Your AI Prototype Stalled. How to Hire Someone to Finish It

You built something. It took a weekend and a lot of prompting, and at some point it started working, which was one of the better feelings you have had at a computer. Then you tried to add the next thing and it broke. You fixed that and something else broke. Now you are three weeks in, the bugs have started arriving faster than you can clear them, and you have realized you need somebody who does this for a living. You have never hired one of these people and you have no way to tell a good one from a confident one.

That is a specific and very common position to be in, and it is a better one than you think. This is how to hire from it without getting taken.

What you actually hit

The wall is real and it is not a sign you did anything wrong. It shows up in the same place almost every time, because building software has two halves and the tools you used are excellent at one of them.

The first half is making something work once, on your machine, with you driving and no one else watching. AI is genuinely good at this now. That is not a toy accomplishment and I would not let anybody tell you otherwise.

The second half is everything that makes it survive contact with other people. Somebody else’s data sitting next to yours without either of them leaking. What happens when two people click the same button at the same moment. What happens when the payment provider times out halfway through. Somebody typing an apostrophe into a field you assumed was a number. The part where you can change one thing without silently breaking three others, which requires that the code have a shape rather than having accumulated.

Generated code tends to be locally correct and globally shapeless. Each piece does roughly what was asked. Nothing is holding the pieces in a relationship to each other, so the twentieth change costs more than the first ten combined, and eventually a change costs more than the feature is worth. That is the wall. It is not a wall you can prompt your way past, because the problem is structural and the tool works one file at a time.

ChatGPT can’t build your MVP for you covers why this happens in more depth. The short version is that you did not run out of talent. You ran out of architecture, which nobody gave you and which the tool does not know it is supposed to produce.

You are holding an asset

Here is what almost nobody tells you at this stage, and it changes the entire conversation you are about to have.

Most people who want software built show up with an idea and a document. You are showing up with a working artifact. Somebody can click it. That is worth more than any specification you could have written, and it is worth considerably more than a well-designed set of screens, because a running thing has already answered a hundred questions that a document leaves open.

It also means you have done the expensive part of the thinking. You know what the app is for, you have felt where it is awkward, and you have opinions about the next three features that are grounded in having used it. A builder walking into that has a much easier job than one who has to extract all of it from you over six weeks of meetings.

A prototype somebody can click is the best specification you will ever write, and you already wrote it.

Say this plainly when you reach out. “I have a working prototype, here is the link, here is what breaks.” That single sentence puts you ahead of most of the inbound a good builder gets.

Why nobody is calling you back

If you have been reaching out and hearing nothing, it is usually one of three things, and all three are fixable.

You offered equity. Equity in a pre-revenue company has no buyer, which means you have offered to pay somebody in something they cannot sell, spend, or value. From their side that reads as a request to work for free with extra paperwork. It is not an insult and most people will not say it out loud, they will just stop replying. If your company has customers and revenue, equity is a real conversation. Before that it is a lottery ticket, and experienced builders have a drawer full.

You asked for coffee. A meeting to explore an idea costs a working builder two hours and produces nothing they can bill. They are not being rude. They are booked, and the request to “pick your brain” arrives weekly. What gets answered is a specific, small, paid piece of work.

You asked them to scope it for free. Writing a real estimate means reading your code, understanding your domain, and thinking about architecture. That is the job, done in advance, unpaid. Spec work filters out exactly the people you want, because the ones with a pipeline decline and the ones who are available say yes.

What a good builder looks like

You cannot evaluate the code. You can evaluate the person, and the tells are more reliable than most people expect.

They ask about your users and your money before your features. Somebody who leads with “who is this for and how does it make money” is thinking about whether the thing will work. Somebody who leads with the tech stack is thinking about what they would enjoy building.

They tell you not to build things. This is the strongest single signal. A builder whose first instinct is to cut scope is protecting your budget, and they can only do it if they understand the business well enough to know what is load-bearing. Anybody who says yes to your entire list is either not listening or is quoting on volume.

They are specific about what they don’t know. “I have not used that payment provider, I would need half a day to read the docs before I could estimate it” is the sound of somebody who estimates from experience rather than optimism.

