JetCustoms: a designed prototype made production-ready
- Client
- JetCustoms
- Sector
- Automotive
- Engagement
- Production hardening
- Duration
- 1 week
- Handover
- One HTML file, one locale
- Stack
- Next.js · TypeScript · Postgres
- On corvale.pt
- The business write-up
The challenge
One HTML file: the client’s own design, in Portuguese, rendering correctly at exactly one viewport. No routing, no locale layer, no content model, no build, no deployment, and a single JPEG inlined in the markup. The design was finished and it was good — what was missing was everything that turns a design into a site, which is also everything a prototype is never asked for.
What we did
Replaced the substrate and held the design fixed. The markup became a Next.js application prerendered per locale and fed from the CMS already in the back office from the platform build, with hreflang alternates so the two languages are variants of one document rather than two documents competing for the same query. Images moved out of the markup into object storage behind a CDN, served responsive with declared intrinsic dimensions so the browser reserves layout before the bytes arrive and nothing shifts under the reader’s thumb. Then the invisible layer — metadata, structured data, sitemap, robots, llms.txt, draft preview against the real site — and a pipeline with preview and production separated.
Zero design changes is what makes a rebuild like this hard rather than merely long.
Every defect that surfaces at a width the prototype never faced has a cheaper fix available if you are allowed to move something: reflow the row, enlarge the target, reorder the focus path. Each of those is a design decision, and none of them were ours to make — so each was solved underneath the design instead. Tested at every width from 320px to wide desktop, because what surfaces there is not a set of design flaws. It is the gap between a layout that works at one size and a layout that works.
What changed
| Area | Prototype | Production |
|---|---|---|
| Locales | Portuguese, hardcoded | Prerendered per locale, hreflang alternates |
| Content | In the markup | CMS-backed, drafts previewed against the real site, published in one click |
| Viewports | One laptop | 320px to wide desktop, every width exercised |
| Images | One inlined JPEG | Object storage behind a CDN, responsive, intrinsic dimensions declared |
| Crawlers | Nothing | Metadata, structured data, sitemap, robots, llms.txt |
| Accessibility | Untested | Skip link, keyboard path, focus order, contrast — done and checked by hand |
| Delivery | A file | Pipeline with preview and production separated |
Lighthouse, desktop
Worth putting in proportion. Desktop is the easier of the two runs — more CPU, a friendlier network assumption, no mobile throttling — so a perfect desktop score is a floor to hold rather than a result to frame. Its value is as a gate: a number checked on every deploy stays where it is, and a number screenshotted once does not.
Accessibility at 100 is the one to be most careful about claiming. The audit checks what a tool can check — contrast ratios, accessible names, document structure — so a clean run means no automated failures, not an accessible site. The skip link, the keyboard path, the focus order and the contrast were done by hand and checked by hand. The score agreed with the work; it did not stand in for it.