Hiring Someone to Finish a Half-Built AI App

One owner shopping for this exact work wrote in a public Reddit post: “Looking for an AI vibe coder to fix an unfinished vibe coded job. Just 25% left to go, should be easy.”

People do this work, they are findable, and the job has a shape. The percentage contains the assumption that makes every price come back wrong.

Hiring someone to finish an unfinished vibe coded app works when the price attaches to named finished things rather than to a percentage. Estimates land higher than owners expect because the missing part is usually a category that was never started: across 21 AI-built apps audited in 2026, only 3 had any way to take money.

Everything published by another company on this page was read on 16 August 2026 and is dated where it appears. The counts come from AxonBuild’s audits of 21 third-party AI-built apps, run in June and July 2026. No agency or freelancer was contacted for a price, and nothing here was produced by running or rebuilding an app. If what you want is a developer to maintain the app and ship future changes on an ongoing basis rather than finish one named thing, that is a different purchase with a different shape, and worth separating before you talk to anyone.

”Nearly finished” means four different things

People looking for someone to finish an app someone else started arrive in one of four situations. They are priced differently, and only one of them is a clean finishing job.

Row two is its own problem, because the constraint is not engineering. When the person who built it stopped being available, what decides the price is whether you hold the accounts: the repository, the database, the hosting, and the domain. Everything else waits on that.

Row three is the one most owners are in without knowing it, and the rest of this page is mostly about how to tell.

Row one has a wrinkle worth naming. If the builder is still producing code but the app gets worse each time, you are not paying for the next feature any more, you are paying for the accumulated cost of every change so far. Why an AI-built app gets harder to change the longer it runs covers the mechanism. Hiring on the build side, where nobody has started yet and the whole thing is written from a blank page, is a different conversation with different suppliers.

Why “just 25% left” is not 25% of the work

The 25 percent figure describes the screens an owner can see. The work behind it is not proportional: across 21 AI-built apps audited in June and July 2026, the categories owners count as nearly done were often absent entirely, and going from nothing to working costs more than finishing.

Almost everyone selling this work publishes the same fraction. MEV, an agency that ranks other agencies for this job in a post dated 4 June 2026 and updated 3 August 2026, writes: “AI builders like Replit get a vibe-coded app 70 to 80% of the way; the missing 20 to 30% is the part that survives real users without dropping logins or double-charging cards, and that’s the work these agencies do.” GVM Technologies, in a post dated 28 July 2026, publishes $20 to $100 a month for the AI tool subscriptions used to validate an idea and $6,000 to $60,000 or more for a developer-built production version, and argues that the fastest fix for a broken vibe-coded app is usually a rebuild of the affected part by someone who understands what the app has to do, rather than repairing it line by line. Prices checked 16 August 2026.

Notice who is publishing the fraction. Both companies sell the remainder. That does not make the number wrong, but it does mean nobody selling it has a reason to say what the remainder actually contains, and neither page does.

Both pages are credited by address rather than linked, because both sell finishing and rebuild work to the same buyer this page is written for: mev.com/blog/best-agencies-for-turning-your-vibe-coded-app-into-a-production-ready-product and gvmtechnologies.com/vibe-coding-vs-hiring-a-developer/. The MEV post ranks five companies, itself first, and publishes one price for one of them, a flat $1,500 audit with a two-week turnaround at Red Leg Dev. One figure on one directory is worth knowing about and is not a market rate.

A visible percentage does not measure the unfinished work behind the screens. That mismatch is why a supplier’s estimate can read as an insult to somebody holding a percentage.

There is a cost that shows up in the same stretch. Slashdot’s summary of 404 Media’s reporting on the developers paid to fix vibe-coded software, published 13 September 2025, names Swatantra Sohni, who built VibeCodeFixers.com and identifies “credit burn” as the recurring problem: money spent on AI usage during the final 10 to 20 percent of development, when adding a feature breaks something that already worked. The 404 Media original at 404media.co/the-software-engineers-paid-to-fix-vibe-coded-messes/ sits behind a paywall and was not read for this page, so the Slashdot summary is what is cited. VibeCodeFixers.com is named and not linked, on the same rule as the agencies above. Owners recognize credit burn immediately, because they have already lived through it and assumed it was their own prompting.

The mechanism underneath all of this is unglamorous. A builder produces what it was asked for. Nobody asks for the parts that only matter once other people use the app, so nobody gets them, and the demo looks complete because a demo has one user who already knows the password. The same argument appears in MVP vocabulary, where the sticking point is usually described as the last stretch of an MVP rather than a percentage of an app.

What the AI builder probably never started