They explain a tradeoff without making you feel stupid. Ask why they would choose one approach over another and listen to the shape of the answer, not the content. A person who understands something can explain it to you. A person performing expertise makes you feel like the question was naive.

They want you to own everything. Good ones bring this up before you do. More on that below, because it is the thing that protects you when the relationship ends.

How to check experience when you can’t read code

You do not need to assess their work. You need to assess whether it exists and whether they can talk about it like somebody who lived it.

Ask for something live that real people use. Not a screenshot, not a case study PDF, not a private repo. A URL. Then use it, on your phone, for five minutes. You are not judging the code. You are checking that a finished thing exists in the world with their hands on it.

Ask what broke and how they found out. Everybody who has shipped has an outage story, and they tell it in specific detail because they lived through it, usually with some relish. Somebody who has never shipped will give you generalities about testing and quality.

Ask what they would do differently. A real answer is technical, mildly regretful, and specific. “We put the reporting in the same database as the app and it got slow at about eight thousand records, I’d separate them now.” Vagueness here means they were adjacent to the work rather than in it.

Ask them to explain one decision about your project. You have a prototype, so they can look at it. “What would you change first, and why?” You are listening for whether the answer is about your situation or about their process.

When you take a reference, ask what went wrong. Not whether they were happy. Every reference is happy, which is why they are the reference. Ask “what was the hardest part of working together” and “was there a point where you were worried.” The answer tells you how this person behaves when a project is going badly, which is the only time it matters.

How this goes wrong, and what it costs

You should know the shape of the bad version, because it is common enough to be predictable and it rarely feels bad while it is happening.

It opens with a quote that is lower than everything else you have heard. Five thousand dollars, four to six weeks. You are relieved, because the other numbers were frightening.

Then the change orders start. Login was not in the original scope. Neither was the admin screen, or working on phones, or the thing you assumed was included because it seemed obvious. Each addition is small and each one is defensible in isolation. Six months later you have paid twenty thousand, the app does not work, and every conversation ends with a new date.

The mechanism is worth naming, because it is the same one from the rainmaker trap pointed at you instead of at a builder. You have paid for something that does not work yet, so stopping means losing everything you have spent. That makes the next payment feel rational every single time. Nothing about it is falsifiable from the outside, because you cannot evaluate the code and there is always a reason.

The tell is at the very beginning: a fixed price with no fixed scope. Nobody can accurately quote a project they have not scoped, so a confident low number on a vague description is not a bargain. It is an opening position. Real quotes come with a written scope, and the first question a serious builder asks is what happens when the scope changes.

This is also the failure mode that offshore development is famous for, though the geography is a red herring. Good and bad exist everywhere. The pattern is the same wherever the person sits: low entry price, undefined scope, and your work living somewhere you cannot reach.

Own everything from day one

This is the part I would care about most if I were you, and it is the least discussed.

Your accounts should be in your name, opened by you, with your credit card and your email. GitHub, the hosting, the domain, the database, the payment processor, the app store listings, the analytics. You then invite the builder in as a collaborator.

Not “we will transfer it at the end.” At the end is when relationships are worst. Do it on day one, when everybody is friendly and it costs nothing.

The reason is not that you expect to be cheated. It is that projects end for ordinary reasons. People get busy, they take jobs, they lose interest, they get sick, they turn out not to be a fit. When any of that happens, the difference between an inconvenience and a catastrophe is whether the work is sitting in your accounts or in theirs. If you need somebody’s cooperation to get your own product, you do not have a product. You have a negotiation.

Structure the work so it can be stopped

The single best protection is not a contract clause. It is making the first piece small.

Pay for a scoped first engagement. A few days, a defined outcome, a fixed price. A code review with a written plan. One feature, finished. You are buying information about how this person works, and the information is cheap at this size.

Tie payments to something you can see running. Not to hours, not to milestones described in a document, but to a thing you can open in a browser and use. “Multi-user login works in production” is checkable by you. “Backend architecture complete” is not.

Deploy to production in the first week. Even if it is only what you already have. A project that has not been deployed is a project where nobody knows what is actually true, and it is where six-month disasters hide.

