How to buy a side project without getting burned

There's a specific kind of thrill in finding a project for sale that's exactly what you'd have built — already made, already working, already earning. The temptation is to move fast before someone else grabs it. That temptation is precisely how people get burned.

Here's the one rule that survives every acquisition horror story: every number is a claim until you've seen where it comes from. A revenue screenshot is a claim. A traffic graph is a claim. "It runs itself" is a claim. Good sellers won't mind you verifying — they'll expect it. The ones who mind are telling you something. So before you fall in love, run the checklist.

Check 01Follow the money

Revenue is the number people lie about most, because it's the number you're paying for. Screenshots take thirty seconds to fake, so don't accept them. Ask to see the live payment dashboard — Stripe, Paddle, the App Store, whatever it runs on — over a screen-share, and get the last 12 months exported, not a cherry-picked month.

And watch the timing. A sudden revenue spike in the weeks right before a sale — one that doesn't line up with any jump in traffic — is one of the oldest tricks in the book. It's there to inflate the asking price, and it usually evaporates the month after you buy.

Check 02Trace the traffic

Same principle: don't accept a picture of an analytics graph. Ask for read access to the actual analytics — Google Analytics, Search Console, Plausible, whatever's running — so you can poke around yourself. What you're looking for is where the visitors come from, because that's what tells you how fragile the whole thing is.

Check 03Read the actual code

You're buying software, so look at the software. You don't need to audit every line, but you do need to answer three questions: does the code actually match what the seller says it's built with? Is it something a normal developer could pick up and change? And — the one people forget — does the seller even own it?

Code written by a contractor without a signed IP assignment doesn't fully belong to the seller, which means it can't fully become yours. And if there's exactly one person on earth who understands how it works, you're buying a bus-factor of one. Ask who wrote it, ask to see it run, and ask what breaks if the original developer disappears.

Check 04Confirm what actually transfers

A deal isn't the code alone — it's everything that makes the code work. Before you close, get a written, itemized list of what comes with it, and make sure the important pieces can actually move to your name.

The tellRed flags that mean walk away

Most bad deals announce themselves if you're listening. Any one of these on its own is a conversation; two or three together is your cue to politely walk.

You're not being paranoid, you're being a buyer. A seller with a real business will happily prove it. The only person who fears verification is the one with something to hide.

The netLet escrow do the worrying

Here's the reassuring part. Even after you've done the homework, you don't have to trust a stranger with your money and hope. That's the entire job of escrow: the buyer pays in, the funds sit locked, and the source code stays locked too — the two only release together, the moment the handoff is confirmed. Nobody can walk off with both the code and the cash.

On Vertos, every deal runs through Stripe-powered escrow by default, and every listing comes with that free AI Analysis of the real code. Do your own diligence anyway — no tool replaces a careful buyer — but know that the structure is built so an honest deal is easy and a dishonest one is hard.

Buy the good ones. Walk from the rest. You'll know the difference now.
— The Vertos team