This is the part nobody publishes. Across the 21 third-party AI-built apps AxonBuild audited in June and July 2026, the audit recorded which parts of an app existed at all before scoring them. That record is a count of what AI builders produce, and it is lopsided.

The caveat belongs right here rather than in a footnote, because without it the table reads as something it is not. “Did not apply” in that study means the surface did not exist: no payments, no AI, no server. An app can lack a way to take money because it was never meant to take money, not only because nobody has built it yet. So each row counts what AI builders produce, and each row is an upper bound on “never started” rather than a measurement of it. The full cohort rules and method behind these counts sit on the page that owns the corpus.

Read it that way and it answers the question the percentage was standing in for. When an owner says a quarter is left, that quarter is rarely a quarter of the screens. It tends to be the part that takes money and the part that knows who the user is, and on this evidence those two are the likeliest of anything to be sitting at zero.

Zero to one is a different job from three-quarters to one, and it is the difference an owner cannot see from the screens.

The most finished app in that study makes the point without any statistics. It scored 81 out of 100, the top of the range published on the security statistics page linked above, with no critical findings at all. It still had no error boundary anywhere, so a single uncaught render error blanks the whole app for the user. It had no test framework and no test files. Its build never ran a typecheck, and nothing at all gated the automatic deploy. Four medium findings, no drama, and an owner who could not have sold access to it. An 81 there measured an app with nothing dangerous in it, which is a different property from being ready to hand to customers. That same app has a second story about scanner noise against real risk, which belongs on the page about what verified findings actually mean.

Turn “nearly done” into a list someone can price

Five questions convert a percentage into something countable. None of them need you to read code, and every one maps to something the audit corpus measured.

1. 01 Can a second account sign up, log in, and see only its own things? Authentication existed on 14 of the 21 audited apps and authorization on 14, and in 7 of the 21 a logged-in user could read or write another customer's data.
2. 02 Does a payment actually move money into your account, or does the button only look like it does? A revenue and billing surface existed on 3 of the 21.
3. 03 When something goes wrong for a user, where does that get recorded, and who sees it? In 17 of the 21, errors were recorded nowhere at all.
4. 04 Is there a copy of yesterday's data anywhere? The corpus records backups and staging by example rather than by count, which is itself the finding: it was rare enough that a count would have been misleading.
5. 05 Does anything check a change before it goes live? At least 17 of the 21 had no deploy gate, and at least 18 of the 21 had no working automated test anywhere.

Write down the five answers. Count the noes. That list is the thing to hand a supplier, and it works with any of them: a marketplace freelancer, an agency, or a fixed-price seller. It also survives the conversation, because each answer is a fact about your app rather than an opinion about how far along it is.

The reframe is the whole point of doing it. A percentage cannot be priced, because two people holding the same percentage are describing different amounts of work. A count of five yes-or-no answers can be priced by anyone, in about ten minutes, without touching the code. If you would rather pay someone to produce that list properly before committing to the finishing work, a paid read of the code is a separate and much smaller purchase than the finishing itself.

What the person picking it up will ask for

Four things, and the order matters, because the first one blocks everything else.

Access to the accounts, first: the repository, the database, the hosting, and the domain. Then whatever the builder exported, in whatever state it is in. Then an honest answer about what has actually been tried by somebody other than you. Then the list from the section above, which is the only part of this that takes any thought.

Three things reliably make a finishing job cost more, and you can check all three yourself before anyone prices anything.

Nobody can get into one of the four accounts. This is the expensive one, and it is not an engineering cost at all. If the app was built inside someone else’s login, or on a plan that expired, the work stops until that is resolved, and no price given before it is resolved means anything.

There is nowhere to try a change except the live app. Every change then lands on real users first. Someone can fix this, but it is billable work before any of the work you actually wanted.

A real key or password is sitting in the code’s history. Cleaning that up means rotating live credentials, which means brief downtime, which means agreeing a time with you. Of the 21 audited apps, 6 shipped a real secret and 3 had one permanently in git history.

Only the first of those three is something you can move on today, and it costs nothing. Track down whoever holds each account and get yourself added as an administrator on all four. Write down which of the four you still cannot get into. That single piece of homework is usually worth more to the price than anything else you can do before the first call. The full list of what to give whoever picks it up, and what the same situation looks like from the developer’s side of the table, are both worth reading separately.

Finish it, or build the part that was never built?

Finishing is the right frame when the app runs and the missing thing has a name. When the missing part is a whole category, part of the work is a first build rather than a continuation, and calling it finishing is what produces a price nobody believes. Three or four noes on the five checks above means construction.

