Can you finish a Lovable, Bolt or Cursor app in 3 days? Six things that decide it

People send me the same message about once a day now. It usually looks like this:

I built the whole thing with Lovable and Cursor. Screens look fine, the database works, but I can't get it live and I don't know what's left. Can you finish it in three days?

Sometimes the answer is yes and it takes three days. Sometimes the honest answer is six weeks, and the reason has nothing to do with how much is left in the app. After doing this for a while, I can usually tell which one it is in the first twenty minutes. Here is the same test, so you can run it on your own project tonight.

1. Does anything in it need a company on paper?

Payments, phone verification, app store review, anything with a "business account" step. None of that is programming. It is a queue you join and wait in, and no amount of AI-generated code shortens it.

A Stripe test payment takes an afternoon. Live payments on a Korean or European entity take a few days of documents. Apple's first review of a new developer account took eight days for an app I finished on a Thursday. If your three-day plan includes the App Store, it is not a three-day plan.

So: write down everything that requires a legal entity, a reviewed account or a human on the other side. That list is your real calendar. Everything else is the work.

2. Has it ever run anywhere except your laptop?

Almost every stalled AI-built app runs beautifully in the preview environment and dies on the first real deploy. Not because the code is bad, but because the preview had things the production host does not:

• environment variables that existed only in the builder's dashboard
• a database that was created by clicking, not by a migration
• cookies set on localhost that the real domain rejects
• a serverless function that works warm and regenerates a secret when cold

The test: deploy it to the domain you actually intend to use, open it on a phone with wifi off, and hit refresh twice. If the second load behaves differently from the first, that is your work for day one.

3. Do two accounts see each other's data?

This one is worth its own paragraph because it is the failure that gets you in trouble rather than merely embarrassed. Generated code often checks that someone is signed in, not who they are. I test it with two accounts, never one: create a row as A, then try to read, edit and delete it as B by editing the URL.

If B can see it, you are not three days from launch. You are three days from a data incident, and the fix is in every endpoint, not in the UI.

4. Is a payment confirmed by a webhook, or by a page?

A payment that is "confirmed" when the user lands on /success is not confirmed. Anyone can open that URL, and the customer can press Back. A real confirmation arrives as a signed webhook, is processed once even if it arrives twice, and reconciles against your own order record.

Test with one real card, live mode, then refund it. If the refund leaves your order table disagreeing with the payment provider, you have found a week of cleanup later.

5. Can the person who paid you get back in?

Password reset, a user who signed in with Google and later tries email, an email that lands in spam, a session that survives a tab restore. I once shipped an app where the reset link expired in ten minutes because that was the default and nobody had read it. The builder never noticed; the first customer did, on a Sunday.

6. When it breaks, will you know?

A user writes "it doesn't work". Can you find that request in a log, with an id you can search, and get an alert somewhere a human reads? If the answer is "I'd ask them to screenshot it", every future bug costs three times as much.

What three days actually buys

If the six answers above are clean, the app rarely needs features. It needs a pass over the seams, plus a deploy that is boring: canonical domain, HTTPS on both apex and www, a phone on cellular, a slow connection, and a rollback you have actually tried.

In my own order, that finish looks like this: half a day to find and fix the seam that will cost the most, one to two days of fixes, then a day of deploy, store or domain paperwork, and a short handover document you could give a stranger. That is where "three to five days" comes from — not from writing an app, from closing the gap between a demo and something a stranger can pay for.

What it does not buy: architecture, a marketplace with two-sided compliance, a bank integration, or a game whose content is still being designed. If someone quotes you three days for those, they are guessing, and you will pay for the guess later.

Where the 20% goes

The part that stalls AI-built apps is not the code the model wrote. It is the set of decisions nobody made: whose name is on the account, what "done" means for each screen, what happens on the second payment, who owns the code after the invoice is paid. Those decisions are cheap to make and expensive to discover at launch. If you want a second pair of eyes before you start paying anyone, that is the part I look at first.

I'm a one-person studio in Seoul, working as a Korean corporation with a direct contract and an official invoice. Quotes and a code review of what you already have are free, and you pay the balance only after you have clicked the finished thing yourself.

• Site: https://cpcai-studio.netlify.app/en/
• Email: [email protected] (write in your own language, I'll reply in it)