When to Stop Prompting and Hire a Developer

Search this question and you will find two kinds of page. Builder companies explain that you no longer need developers. Development companies explain that you do. Both are arguing their own book, and neither tells you which situation you are in.

We are the second kind of company, so treat the rest of this with that in mind. What follows is the answer we actually give people who write to us, including the times we tell them not to hire anybody yet.

If you have not started building yet, the prior question is whether a builder suits what you are making at all, and we answer that separately in when an AI builder is the right way to start. This article assumes you already have something running.

When the answer is to keep prompting

Start here, because it is the most common correct answer and the one nobody selling either side will give you.

If nobody outside your circle is using the app, keep prompting. If you are still finding out what the product should be, keep prompting, because you will throw most of it away and it would be a waste to have paid someone to build it carefully. If the users are you and four colleagues who already have access to the data anyway, keep prompting. If the app holds nothing that would matter if it leaked and takes no money, keep prompting.

People in these situations hire too early surprisingly often, usually after a frustrating week, and the money goes into hardening a product that is about to change shape entirely. Spend it later, when you know what you are keeping.

The four signals that change the answer

There are four things that move the question from taste to risk. Each one changes what a mistake costs from an afternoon to something you have to tell someone about.

1. Real accounts. The moment people who are not you can sign in, the database has to be the thing refusing access, not the screen. This is the single most common serious problem we find.
2. Real money. Once payments exist, something has to decide what counts as paid, and it cannot be the user's browser.
3. Other people's data. Anything you would have to write an awkward email about if it leaked. Health, financial, children's, or simply customers who assumed their records were private.
4. App store submission. The stores enforce things a prototype has never had to answer: signing, privacy declarations, data-safety answers, account deletion.

One of these being true does not mean you need a full-time developer. It means the app now has a category of problem that cannot be found by looking at it, which is why the seven problems we check first exists as a list you can run yourself before you call anyone.

Things that feel like signals but are not

Equally useful is knowing what does not mean it is time.

• A bug you cannot get the tool to fix. Annoying, but one stubborn bug is a bad afternoon, not a structural verdict.
• Code you do not understand. You were never going to read it. Whether it is good is a question for a review, not a reason in itself.
• Someone telling you that AI-built apps are not real software. They are describing a category, not your app.
• Wanting it to feel more professional. That is design work, and often a different and cheaper purchase than engineering.
• A feature you cannot get built. Worth one honest attempt at a different prompt first. Tools improve monthly and this is the complaint that ages fastest.

It is not prompting or hiring

The framing of the question is the thing most likely to cost you money. It presents a permanent choice between doing it yourself and employing somebody, when the useful option sits between them.

That option is a bounded piece of work: someone reads the code, tells you what is actually wrong, fixes the handful of things that would hurt real users, puts tests around the flows that already work, and leaves. You carry on prompting afterwards, with the difference that a later prompt which breaks checkout now fails a test instead of a customer.

This is what we do most often, and it is deliberately the smallest version of the work. What it costs depends entirely on what the review finds, which is why what decides the cost of finishing a half-built AI app is worth reading before anyone quotes you a number.

What hiring actually buys

If you do bring someone in, be clear about what you are buying, because it is not typing speed. An AI tool writes code faster than any person.

What you are buying is judgement about the invisible half: what happens when two things occur at once, what the app should do when a payment half-completes, which of your features is quietly a security decision, and what not to build at all. That last one is usually worth the most and is never what people think they are paying for.

Whoever you choose, the usual advice on picking them applies: ask for a review before a rebuild, and be wary of a fixed price quoted before anyone has read the code. We set out what to ask in how to choose a development partner.

Where this leaves you

Run the four signals. If none is true, close this page and keep building, which is the honest answer however little it suits us. If one is true, run the seven checks yourself first, because you may find the gap is narrow and fixable.

If two or more are true and the app is about to meet real people, that is the point where a second pair of eyes is cheaper than the alternative. We start every engagement with a review rather than a rebuild: send us the app, or the Lovable-specific version if that is what you built with. If you would rather just ask, tell us where you are and we will say which of the three answers above applies, including the one where you do not need us.