You've inherited a half-built app. Inspect it before anyone quotes a rewrite.

The call you're about to make

It usually goes like this. The project started well. Then the freelancer got a full-time job, or the agency was bought, or the budget ran out at about seventy percent. You have an app that logs in, shows some screens and does about half of what it was supposed to. You call a new developer, they look at it for an hour, and they say the safest thing is to start again.

Sometimes they're right. Half-built software can be in a state where finishing it costs more than rebuilding it. But "start again" is also the easiest thing for a new team to say. It's their code, their choices, no surprises. And it's the most expensive answer for you.

A rewrite quote without an inspection is a guess with a number on it. So treat it like buying an old house: before anyone talks about knocking walls down, get it surveyed. The report should cover the same handful of areas every time, and you should be able to read it yourself.

Get the keys in your name first

Before any inspection, make sure you can actually get in, and that you own what you're paying for. Half-finished projects often live in the previous developer's accounts. That's normal while work is going on. It's dangerous once they've gone.

The list is longer than people expect:

• The code repository, with full history, not a zip file.
• Hosting and cloud accounts, including the database and file storage.
• The domain name and DNS.
• App store developer accounts if there's a mobile app. These should be in your company's name.
• Third-party services: email sending, payments, maps, analytics, login providers, AI APIs. Each has an account and a bill somewhere.
• Design files, documents and credentials the previous team kept.

If the previous developer won't hand things over, or can't be reached, stop and read your contract before anything gets heated. It should say who owns the code and the accounts. If it doesn't, or it's unclear, that's a conversation for a lawyer, and it's better to have it now than after you've paid someone to build on top of code you may not have clear rights to.

Move everything into accounts your company controls and change the passwords and keys as you go. If the previous developer is reachable and on good terms, ask for a short handover call. Our note on what a useful software handover should include is a good list to work from, even if the handover is happening late.

Does it build, and can someone else deploy it?

This is the foundation. Can a developer who has never seen the project take the code, run it on their own machine and put a new version live, following written steps?

If yes, you're in a much better position than you might think. If no, find out why. Sometimes it's a missing configuration file or a secret only the old developer had, which is fixable in a day. Sometimes the live version was changed directly on the server and never put back into the code, so what's running and what's in the repository don't match. That's worth knowing before anyone makes promises.

While you're in the foundations, do a quick safety pass too. Are passwords, API keys or payment keys sitting in the code? Are there admin pages anyone can reach without logging in? Is customer data stored somewhere public by mistake? None of this needs a full security audit yet. It's the equivalent of the surveyor noting exposed wiring: you want to know about it before you move in, and some of it should be fixed this week whatever you decide.

Also check what versions of frameworks and libraries it uses, and whether they're still supported. Old isn't automatically bad, but unsupported is a cost you'll pay later.

The data and the connections

Next, the parts that are hardest to redo.

The data. Is there real customer data in it yet? How is it structured, and does that structure match how your business actually works? Is it backed up, and has anyone ever restored a backup? If there are live users, the data is often the most valuable thing in the project, and the strongest reason not to throw it away.

The connections. Which integrations actually work? Half-built apps often have payment, email or a partner API wired up for the demo, but not for real. A payment screen that works in test mode is not a payment integration. List each connection, whether it runs against the real service, and what happens when it fails.

What's finished, what's faked, and what's missing

Now compare the app with what you actually need. Not the original spec, which may be out of date, but what the business needs now.

Go feature by feature and put each one in one of three columns. Finished and working. Present on screen but not really working (hard-coded data, buttons that don't do anything, screens that only work for one user). Missing entirely. This is the part of the report you'll use most, because it turns "half-built" into a real list.

Look at the tests while you're there. Are there any? Do they pass? And ask how the code was written: if the previous team leaned heavily on AI tools, that isn't a problem in itself, but you want to know where, and who reviewed it. Asking how AI touched your code has the questions.

Finish, fix or rebuild

With the report in hand, the decision usually gets clearer.

Finish when it builds and deploys, the data model fits your business, and most of what's missing is new features rather than broken foundations.

Fix, then finish when the foundations are mostly sound but something specific is wrong, such as an integration done badly or a part of the data model that needs reworking. Fix that part on purpose, then carry on.

Rebuild when it can't be built or deployed reliably, the data model fights how your business works, or the technology is unsupported. Even then, a rebuild can often reuse the designs, the data and the lessons, and it can happen in pieces rather than all at once.

Whichever way it goes, any quote you get afterwards should refer to the report. If a developer recommends a rebuild, they should be able to point to the parts of the inspection that led them there.

We build web applications and mobile apps, and we're regularly asked to look at projects someone else started. If you've been left with a half-built app and a rewrite quote, send us what you have and we'll tell you what we see.

Related work: PatientIQ.