What you built
- Proves the idea and the demand.
- Defines the scope precisely.
- Becomes the specification.
Your prototype proved the idea. We'll turn it into a product.
Audit, redesign, architect, and productionize what you built in Lovable, Figma Make, Claude, v0, or Replit, into software you can actually ship, sell, and maintain.
The gap
A working demo and a working product aren't the same artefact.
Modern tools are extraordinarily good at getting an idea to the point where people believe it. They are not designed to get it to the point where a customer depends on it.
It works for you, not for users
The happy path is solid because you built it and you know the route. Everything either side of that route is undefined.
There's no design system
Every screen was invented separately. Nothing composes, and the product gets less coherent with each feature added.
The architecture can't take weight
Data model, state, and auth were expedient choices rather than decisions. They hold until they very suddenly don't.
Accessibility isn't there
Keyboard navigation, focus management, contrast, and semantics. Increasingly a procurement blocker, not a nice-to-have.
Responsive means desktop
Laid out at one width, on one machine, by one person. Real breakpoints were never a constraint.
Edge cases are unhandled
Empty, loading, error, permission, offline, and partial-failure states are the bulk of real product surface area.
What you have
What the prototype already earned you.
This is not a page about prototypes being bad. Getting to a convincing prototype is genuinely valuable, and it de-risks everything that follows.
| Your prototype proved | It hasn't yet established | |
|---|---|---|
| 01 | The idea is worth building | A design system anything can scale on |
| 02 | Roughly what the core flow should be | An architecture that survives the roadmap |
| 03 | That users respond to the concept | Accessibility or responsive behaviour |
| 04 | Enough to raise or to get a design partner | Error, empty, and permission states |
| 05 | A working specification of intent | Security, auth, and data boundaries |
| 06 | Which features nobody actually asked for | Anything a second engineer can work in |
01
- Your prototype proved
- The idea is worth building
- It hasn't yet established
- A design system anything can scale on
02
- Your prototype proved
- Roughly what the core flow should be
- It hasn't yet established
- An architecture that survives the roadmap
03
- Your prototype proved
- That users respond to the concept
- It hasn't yet established
- Accessibility or responsive behaviour
04
- Your prototype proved
- Enough to raise or to get a design partner
- It hasn't yet established
- Error, empty, and permission states
05
- Your prototype proved
- A working specification of intent
- It hasn't yet established
- Security, auth, and data boundaries
06
- Your prototype proved
- Which features nobody actually asked for
- It hasn't yet established
- Anything a second engineer can work in
The actual work
Audit to product, in eight moves.
Audit
We go through the prototype properly: code, data model, dependencies, auth, and which parts are genuinely load-bearing versus scaffolding.
Rethink the UX
Flows, information architecture, hierarchy, and the jobs the product actually does, separated from the shape the prototype happened to take.
Establish a design system
Tokens, components, and states, defined once in Figma and in code, so the tenth screen costs a fraction of the first.
Architecture
Data model, state management, API boundaries, auth, permissions, and environments, decided deliberately this time.
Productionize
Rebuild on a stack that can carry the roadmap, reusing whatever from the prototype genuinely deserves to survive.
Accessibility
WCAG 2.2 AA as a build standard: semantics, keyboard paths, focus management, contrast, and screen reader passes.
Responsive
Real breakpoints against real content, including the dense data views that prototypes quietly avoid.
Edge cases and QA
Empty, loading, error, permission, and failure states designed and built, then tested systematically rather than demoed.
What happens to what you built?
Usually it becomes the specification. It is the clearest possible statement of what you wanted, and it's far more useful than a requirements document.
Occasionally chunks of it survive into production. More often the value was in what it taught you, and rebuilding is cheaper than untangling.
- Kept as the functional specification
- Kept running for demos and fundraising
- Specific components harvested into production
- Retired once the real product ships
- Rebuilt incrementally behind a feature flag
Approach
How it fits together.
AI stays in the workflow throughout. It accelerates production and catches the checks humans shouldn't do by hand. The decisions stay with designers and engineers.
Design system + architecture
- Tokens, components, states.
- Data model, auth, API boundaries.
- Decisions, not defaults.
Shipped product
- Accessible, responsive, tested.
- A second engineer can work in it.
- Built for the next two years.
Process
How an engagement runs.
Understand
Product goals, users, the prototype itself, the roadmap, and what has to be true for this to be a business.
Architect
Information architecture, content and data model, design system plan, technical architecture, and a build sequence.
Design
A component-based interface system designed against real data and the states the prototype skipped.
Build
Production build on a modern stack, shipped in slices, with preview environments from the first week.
Validate
Accessibility audit, responsive QA, performance, analytics instrumentation, and systematic functional testing.
Launch
Deployment, environments, monitoring, analytics verification, then handover documentation and support.
Honest assessment
When this is the right engagement.
If you're still testing whether anyone wants this, keep prototyping. This work is for the moment after that question is answered.
Bring us in when
- The prototype has validated real demand
- You're funded and hiring against a roadmap
- Customers are about to depend on it
- Enterprise buyers are asking about accessibility
- A second engineer needs to work in the codebase
- The next ten features feel harder than the first ten
Keep prototyping when
- You're still testing the core hypothesis
- The concept is likely to change substantially
- There are no users and no timeline yet
- A throwaway demo is genuinely all you need
- You haven't decided what the product is
The production stack.
React · Next.js · TypeScript · Tailwind · Supabase · Postgres · Stripe · Vercel · Figma · Sentry
Tools: React, Next.js, Vercel, Figma
Starting points
Wherever you built it.
Built it somewhere else? We'll still audit it.
Lovable → production
Full-stack prototypes with a real data layer, usually the closest to production and the most tempting to ship too early.
v0 → production
Strong component output that needs a design system, state architecture, and the states it never generated.
Claude → production
Genuinely capable application code that needs architectural decisions made deliberately rather than per-prompt.
Replit → production
Working software in a hosted sandbox that needs environments, auth boundaries, and a deployment story.
Figma Make → production
A convincing interactive prototype that needs a real data layer and a component system underneath it.
Bolt → production
Fast full-stack scaffolding that needs the architecture, accessibility, and edge cases filled in.
Relevant work
Product projects.
FAQs
Prototype to production questions.
Do you throw away what we built?
Sometimes, and we'll tell you honestly which it is after the audit. The prototype's real value is usually as a specification. It removes the ambiguity that makes product work expensive.
Can you work with our engineers?
Yes. We can own design and hand off, design and build the front end alongside your team, or take the whole thing. Most engagements are the middle one.
How long does productionizing take?
A focused product surface is typically ten to sixteen weeks. Broader platforms with permissions, billing, and integrations run longer, and we'd sequence it into shippable slices.
Why not just hire engineers?
Eventually you should. This work is what makes that hire productive on day one instead of month four: a design system, an architecture, and a codebase someone can join.
Do you use AI in the build?
Constantly, for production work and for the checks humans shouldn't do manually. The architecture and design decisions stay with senior people, which is the entire point of hiring us.
What if we're pre-funding?
Then this probably isn't the right time. Keep prototyping until the idea is validated, and come back when customers are about to depend on it.