My app is half built. Can an AI tool finish it, or do I need a developer?

This page may contain affiliate links from which Blur Studio earns commissions.

A half-built app is a specific, stressful kind of problem, because the money already spent makes every next decision feel higher-stakes than it should. The instinct is to find the fastest possible path to "finished" without spending more, and AI app builders get searched for specifically because they promise exactly that: describe what's missing, and have it built quickly and cheaply. That can work, but it depends entirely on something you need to check first, not assume: whether the tool you're considering can actually pick up an existing, half-finished codebase at all, rather than only building fresh from a description.

What to actually do first, before any tool decision

1. Get the actual code and the logins from whoever built it, in writing, today, not "whenever they get a chance." This is the single most common point where a stalled project gets permanently stuck: the person who built it stops responding, and without the code and access, there's nothing to hand to anyone else, AI tool or developer.
2. List what actually works and what doesn't, as specifically as you can. "The login page works, the dashboard loads but the save button does nothing, the payments section was never started" is a genuinely useful list. "It's about 70% done" is not, because it tells the next person nothing about where the actual gaps are.
3. Get a developer review, even a short, paid one specifically scoped to answer "is this worth finishing," before committing to any next step. This is usually a small, fixed cost compared to either finishing or rebuilding blind.
4. Decide between fixing, finishing or rebuilding based on that review, not on how much you've already spent. The money already gone is gone regardless of what you do next; it shouldn't drive the decision about what to do now.
5. Set a fixed scope for whatever comes next, written down, before paying anyone else anything. A second open-ended engagement is how a half-built project becomes a project that's half-built twice.

Can an AI app builder actually finish someone else's code?

This is the question that matters most, and it's the one most people skip past because the idea of describing the missing piece in chat and having it appear is appealing. Different AI app builders are built differently: some are designed specifically to generate a whole application from a description and manage it within their own system end to end, and may not be built to import and continue a codebase that originated somewhere else. I looked for a clear statement on Emergent's own pages about whether it imports and continues existing codebases and could not confirm one either way, so treat this as an open question to ask directly, not something to assume works, before you plan a rescue around it.

The practical way to find out, rather than guessing from marketing copy: ask Emergent's own support directly, "can I import this specific codebase and continue building on it," before spending time trying. If the answer is no, that's useful information immediately, not a failed afternoon of trying to force a tool to do something it isn't built for.

A worked example: a half-built booking portal

Say you paid a freelancer for a customer booking portal, got a login screen and a basic calendar view, and then the freelancer went quiet with payments, notifications and the admin dashboard never started. Collecting the code and logins first, then listing exactly what works (login, calendar view) versus what's entirely missing (payments, notifications, admin dashboard) turns a vague "it's half done" into something a developer, or a decision about an AI tool, can actually act on.

A developer review at that point, usually a fixed, modest cost for an experienced developer to actually read the code and tell you honestly what state it's in, answers the question that actually matters: is the existing login and calendar code reasonable to build on, or is it tangled enough that starting the remaining pieces fresh, even reusing the same overall plan, is genuinely faster. That answer, not which AI tool is trendiest, should drive what happens next. If the existing code turns out to be a reasonable foundation, that's also the point to ask a tool like Emergent directly whether it can import and work with that specific codebase, now that you know precisely what you're asking it to continue.

What a good developer review should actually cover

Not every "review" is equally useful, and it's worth knowing what to ask for so you don't pay for a vague opinion. A genuinely useful review should tell you, specifically: whether the existing code actually runs and does what it appears to do, how clean or tangled the underlying structure is (a rough but honest signal of how painful it would be to keep building on), which of the missing pieces are small and which are substantial, and a realistic estimate of effort for finishing versus rebuilding the stuck parts. A review that just says "it's okay" or "it's a mess" without specifics isn't worth paying for; push for the details above before you commit to one.

It's also worth asking the reviewer directly whether they'd be comfortable continuing the work themselves, or whether they think a different approach, including an AI builder, makes more sense for what's left. A good developer will tell you honestly when a simpler tool is the right call for the remaining scope, rather than always recommending more development work.

What I'd actually tell you

The emotional pull in this situation is to treat the money already spent as a reason to keep pushing the same direction, finish it somehow, anyhow, because starting over feels like admitting the first spend was wasted. I'd push back on that framing directly: the money is already spent either way. The only question that matters now is which path, fixing what exists, finishing it as-is, or rebuilding the stuck pieces, gets you a working app fastest and most reliably from here, and that's a question a short developer review answers far better than guessing.

Where I'd be specifically cautious: don't hand a stalled, half-understood codebase to an AI tool and hope it figures out the gaps on its own, even if the tool technically accepts an import. AI tools work from what's described to them, and a half-built app full of undocumented decisions from someone else is a much harder thing to describe accurately than a fresh idea. A human review of what actually exists first makes whatever comes next, AI tool or developer, far more likely to succeed.

How to actually ask for the handoff, without burning the relationship

If the original builder is still reachable, even if slow or difficult, the request that gets the fastest response is specific and low-effort for them to fulfill: "please send me a zip of the current codebase and a list of every login, admin panel and account involved" is something they can act on in minutes. A vaguer "can you send everything over" invites delay. If there's an outstanding dispute about payment or scope, it's worth separating that conversation from the handoff request itself, since tying them together often stalls both, and you want the code and access regardless of how the payment disagreement resolves.

If the builder is genuinely unreachable, check what you already have access to directly: your own hosting account, domain registrar, any third-party service (payments, email, database) you set up or paid for yourself. Often more of the actual infrastructure belongs to you, under your own accounts, than it first appears, even if the application code itself is harder to recover.

When to skip the AI route, and call a developer directly

If the app holds payments, customer data, or anything with real compliance weight, skip straight to a developer review rather than experimenting with an AI tool's import capability first, since the cost of a mistake there is higher than the time saved. The same applies if the existing code is tangled enough that even the original builder struggled to explain what state it's in; that's a sign the project needs a careful human read before anything else happens to it.

This is exactly the situation I get called into most often, not a fresh idea, a stalled one. I'll look honestly at what exists, tell you plainly whether it's worth finishing or better rebuilt, and quote a fixed scope for whichever is actually true, rather than defaulting to "let's finish what's there" because that's the answer that sounds less wasteful. Get in touch with what you have and I'll give you a straight read on it.

One more thing worth saying plainly: a stalled project is a common, ordinary thing, not a sign you did something wrong hiring the first builder. Development projects stall for all kinds of reasons, a freelancer takes on too much, a studio reprioritizes, the original scope turns out to have been underestimated, and most of them are fixable once someone takes an honest, current look at what actually exists rather than continuing to guess from the outside.