Prototype first when stakeholders still disagree on direction, when motion or interaction carries real technical risk, or when changing production code would be expensive; build first when scope is signed off, components are familiar, and a working baseline beats another round of alignment. We choose per project with three filters — alignment, risk, and change cost — then run the smallest artifact that answers the open question. That discipline sits at the heart of our pitch, prototype, and handoff playbook.
Two paths, defined plainly
Build-first means you take the approved Figma file and move straight into production templates, components, and CMS structure. You get a real site early, real content flows, and real integration points. Prototype-first means you deliberately pause before the main build to create a bounded artifact — a clickable flow, a component spike, or a motion study — whose only job is to retire a specific unknown before it becomes expensive.
Neither path is “more professional.” Build-first is a speed strategy for settled scope. Prototype-first is a risk strategy for unsettled scope. Agencies get in trouble when they treat one default as identity instead of treating the choice as a per-project decision. If you are sequencing work across design handoff and WordPress delivery, our Figma to WordPress service is built around whichever path the risk profile actually supports.
Decision criteria we actually use
We run every engagement through the same short scorecard. If two or more rows point left, we prototype first. If most rows point right, we build first and keep a tight change log. The table is intentionally qualitative: you are judging certainty, not guessing at multipliers.
| Question you can answer today | Prototype first | Build first |
|---|---|---|
| Do stakeholders agree on structure, hierarchy, and priority? | Not fully — direction is still moving | Yes — sign-off is documented |
| Is the hard part a novel interaction, motion system, or component? | Yes — spike it before the full build | No — patterns are proven and familiar |
| Will change requests hit working production code? | Likely, repeatedly | Unlikely — changes stay cosmetic |
| Is the goal to win alignment or a pitch decision? | Yes — the artifact is a decision tool | No — the goal is shipping the baseline |
| Are templates, content model, and integrations locked? | No — assumptions remain open | Yes — scope is ready to execute |
The change-cost curve
Software engineering has long established a simple truth: the later a problem is discovered, the more layers it touches. A confused hierarchy caught in a prototype costs a conversation. The same confusion found after templates, components, content entry, and QA cycles exist costs rework across all of them. You do not need a precise multiplier to plan sensibly — the direction of the curve is enough. Cost is flat while the artifact is disposable, then climbs as soon as production code exists, and climbs again after launch.
That is why we treat prototypes as insurance with a fixed premium. The premium is days of focused work. The payout is avoiding structural rewrites inside a live build. When stakeholders want “just one more direction” after production has started, you are already paying the expensive side of the curve. A prototype moves that negotiation to the cheap side, where changing your mind is still cheap. The same logic applies after launch: cosmetic tweaks stay affordable; structural pivots do not.
When a prototype saves money — and when it does not
A prototype pays for itself when it prevents rework. Classic cases: a homepage narrative that sales and marketing have not agreed on; a custom interaction your team has never shipped; a scroll-driven sequence that must feel right before you commit a template structure to it; a stakeholder group that needs to click through an idea before they can approve it. In those situations the prototype is not decoration — it is the shortest path to a binding decision. Motion questions are especially good candidates; a focused motion sprint isolates the interaction in days instead of discovering friction mid-build.
A prototype does not pay when the design is approved, the components are ordinary, the motion is light, and the stakeholder count is small. At that point a prototype is pure overhead: you delay the real build without reducing a real risk. We also do not prototype what is already proven. If a pattern has shipped cleanly many times, the honest move is to build it and reserve prototype budget for the genuinely unknown parts of the project.
How we run prototype work before a full build
We scope the unknown first, in one sentence: what decision must this artifact make possible? Then we build only what answers that question — no speculative component library, no full content model, no production CMS wiring. We review it on real devices, note constraints for engineering, and hand a tight set of decisions into the build phase. Production code is written clean from the approved direction; the prototype is reference and evidence, not a shortcut past QA. Agencies that want this sequence embedded in delivery can start with our white-label web development engagements, where the prototype conversation happens inside your process, under your brand.
Related reading that pairs well with this decision: realistic Figma to WordPress timelines and cost drivers, and how we keep work invisible to your clients as an invisible development partner. For design-side prerequisites, see the Figma handoff checklist for developers. Selected production work lives in our Mukani and Leadly case pages.
Key takeaways
- Prototype first when alignment or technical risk is high; build first when scope and patterns are locked — decide per project, not per agency habit.
- A prototype pays for itself when it prevents rework in production code; the change-cost curve does the math for you.
Frequently asked questions
How long should a prototype take?
Short enough to answer one question. In practice that means days, not a parallel redesign of the whole site. If a prototype keeps growing, it has lost its scope and should be cut back to the decision it was meant to serve.
Does a prototype replace a design system or full design pass?
No. A prototype is a decision tool attached to a specific unknown. Your design system, tokens, and documented components still define the product; the prototype validates direction before those decisions harden into production templates.
When is build-first wrong even on a small site?
When the small site hides a hard interaction, a contentious narrative, or stakeholders who have not agreed on priority. Size does not remove risk — it only changes how visible the risk is until production code makes it expensive.
Will our client see the prototype?
Only if you want them to, and only through your brand and your process. We work as an invisible partner: no direct client contact, deliverables presented under your name, communication routed through your team per your NDA and workflow.
What happens to prototype code after approval?
We treat it as reference and evidence unless the engagement explicitly scopes it as production-grade. Approved direction moves into a clean build with normal code review, cross-browser QA, and performance budgets — not a rushed promotion of spike code.