Skip to content
Senior web & app development · 20 capabilities
oakstone.digital
Case study / Rivet Systems

The website that finally sells the product.

We rebuilt an industrial software marketing site around the way technical buyers actually evaluate.

Industry
SaaS
Duration
10 weeks
Division
Websites & Commerce
Year
2025
Rivet Systems — saas web development project by Oakstone
Websites & Commerce / delivered
+41%
demo starts on flat traffic
−9 min
average time to technical qualification
2nd
largest lead source now documentation
The challenge

Rivet sold a genuinely sophisticated product to plant engineers and IT directors, and its website spoke to neither. The homepage led with a vision statement, the product pages listed features without context, and the technical documentation sat behind a form.

Sales spent the first fifteen minutes of every call correcting misconceptions the site had created.

The move

We interviewed eight recent buyers and both sales engineers, then rebuilt the argument in the order those buyers actually used: the failure mode they recognise, the mechanism, the integration reality, then the commercial model.

Documentation came out from behind the form. Architecture diagrams, API references and a security overview were published openly, on the reasoning that a technical evaluator who cannot verify your claims assumes the worst.

The result

Demo starts rose 41% on flat traffic, and sales reported that calls now began at the integration question rather than at "so what does this actually do".

Publishing the documentation also produced an unexpected search effect: technical pages began ranking for the specific integration terms their buyers search for.

Oakstone gave us the rarest thing in a rebuild: a sharper business. We stopped explaining ourselves and started being chosen.
Maya Chen
CMO, Rivet Systems
Stack
AstroTypeScriptTailwind CSSMarkdocCloudflarePlausible
Team

One strategist, one designer, one engineer, plus their two sales engineers

Constraints
  • No new brand identity — the existing one had to be extended
  • Technical documentation had to publish from the engineers’ own Markdown
  • Launch date fixed to a trade show
What we would do differently

Publishing the documentation openly was the single highest-return decision and we argued for it too gently at first. It should have been in the first proposal rather than reached in week four.

We under-scoped the internal review burden on clinical-grade technical claims. Two rounds of engineer review per page is realistic; we planned for one.

A better brief starts here

Your next proof point is waiting.

Bring us the hard thing. We will bring a point of view, a senior team and a clear next step.

Start a conversation