Agree what happens when scope changes, before it changes. It will change, because you will learn things. That is normal and healthy. What matters is that both of you know in advance whether a change means a new price, a swap against something else, or a conversation.

If someone will not work this way, you have learned something useful for the price of asking. People who are confident in their work like small first engagements, because it is how they get hired everywhere.

What you owe them

The last part gets skipped in every article like this, and it is half of whether the project works.

A good builder is going to be evaluating you too, and the founders who get the best work are not the ones who pay the most. They are the ones who are easy to build for.

Decide things. The most expensive thing a client does is go quiet for a week on a question that blocks the work. If you cannot answer quickly, say so and give a date.

Pay on time, without being chased. This one is unglamorous and it moves you to the top of somebody’s list permanently.

Say what success looks like in numbers. “I want fifty of the people on my waitlist to complete a session in the first month” gives a builder something to make decisions against. “Make it great” does not, and it means every small decision comes back to you.

Don’t ask for free work. Not a free prototype, not a free estimate that requires real analysis, not a free “quick call” that is actually a consulting session.

Let them tell you no. If you hire somebody for judgment and then overrule it on every point, you are paying professional rates for typing. The value is in the disagreement.

The founders who get the best work are the ones who are easy to build for, and it costs nothing to be one.

This can be a good deal for both of you

There is a version of this that is genuinely fair, and it is the common one when both sides behave.

You get software that works, built by somebody who has done it before, for a price you agreed in advance and can plan around. They get paid properly for work they are good at, on a project where the person across from them makes decisions and pays invoices. Nobody gave anything away. Nobody is waiting on a windfall that may not come.

That is available to you right now, and the prototype in your browser is what makes it available. You are not asking somebody to believe in an idea. You are asking them to finish something that already exists, which is a normal transaction between adults and is priced accordingly. If you want a sense of what that costs before you start, we publish our numbers.

The thing to protect on the way in is fairness in both directions. Pay for work, own your accounts, keep the first piece small, and be the client somebody wants to keep. None of it is complicated. It just has to be decided before you are three months and twenty thousand dollars into finding out.

Frequently Asked Questions

Can a developer take over a project I built with AI?

Yes, and it happens constantly now. A working prototype is a real asset because it answers questions a written specification leaves open. Expect the first engagement to include a review of what exists and a decision about how much to keep. Some of it usually survives, some gets rebuilt for structural reasons, and a good builder will tell you which is which and why before charging you for either.

How do I know if a developer is any good if I can't read code?

Evaluate the person rather than the code. Ask for a live URL that real people use, not a screenshot or a case study. Ask what broke on a past project and how they found out, because people who have shipped tell that story in specifics. Ask what they would do differently. Then take a reference and ask what went wrong rather than whether they were happy.

Why won't developers work for equity?

Because equity in a pre-revenue company has no buyer, so it cannot be sold, spent, or valued. Offering it reads as a request to work for free with extra paperwork, and experienced builders have already collected several. Equity becomes a real conversation once there is revenue and a documented agreement. The Equity Tell covers why the exchange only ever runs one direction.

Why did my software project cost four times the quote?

Almost always because the price was fixed and the scope was not. Nobody can accurately quote work they have not scoped, so a confident low number on a vague description is an opening position rather than an estimate. Every addition afterward is defensible on its own, and stopping means losing what you already spent, which makes each next payment feel rational. Ask for a written scope and agree in advance what happens when it changes.

Who should own the code and hosting accounts?

You should, from day one. Open the GitHub, hosting, domain, database, and payment accounts yourself, on your card and your email, then invite the builder in as a collaborator. Not because you expect to be cheated, but because projects end for ordinary reasons and you do not want to need somebody's cooperation to reach your own product. Good builders raise this before you do.

How much should I pay for a first engagement with a developer?

Enough to buy real information and little enough that losing it does not hurt. A few days of scoped work with a fixed price and a defined outcome, such as a code review with a written plan or a single feature finished and deployed. You are buying knowledge of how this person works. Anyone confident in their work will welcome a small first piece, because that is how they get hired everywhere.