A migration is not a feature-for-feature port. It’s a redesign opportunity — and mockups built in the production tech stack are how you seize it.
The Question That Changed the Schema
We chose to build all 23 UI pages as standalone mockups in the production tech stack — not Figma, not wireframes — before writing any backend code. The product owner’s first review caught a data model flaw that would have been a rewrite if we’d built the backend first.
The question was simple: “What happens when there are zero candidates?”
It doesn’t sound like a schema question. It sounds like a UI question — what does an empty state look like? But the moment you answer it, you’re making decisions about data relationships, default views, permission logic, and onboarding flow. The mockup surfaced this because the product owner was clicking through something that looked and felt like the real application. That’s the difference between a design review and a design document.
This was the AI hiring decisioning platform we rebuilt from Bubble.io — the same project where we wrote 19 PRDs before touching code. After the requirements were locked, the next instinct was to start building the backend. We said no again. Build the frontend first. Every page. Static data. No API. Let the product owner see what their customers will see before a single database table exists.
Why Figma-to-Code Is a Tax, Not a Process
The standard workflow looks reasonable on paper: design in Figma, get approval, hand off to developers, build. In practice, every step in that chain introduces translation loss.
The designer creates something pixel-perfect in a tool that has no concept of responsive behaviour, state management, or real data variability. The developer rebuilds it in actual code, making dozens of micro-decisions along the way — how does this component behave at mobile width? What happens when the text is longer than expected? How does this animation perform with real network latency? Each micro-decision is a divergence from the design. Each divergence requires a review cycle. The review cycle reveals that the design didn’t account for the edge case. The designer adjusts. The developer rebuilds. Repeat.
This is the translation tax. You pay it on every screen, every iteration, every review cycle. And for a migration with 23 pages, the tax is enormous.
This is the translation tax. You pay it on every screen, every iteration, every review cycle. And for a migration with 23 pages, the tax is enormous.
The alternative: build mockups directly in the production tech stack. Next.js components with Tailwind CSS and static sample data. The product owner reviews something that runs in a browser, responds to clicks, and adapts to screen sizes. When they approve it, the components transfer directly to production. Zero translation. Zero tax.
Every UI Choice Is a Data Model Decision in Disguise
This is the insight that most teams miss until it’s too late.
“Show candidates grouped by stage” sounds like a layout choice. It’s actually four decisions: a status field on the application model, a sort order, a grouping key, and a permission rule about who sees which stages. “Display the interview panel with a left sidebar” implies a data structure for interview assignments, a relationship between questions and sections, and a rendering order that maps to the evaluation framework.
If you don’t make these decisions explicitly in the design phase, AI will make them implicitly in the code.
If you don’t make these decisions explicitly in the design phase, AI will make them implicitly in the code. Its guesses will be internally consistent — the data model will support the layout, the API will serve the components, the tests will pass. And the product owner will look at the result and say “that’s not what I meant,” because the silent decisions embedded in the code don’t match the silent assumptions in their head.
Mockups are the forcing function. When the product owner clicks through a page and says “I want to see candidates grouped by stage,” you can ask: “What are the stages? Who defines them? Can they be customised per job? What happens to a candidate when a stage is deleted?” These questions surface naturally in a review of something tangible. They never surface in a review of a specification document.
The Design Brief Isn’t a Mood Board
Before building a single mockup, we extracted a design brief from the recorded planning session. Direct quotes from the product owner became design principles:
“Users can’t see where they are in a workflow.” That became a principle: every screen must show context — where am I, what’s the current state, what can I do next.
“Features exist but nobody finds them.” That became progressive disclosure — core actions visible, advanced features accessible but not cluttering the primary view.
“The terminology doesn’t make sense to customers.” That became a terminology audit — every label, every button, every section header reviewed against what paying customers would understand, not what internal jargon the builder used.
These aren’t aesthetic preferences. They’re product decisions that affect information architecture, navigation structure, and component hierarchy. They belong in a document that every developer — human or AI — references before building anything.
Build in the Production Stack. Review the Same Day.
The mockup phase for the hiring platform produced 23 pages in five days. Not wireframes. Not prototypes. Production-quality Next.js components with realistic sample data, responsive layouts, and interactive states.
The approach was systematic: start with TypeScript interfaces from the core data model PRD. Generate realistic sample data that exercises edge cases — empty states, long names, missing fields, maximum entries. Build shared components first — navigation, layout shells, data tables, form patterns. Then build each page against the PRD specification, one at a time.
Two product review sessions caught issues that would have been expensive to discover later. The first session surfaced the zero-candidates question. It also revealed that the interview conductor — the highest-stakes screen in the entire application — needed a fundamentally different layout than the initial design assumed. The product owner wanted contextual AI assistance available at every point in the interview, not hidden behind a sidebar toggle. That insight reshaped the entire conductor architecture.
When the product owner flagged an issue at 10am, the mockup was updated by 2pm. No ticket. No sprint planning. No waiting for the next design review.
The second session refined terminology across every screen. What the builder had called one thing internally, customers would understand better with different language. Internal shorthand that had accumulated over years of development was replaced with language that new users could parse without a glossary.
Same-day feedback application prevented stale backlogs. When the product owner flagged an issue at 10am, the mockup was updated by 2pm. No ticket. No sprint planning. No waiting for the next design review. This velocity is only possible because the mockups are in the production stack — changing a component is a code change, not a design-tool-then-code-change.
Don’t Port Your App Feature for Feature
The product owner described the existing platform as “clunky.” We’d already unpacked that word during the requirements phase — invisible workflows, buried features, confusing terminology, a UI designed for the builder not the customer. The mockup phase was where we fixed every one of those issues.
A feature-for-feature port would have reproduced them all. The old platform had a settings page with forty options arranged in no particular order. The old platform had a navigation structure that made sense when there were three features but had grown incomprehensible at thirty. The old platform displayed data in the order it was stored, not the order it was useful.
None of this is a technology problem. A new tech stack doesn’t fix bad information architecture. It just renders bad information architecture faster.
The mockup phase is the moment to re-evaluate everything through the eyes of your paying customers. Not “how did we build this in Bubble?” but “what does the user actually need to see on this screen, and in what order?” Every page was designed from scratch against user needs, not ported from the existing layout.
This takes discipline. The product owner’s instinct is to recreate what they know. “Can we have the same dashboard?” No — let’s talk about what you need to see first thing in the morning. “Can we keep the same navigation?” No — let’s organise by what your customers do, not by when you built each feature. Every default assumption gets challenged. The mockup is where you win or lose that argument, because the product owner can see both options side by side in a browser.
The Stakeholder Test
Here’s the simplest quality gate for any design phase: can your stakeholder click through it?
Not “can they look at a screenshot.” Not “can they read a specification.” Can they open a browser, navigate through the application, and tell you whether it makes sense? Can they find the feature they use most? Can they complete the workflow they care about? Can they explain the screen to someone who’s never seen it?
If the answer is no, you haven’t designed it yet. You’ve described it. Description and design are different activities.
If the answer is no, you haven’t designed it yet. You’ve described it. Description and design are different activities. A description tells you what something should do. A design shows you what something does. The gap between those two is where projects go wrong — and AI amplifies the gap, because AI is exceptionally good at turning descriptions into plausible-looking implementations that quietly embed wrong assumptions.
The 23 mockup pages weren’t a deliverable. They were a testing ground. Every page was a hypothesis about what the user needs, validated or invalidated by the product owner within hours of being built. The ones that survived became production components. The ones that didn’t were cheap to discard — a few hours of mockup work, not weeks of integrated development.
What This Means for Your Migration
If you’re moving from a no-code platform to a production tech stack, the mockup phase is not optional. It’s where you:
Discover data model implications before they’re baked into your schema. Every UI layout implies a data structure. Surface those implications when they’re cheap to change.
Fix product problems, not just technology problems. The migration is your chance to redesign, not just rebuild. “Clunky” has a dozen causes, and most of them aren’t about page load speed.
Eliminate the translation tax. Build in the production stack. Components transfer directly. Zero waste.
Get same-day feedback. When the mockup is code, changing it is fast. When it’s a Figma file, changing it is a workflow.
Validate before you invest. Twenty-three pages of mockups cost five days. Twenty-three pages of integrated application would have cost months. The mockups caught issues that would have been rewrites in production.
If your stakeholder can’t click through it, you haven’t designed it yet.