Path 01
F
Finish it
Keep the stack fix the hidden parts, launch
Prototype to Production / Lovable · Bolt · v0 · Cursor · Replit
Bring us your AI-built prototype.
You built it in Lovable, Bolt, v0, Cursor or Replit and it almost works. We read what it proves, what it hides and what should happen next, then build the real system: scope, security, data, testing, support.
Prototype review
Lovable · Bolt · v0
Cursor · Replit
Security and data
Real scope, clear quote
Supported after launch
// 01
what we build
The prototype is a better brief. We build the product it describes.
A prototype built with an AI tool is the most useful brief a business has ever brought us. It shows the screens, the flow and the words. It also skips the parts that make software safe to run: accounts, permissions, data, payments, errors, hosting.
The prototype review reads both. In a week you get a written scope: what the prototype proves, what it hides, the risks, a build path and a quote. Ask for a quote for the review before we start.
Then we build the real system, with the prototype as the reference, and support it after launch. You keep working in your tool if you like; we tell you where that stops being safe. Our guide to working with a digital agency explains how the prototype becomes a scope.
01
Prototype review (Lovable, Bolt, v0, Cursor, Replit, Claude, ChatGPT builds)
02
Scope document and build path
03
Security and permissions review
04
Data model and database design
05
Authentication and accounts
06
Payments and subscriptions
07
API and integration work
08
Hosting, deployment and backups
09
Testing and error handling
10
Rebuild or finish, phase by phase
11
Launch
12
Support after launch
// 02
what usually hides in a prototype
It works on your laptop. Production is a different place.
Prototypes are built to show, not to run. The AI tool makes the happy path look finished and leaves the rest for later: who may see what, what happens when a payment fails, where the data lives, who gets the error at 2 a.m.
None of that is a reason to throw the prototype away. It is the reason to read it properly before spending real money. The review is where most of the savings happen: what to keep, what to rebuild, what to drop.
We have done this for publishers and brokerages that came with half-built systems. The pattern is the same at any size.
// 03
three ways it goes
After the review, one of three paths.
Most prototypes land in one of these. The review tells you which, with a quote for each.
Path 02
R
Rebuild from the reference
New stack prototype as spec
Path 03
S
Stop here
Honest answer the prototype did its job
Then
S
Support
Any path named engineer, monthly
The prototype review takes one week. Ask for a quote for the review and any build that follows, in phases you approve one at a time.
// 04
how rtw works
Read it. Scope it. Build the real one. Support it.
We start by reading the prototype as a brief and as code, then write down what it proves, what it hides and what it should become.
prototype.flow
06 stages
LINK
you send the prototype
REVIEW
one week, agreed quote
SCOPE
proves, hides, risks, path, quote
BUILD
phases you approve
LAUNCH
tested, hosted, documented
SUPPORT
named engineer
01
Send the link
The prototype's URL and, if you have it, the code. A short form asks what it is for and who will use it.
02
The review
A week. We use it as a user, read it as engineers, and list what holds, what hides and what it would take.
03
The scope document
Written, with a build path in phases and a quote per phase. We walk through it on a call.
04
Build, phase by phase
Finish or rebuild, with the prototype as the reference. Accounts, data, permissions, payments, errors, hosting done properly.
05
Launch
Tested, hosted where it makes sense, documented, yours.
06
Support
A monthly plan with a named engineer, so the system keeps working after the launch week.
// 05
why rtw
From the people who wrote the vibe-coding series.
We read prototypes for a living
Six articles on what AI-built prototypes prove and hide. The review applies them to yours.
Quote agreed, one week
The review has an agreed quote and a deadline before you commit to anything else.
Keep what works
We do not rebuild for the sake of it. If the stack holds, we finish it; if it does not, the prototype becomes the spec.
Senior engineers, Reston VA
The people who review the prototype build the product. Since 2012, for USA TODAY, Century 21 New Millennium and founders across the DC metro.
Supported after launch
We build systems we are willing to support. A named engineer stays on the product after the launch.
client voices
What clients say.
// 06
features
What the prototype review and the build cover.
Prototype to production development
AI-built app review
Lovable app to production
Bolt app development
v0 app development
Cursor and Replit app finishing
MVP to production
Security review of AI-generated code
Authentication and accounts
Permissions and roles
Database design and migrations
Payments and subscriptions
API integrations
Hosting and deployment
Backups and monitoring
Testing and error handling
Performance and cost review
Documentation and ownership
Support after launch
// 07
services checklist
A practical checklist of what RTW can help with.
Review / one week
Scope / document
Build / engineering
Launch / handover
Support / post-launch
Honest / answers
// 08
fit
Good fit when the prototype already convinced someone.
RTW is a good fit when a prototype has shown the idea to users, a partner or a boss and the next question is “what does it take to run this for real?”
It is not a good fit when the prototype has not been shown to anyone yet. Show it first; the review is better with their reactions in it.
common situations
- You built it in Lovable, Bolt, v0, Cursor or Replit and it almost works
- Users like it and you are afraid to put real data in it
- The AI tool stopped being able to fix what it broke
- You need accounts, payments or permissions and the tool's version feels unsafe
- An investor, partner or client asked “is this production-ready?”
- You want a quote for finishing it before you spend more
- You want someone to support it after launch
// 09
straight answers
Straight answers to the questions we usually hear first.
OBJ 01
Will you just tell us to rebuild everything?
Only if it is true. The review names what to keep. Many prototypes are finished, not rebuilt; some should stop. We put the three options and their quotes in the same document.
OBJ 02
Can we keep working in the tool?
Often, for the parts it is good at: screens and flows. We tell you where that stops being safe, usually at data, accounts and payments.
OBJ 03
Is our code safe to show you?
Yes. The review is under a simple confidentiality agreement and the code stays yours. We do not keep copies after the review unless we build.
OBJ 04
How much does finishing cost?
Ask for a quote for the review. The scope document that comes out of it quotes the build in phases. Nothing beyond the review is committed until you approve a phase.
OBJ 05
What if it is not worth finishing?
Then the review says so, and the prototype has done its job: it showed you the answer in a week.
// 10
common questions
Questions from the intake conversations.
01 Which tools do you review?
Lovable, Bolt, v0, Cursor, Replit, Windsurf, and apps built directly with Claude or ChatGPT. If it runs in a browser and you can send a link or the code, we can review it. For a prototype centered on a repeatable business process, see AI Workflow Automation.
02 What do we get from the prototype review?
A written scope: what the prototype proves, what it hides, a risk list, a build path (finish, rebuild or stop) with phases and quotes, and a call to walk through it. Delivered in one week.
03 How much does the review cost?
Ask for a quote. The review is credited against the first build phase if we build.
04 Who owns the code?
You do, before and after. We work in your repository and your accounts.
05 Can we keep using the AI tool while you build?
For screens and flows, usually yes. For data, accounts and payments we take over, and we tell you exactly where the line is.
06 What does 'production-ready' mean?
Accounts and permissions that hold, data that is backed up and migratable, payments that handle failure, errors that users can understand, hosting someone maintains, and tests for the paths that matter.
07 How long does the build take?
Depends on the path. A finish is often four to eight weeks; a rebuild from the reference is scoped in phases with a date each.
08 Do you support it after launch?
Yes, under a monthly plan with a named engineer. See Application Support.
09 Do you work remotely?
Yes, across the United States. Founders in Reston, VA and the DC metro can meet us by appointment.
// ready when you are
Send the link. We'll tell you what it proves and what it hides.
A one-week review of your AI-built prototype: what holds, what is missing, the risks, and a quoted path to a system you can run.