Built a prototype with Lovable, Bolt or Cursor? Here's when to bring in a team

If you've built a working prototype with Lovable, Bolt or Cursor, you've done the hardest part of any product: you've made the idea concrete enough to show someone. Keep going for as long as it's teaching you something.

The tools are genuinely good at screens and flows. Where founders tend to get stuck is the part that doesn't show up in a demo.

What a demo doesn't have to survive

• Sign-in that holds up: password resets, sessions, and people who should only see their own data.
• Payments that reconcile: failed cards, refunds, subscriptions that change mid-month.
• Data you can't afford to lose: backups, migrations, and records that stay correct when two people edit at once.
• Errors you hear about before your users tell you.
• Code another developer can pick up and keep building on.

None of these are exotic. They're simply the difference between something that works when you click through it and something that works when a stranger uses it at 2am.

Signs it's time

• Real people are about to use it, and you'd be embarrassed if it broke or leaked.
• It needs to take money.
• Each new prompt fixes one thing and quietly breaks another.
• You're spending more time steering the tool than talking to users.

If none of those are true yet, you probably don't need a team. Keep testing.

What happens to the prototype

It becomes the best brief you could write. A clickable prototype answers most of the questions we'd otherwise spend a call on: what the main screens are, what order things happen in, what you care about. Often the right move is to keep the flow and rebuild underneath it, on mainstream technology in a repository in your name.

A prototype often fits one of our fixed-price packages, because the hard thinking about scope is already done. See how we take a prototype to production, what each package includes, or read how we decide what goes in the first version.