That is the only fork this page decides. If the checklist above came back with four yeses and one no, you have a finishing job, and it is priceable today. If it came back with three or four noes, at least some of the work is construction, and the honest sequence is to build those pieces one at a time rather than buying “the rest of it” as a single item.

The bigger question, whether to keep the code at all or start the affected part again, is a genuinely separate decision with its own arithmetic, and it deserves more than the two paragraphs it would get here.

What AxonBuild charges to finish part of an app

The price attaches to a named finished thing, never to a percentage. That distinction comes first because it is the whole difference between a number you can hold someone to and a number that moves.

Finishing a feature that does not exist yet is quoted after AxonBuild reviews the code. If the app already works and one existing behavior is broken, a new client may qualify for a $99 first repair. It is available once for one agreed blocker, is completed within three business days once access works, and is paid after you see it work. AxonBuild publishes the current price and boundaries for that first job on its own page.

A half-built app is usually larger than one repair. Where the app needs a way to take money, a way to know who the user is, and a way to find out when it breaks, that is several connected pieces of construction. AxonBuild quotes that work after reviewing the code rather than guessing from a description.

The boundaries belong here rather than in fine print. This does not cover a whole rebuild, an app nobody can get into, or an idea with no code behind it yet. It produces no written review of the app, and it carries no promise that the app is finished, safe, or ready in any general sense. What a whole cleanup costs, worked out piece by piece, is a different calculation from what finishing one thing costs, and worth doing separately if the checklist came back mostly noes.

Common questions about getting a half-built app finished

Can I hire someone to finish my vibe coded app?

Yes, and there is now a small market of people who do only this. Supply is rarely the constraint. Most owners describe the job as a percentage, which nobody can price, so the first real step is converting that percentage into a list of named things that do not work yet.

Where you find them matters less than what you hand them. Upwork and Fiverr both hold category pages on the search results where this question gets asked, at upwork.com/hire/vibe-coding-developers/ and fiverr.com/vibe_coding. Neither is linked here, and neither was read: both returned an access error on 16 August 2026, and both sell the same buyer the same work this page describes. A marketplace category page lists people. It cannot tell you what your own app is missing, which is the part you have to bring.

Are vibe coders being hired?

Yes, and there is dated reporting on it. Slashdot’s summary of 404 Media’s September 2025 reporting names a Fiverr seller, Hamid Siddiqi, who says he works ”… with around 15-20 clients regularly, with additional one-off projects throughout the year”, and describes VibeCodeFixers.com, a site connecting owners with developers, as having nearly 300 developer profiles while matching “30-40 vibe code projects”.

Those are small numbers, and they are the point. The market exists and it is early, which is why prices vary so much between suppliers who look similar from the outside.

How do I know if my app is nearly finished or barely started?

Answer the five questions in the checklist above. If a second account can sign up and see only its own things, money actually arrives, errors are recorded somewhere, yesterday’s data exists somewhere else, and something checks a change before it ships, you are nearly finished. Four noes out of five means most of the remaining work has not been started.

The reason this beats a percentage is that all five are yes-or-no, and none of them require an opinion about the code.

Can the AI builder finish the app itself?

Sometimes, for the shape of work it is good at, which is visible features on screens that already exist. It reliably struggles with the parts that span the whole app, like permissions and payment correctness, because those need consistency across files rather than one more screen.

The signal to watch is whether each round of prompting leaves the app better or the same. When new prompts break about as much as they fix, more prompting is the expensive option. Whether an AI builder can fix its own code has a longer answer than this one has room for.

What do I give the developer maintaining my app and shipping future changes?

Access to four things: the repository, the database, the hosting, and the domain. Then whatever the builder exported, and an honest list of what has never been tried by anyone except you.

Access is the part that stalls. If the app was built inside somebody else’s account, or on a plan that lapsed, sort that out before the first call rather than after the first price.

Is it cheaper to finish a half-built app or start again?

Finishing is cheaper when the app runs and the missing pieces have names. Starting the affected part again gets cheaper as the number of missing categories grows, because building three things from nothing inside code shaped around none of them is slower than building them cleanly.

There is no percentage threshold that decides this, which is why anyone who offers one is guessing. The deciding question is how many of the five checks come back no, and whether the code you would keep is code anyone can change safely.

How much does it cost to finish an app that is half-built?

It depends on whether the unfinished part is one feature or most of the product. AxonBuild quotes unfinished features and connected work after reviewing the code. If the app already works and one narrow behavior is broken, a new client may qualify for a $99 first repair.

For hourly rates, agency minimums, and how the four hiring routes compare on total cost, what it costs to finish an app someone else built owns the money question. What nobody can price honestly is a percentage, from any supplier, at any rate.