How to check an app's code and tech before you buy it

Checking the revenue tells you the app earns money today. The tech check tells you whether it will keep working once the seller has gone. Plenty of small apps make money and still run on one person's laptop, an old server nobody else can log into, and a bank card that expires next year.

None of that shows up in a screenshot, so open the code and the dashboards before you agree a final price.

Ask for read-only access to the code repository. On GitHub the seller can add you as a collaborator with read rights, and remove you again if the deal falls through. A zip file sent over WhatsApp is weaker proof, because you can't see the history of who wrote what, or when.

For hosting, payments and the app store accounts, a video call where the seller shares their screen is usually enough at this stage. Sign their NDA if they ask.

Nearly every app pulls in free open-source packages, and nobody minds. Your worry is the rest of the code. Did the seller write it, or did a freelancer from Upwork or an old cofounder? If someone else did, ask for the paper where they signed their rights over.

Licences matter too. GitHub's own documentation says that code with no licence falls under default copyright, so nobody may reproduce, distribute or build on it without permission.¹ If the app is built on a repo the seller found online with no licence, or on a paid template meant for one site only, you could be paying for a problem.

Hand your developer the repo and the README, nothing more. Can they get it running on their own machine in an afternoon? If they keep needing the seller on a call, then the know-how lives in the seller's head and walks out with them.

Then ask how a change goes live. A good answer sounds like “I push to the main branch and the host deploys it.” A worrying one is “I copy the files to the server by hand.” Ask the seller to make a small change while you watch, like the text on a button, and push it to the live site.

Code goes stale quickly. Take Node.js, which a lot of web apps run on. Its own site tells you to run live apps only on its long-term support versions,⁴ and right now that means 22, 24 or 26. Anything from 20 down gets no more security fixes.⁴ Your developer can check which one the app uses in a minute.

For the packages, they can run npm audit. It sends the list of dependencies to the npm registry and reports any known security holes.³ Some can't be fixed automatically, and npm warns against forcing fixes unless you know what you're doing, because that can pull in major new versions that change how things work.³

A long list isn't a reason to walk away. Ask your developer how many days it would take to bring everything up to date, then put a naira figure on those days and bring it into the price talk.

Small builders often paste secret keys straight into the code: a Paystack secret key, a database password, an email API token. Anyone who has seen the repo has them.

GitHub runs secret scanning for free on public repos, and it checks the entire history on every branch for API keys, passwords and tokens.² On a private repo, ask your developer to run a scanner over the full history, since a key deleted last year is still in the old commits. Every key you find goes on the handover list, to be replaced the day the app becomes yours.

Write down each service the app needs to run. Hosting, the domain, the database, email sending, SMS, payments, analytics, push notifications, the Google Play and Apple developer accounts. For each one, note whose name it's in, which card pays for it, what it costs a month, and whether it can be transferred.

Watch the dollar bills. A $40 server paid with a dom card looks small until the exchange rate moves, and then your profit moves with it. Ask to see the last three invoices for each service. Our handover guide covers how each account moves to the buyer once you've paid.

Then just ask. When did the app last go down, and what fixed it? Which file do you avoid touching? Are there backups, and has anyone ever restored one?

Sellers who know their app answer with dates and names. If all you get is “it never breaks”, dig a bit more.

Put each problem on a list with a rough cost next to it. Some you'll knock off the price. Some the seller can fix before closing, and the rest go on the handover checklist in the contract. Pay through escrow, and don't confirm until the code, the accounts and the new keys work for you.

On Prow: Before a project with a link can be listed for sale on Prow, the seller has to prove they own it, for example with a DNS record or a file on the website, or a file in a public GitHub repo. Buyers can sign the seller's NDA, ask questions in private and make offers. The money is held in escrow with EscrowPay until you confirm you have everything. When it sells, you and the seller each pay Prow 1.5% of the price, at least ₦5,000 each, and EscrowPay's own fee is split between you.

• Read access to the repo came before any talk of price.
• Code the seller didn't write has a licence or a signed handover.
• Your developer ran it using only the README.
• Node or whatever it runs on is still supported, and npm audit has been run.
• Old commits were searched for keys, and all of them get replaced at handover.
• You know who owns each account, what it costs and how it moves.
• Each problem has a price, and the price is in the deal.