A due-diligence checklist for buying someone else's code
Buying a half-built project is not like buying a business. There's no revenue to verify, no traffic to audit, no P&L to argue about. What you're buying is a head start — and the whole risk is that the head start turns out to be shorter than it looked.
Here's the order to check things in. It's deliberately front-loaded: the first four checks take about five minutes and kill most bad deals before you've read any code.
The four that come first
1. Does the seller actually own it? The single most expensive mistake. Ask directly: did you write all of this, was any of it written for an employer, and is any of it under contract to someone else? Code written on company time usually belongs to the company, and a side project built while employed is the classic dispute. Look for copyright headers naming someone who isn't the seller.
2. What licence is it under, and what does that let you do? A permissive licence (MIT, Apache-2.0, BSD) means the public copy stays public — so what you're buying is the seller's *work*, not exclusivity, and you must keep the attribution. Copyleft (GPL, AGPL) means a proprietary product needs the author to relicense, which only the copyright holder can do. No licence file at all is the interesting case: it means all rights reserved, so the author still holds everything and can grant you a genuinely exclusive transfer.
3. Does it build? Not "does it look complete" — does install then build actually succeed on a clean machine. This is the check most buyers skip and most regret. If the seller can't tell you the exact commands, that's your answer.
4. Is it what it claims to be, or is it scaffolding? Open five source files at random. If they're mostly // TODO: implement, or you find comments like // ... rest of the code unchanged, you're looking at a sketch, not a project. That second one especially — it's the mark an AI leaves when it writes *around* code it doesn't have.
Then the code itself
5. Read the commit history, if you get one. Fifty commits over eight months is a project. One commit called "initial commit" containing 40,000 lines is something else — possibly fine, possibly a repo assembled elsewhere.
6. Check what's vendored. A vendor/ directory, a committed dist/, minified bundles — none of that is the seller's work, and none of it should be counted in "how much code you're getting."
7. Look at the dependencies, not just the code. How many, how old, and how many are unmaintained? An abandoned repo often means abandoned dependencies, and the real cost of the head start is the upgrade you'll do in month one.
8. Find the boring 30%. Auth edge cases, payment reconciliation, error handling, deploy config. This is the expensive part of any product and the part most half-built repos are missing entirely. If it's there, the project is worth considerably more than its line count suggests.
Then the things around the code
9. What else is included, exactly? A domain, a landing page, a waitlist, an app store listing, social handles, a Stripe account. Get it in writing — "and the domain" said in chat is not a transfer.
10. Were there ever users? Even ten real ones is evidence a generator can't produce. Ask what they said and why they stopped.
11. What secrets were in the repo, and have they been rotated? Any keys the seller had are keys you must assume are compromised. On Cinderella these are stripped automatically before listing and the report is public, but wherever you buy, ask.
12. The question most buyers forget: why are you selling it? Not to catch anyone out — the honest answer is usually "I lost interest" or "I got a job" — but because the *dishonest* answers are recognisable. "I've moved on to bigger things" from someone with no bigger things is worth another look at checks 1 and 3.
What good looks like
You want a seller who answers quickly and specifically, who volunteers what's broken before you ask, and who can tell you exactly what doesn't work. Vagueness about ownership, evasion about whether it builds, or pressure to move fast are the three signals worth walking away from — and they're the same three whichever marketplace you're on.
On Cinderella, checks 3, 4, 6 and 11 are done before a listing goes live: we run the build in a sandbox and publish the result even when it fails, we flag scaffolding and placeholder code, we exclude vendored code from the valuation, and every upload is scrubbed of secrets. The rest is still yours to do — but it's a much shorter list.