A hardware startup shipped a five-page launch suite at 1.4s LCP

Representative examplesEvery case study in this library is an illustrative composite of the kind of engagement we deliver — written to show our method and standards, not to name clients.

Where they started

One consumer-hardware product, sold direct, with revenue that spikes around press moments and trade shows — that is the shape of this startup. Its visual identity is built on interactive 3D renders of the product, exploded and rotating, and the previous agency's launch pages treated that identity as a mandate to ship megabytes. The comms lead maintained press assets in a shared drive, and every embargo day meant fielding requests for current photos, spec sheets, and boilerplate. The next launch was approaching with reviewers' memories of blank shells still fresh.

What it was costing

The launch needed five interlinked pages — hero product, specs, pre-order, reviews, and press — that previous agency work had delivered as beautiful, slow, 3MB pages. Reviewers opening the press page on conference Wi-Fi saw shells.

What they could see

• Journalists on conference Wi-Fi waited through blank shells before the pages rendered anything at all.
• Analytics showed most spec-page readers never reached the pre-order page during the previous launch.
• Press requests for current assets flooded the comms lead on embargo days because nothing was self-serve.
• Every page edit went through the previous agency on a retainer, so copy fixes took days and cost calls.
• The 3D viewer loaded on every page visit, whether the visitor wanted it or not.

The constraints we worked inside

• The design system was 3D-asset-heavy by brand; the pages had to keep the visual identity.
• Pre-order flow rode on an existing commerce link — the pages must not break the checkout path.
• Press page needed downloadable assets that stayed current without developer help.

What had been tried before

The previous agency had optimized image delivery and added a caching layer to the launch pages.

The weight lived in the 3D pipeline and the bundled scripts their stack required; the optimization trimmed the edges of the problem and left the mass untouched.

The team tried replacing the 3D viewer with lighter screenshots on one page.

The brand's whole point is the product in your hands; the flat version read as a downgrade, and the experiment was scrapped within a day.

Marketing reviewed building the launch on the storefront's page builder.

The builder could not host the 3D assets or the press-kit workflow, so it would have split one launch across two half-capable systems and doubled the maintenance.

What we proposed

Treat the 3D assets as the budget problem rather than the identity problem: static poster frames everywhere, with lazy-loaded interactive viewers only where a reader scrolls into them — the identity stays, the weight moves below the fold. Five pages ship from one static build with a shared component layer, so typography, proof, and navigation stay consistent while each page argues its own case. The pre-order path rides the existing commerce link untouched. The press page reads its asset list from a manifest the comms team updates, making embargo-day changes file swaps.

Just as important is what we ruled out, and why:

• Dropping the 3D entirely for a photo-and-text launch — The identity is the differentiator in a crowded category; the asset was never the problem — its delivery was, and that could be fixed without amputating the brand.
• Hosting the suite inside the existing storefront — The store's theme and release process could not carry lazy 3D or the press manifest, and the pre-order path would have coupled the launch to store releases.
• Replacing interactive 3D with pre-rendered video — Video trades one heavyweight asset for another and loses the drag-to-inspect moment reviewers respond to; the interaction is the story, not a decoration.

How the work ran

Delivered by the experience pod — frontend engineer + designer over 4 weeks, with working increments reviewed with the client every week.

The stack, and the reasoning

Astro-class static build

Five pages that change a few times per launch do not need a runtime; the static build ships near-zero JavaScript by default and treats each page as an argument, not an app.

Lazy 3D viewers

The interactive model loads only when a reader scrolls it into view, behind a poster frame — reviewers who want to inspect still can, and first paint no longer waits on megabytes of geometry.

GA4

The launch's argument — specs to pre-order — needed step-level events so the next launch's edits start from where readers actually dropped, not from a single page total.

Consent Mode

Launch traffic includes EU press and partners; Consent Mode keeps measurement lawful before consent without blinding the team to the funnel they are about to optimize for the next product.

What went wrong

How we worked together

Cadence

Twice-weekly 30-minute reviews on staging with the comms lead and the design lead; a live checklist held every embargo-day task with an owner.

Client side

The comms lead owned press content and asset curation; the design lead guarded the identity; the store's engineer was on call for the commerce-link verification.

Decisions

Design calls were made against the existing brand system on staging; the founders saw two gate reviews — mid-build and pre-launch — and nothing else.

They provided

Brand and 3D source files, store analytics access, the embargo-day timeline, and the comms lead's asset inventory from the previous two launches.

What changed

The headline: p75 lcp across the launch suite on mobile, first 28 days — 1.4s, read from CrUX field data. A second check: spec-page to pre-order progression versus the prior launch at +31%.

Embargo day got quiet. Journalists pulled what they needed from the press page without emailing, because the manifest was current and the files were real. Reviewers stopped mentioning load times and started mentioning the product — the 3D moments still land, they just arrive after the page does. The team runs launch edits themselves now, which changed the cadence of decisions from 'ticket the agency' to 'fix it before lunch'. And the next product's launch suite is a copy of a system that already worked once.

The result was read from CrUX field data against the pre-engagement baseline over the stated window, with a guardrail check on spec-page to pre-order progression versus the prior launch. Where platform-reported numbers and business outcomes differ, this record says which layer it is quoting.

What they own now

• The static site repository with build and deploy documentation.
• The press-page manifest and a written guide to adding assets without a deploy.
• The 3D viewer integration pattern with frame-count and weight budgets documented.
• GA4 step-level events mapped to the launch funnel for future launches.
• The store test-order procedure for verifying the commerce link after any change.