A lot of founders quietly dread the first time they hand their code to a developer. You built something with an AI tool, it works, people are using it, and now you want help. So you find a developer, hand them the code, and they take one look, breathe in, and quote you for a rewrite. The thing you built and shipped is, apparently, worthless.
I want to take some of the fear out of that moment, because it’s more predictable than it feels. AI tools produce a lot of code very quickly, and speed is the point. What they’re not doing while they type is worrying about the person who comes after you. The code that runs your app and the code another human can pick up and change aren’t the same thing, and the gap between them is where handover goes wrong.
Here are the things a new developer, a buyer or an investor will look at, and how to check each one before they do.
1. Can someone run it from a clean clone?
This is the test that matters most, and the one people skip. A clone is a fresh copy of your code, pulled down onto a machine that has never seen it. The real question of handover is whether a developer can take that fresh copy, follow your instructions, and get the app running.
It fails in the same places every time. Setup steps that live only in your head. An env file (the file that holds your configuration and keys) that never got written down, so the app falls over looking for a value that’s not there. Or the quiet killer: it runs on the machine you built it on, because of something installed there months ago that you have long forgotten, and nowhere else.
To check it: try to run it yourself on a different computer, one that has none of your tooling on it. If you cannot borrow a machine, write down every single step from empty folder to working app, in order, assuming nothing. Then look at how long the list is and how many steps you would struggle to explain. That list is what a new developer starts from.
2. Is it organised, or does one change break three things?
Good code is arranged so that a change in one place stays in that place. The worry is the opposite: you fix a bug on the signup page and the payment page quietly stops working, because the two were secretly wired to the same thing in a way nobody meant.
AI tools have a particular habit here. Instead of writing a piece of logic once and using it everywhere it’s needed, they often write it out several times. It all works, so you never notice. Then the day comes to change how something behaves, the fix has to be made in every copy, and if you miss one, the app disagrees with itself.
To check it: pick something that appears in more than one place, like how a price is worked out or how a date is shown. Ask your AI tool, or the developer you are talking to, to find every copy of that logic. If the answer is one shared piece, that is a good sign. If it is scattered, every future change costs more than it should.
3. Are the important paths tested?
A test is a small piece of code that checks the app does what it’s meant to. You don’t need many. A handful around the paths that matter, signup, payment and whatever your app is for, changes the picture completely.
Two reasons. First, a test catches the moment a change breaks something, before your users do. Second, and this is the part people miss, a test is a written record of what’s supposed to happen. A new developer reads your payment tests and learns how payment is meant to work, without guessing from the code or asking you.
To check it: ask whether there are any tests at all, and if so, whether they cover signup, payment and the core action. Zero tests is common in AI-built apps and not a disaster on day one. It does mean every future change is done by hand and by hope, which a developer will factor into their quote.
4. Is the dependency list sensible?
Your app leans on other people’s code, called dependencies or packages, and they’re listed in a file called package.json. This is one of the tidier things to check and one of the more telling.
AI tools reach for a package the way you might reach for a whole toolbox to tighten one screw. They pull in a library to use a single line of it, then never remove it. Over a few weeks you end up carrying packages you don’t use, two packages that do the same job, and the occasional one that has been abandoned by whoever wrote it and no longer gets security fixes.
To check it: run npm audit in the project. It reads your dependency list and reports known security problems in plain terms. Then read down the list of packages and ask, for each one, what it is for. The ones nobody can account for are the ones to look at first. Every dependency is code you did not write, running inside your app, so a shorter honest list is worth more than a long mysterious one.
5. Is there a README that maps the place?
A README is a short text file that sits at the top of your code and tells a newcomer what they’re looking at. Not a manual. A map. If it answers four questions it has done its job: what’s this project, how do I run it, where do the main things live, and how does it get deployed (put live for users).
Without one, a developer’s first day is spent reconstructing what you already know, and they will bill you for that day. With one, they’re productive by the afternoon.
To check it: open your project and see if a README exists. If it does, read it as though you had never seen the app, and notice where it leaves you guessing. If it does not, writing one is the single highest-value hour you can spend before any handover.
6. Is your configuration written down, safely?
Every app needs configuration: which database to talk to, which keys to use, which email service. A new developer has to recreate all of that to run the app at all. The trick is to write down what the settings are and where they come from, without writing the secret values themselves into the code.
This matters twice over. Secrets committed into the code are a security problem, because anyone who sees the code sees the keys. Configuration that exists only in the memory of the original builder is a handover problem, because nobody else can set the app up. What you want is a list of every value the app needs and where a new person would get it, kept separately from the code, with the secrets themselves never checked in.
To check it: find where your keys and settings live. If they are typed directly into the code, that is worth fixing on its own terms. If they live outside it but nobody has written down what they all are, make that list now.
Why this is worth an afternoon
All of this is invisible while the app is running for you. It becomes visible the moment someone with money is deciding whether to trust it. A buyer’s technical advisor will clone the repo and try to run it. An investor’s diligence will ask who else could maintain this. And the developer you want to hire is quietly costing all of the above while they decide whether to quote you a fair price, a padded one, or nothing at all.
None of these are judgements on how you built the app. They’re the ordinary, boring gap between code that works and code that travels, and every one of them can be closed. This is one slice of a bigger picture, and if you want the whole of it, I keep the full launch checklist up to date.
Where to start
Do the clean-clone test first. Everything else is downstream of it. If you can hand someone a fresh copy of your code and they can get it running from your written instructions alone, you’re most of the way there. If they can’t, that tells you exactly what to fix, in order.
If you would rather not do it alone, this is the part I help with. I can go through your app the way a careful buyer or a new developer would, tell you plainly what someone taking it over would find, and either fix the worst of it or get it into a state where handing it on is calm rather than frightening. Either way you’ll know where you stand before anyone else does.
