Most of my contract history is taking over projects another developer left behind, and the first conversation is almost always the same. The client has a repository, a hosting login and no way to tell whether what they paid for was any good. Nobody told them it was bad. They just couldn't tell, and neither can most people who hire a developer without being one.
You don't need to learn to read code to fix that. You need to check things you can see, in the right order, before the money is spent. Here is how I'd do it if I were the client.
Ask to see something live, not a portfolio screenshot
A screenshot proves someone opened Figma. A deployed app proves someone shipped. Ask for a link to something the developer built that is running right now, and ask what they personally did on it versus what the rest of the team did.
Then use it. Open it on your phone, submit a form with bad input, refresh in the middle of a flow. You aren't testing the code. You're checking whether the thing holds up when a normal person pokes at it, and whether the developer can explain what went wrong without getting defensive.
A developer who can only show mockups, or whose live work belongs to a client they won't let you speak to, isn't automatically ruled out. But you are betting without information, so commit less money until you've seen more.
Read the track record, and know what it hides
On Upwork, Top Rated means a Job Success Score of at least 90% for 13 of the last 16 weeks, plus at least $1,000 in earnings over the past 12 months, according to Upwork's help page on Top Rated and Top Rated Plus badges. That is a floor, not a verdict. I've held a 100% score across 9 contracts, and I can tell you the number says very little about how a freelancer handles scope changes, silence or bad news.
The score also depends partly on private client feedback that neither you nor the freelancer ever sees. So read the review text, not the percentage. A 94% score with detailed reviews describing what was delivered tells you more than a clean 100% with "great work, thanks!" repeated six times. I cover this in more detail in what a Job Success Score actually tells you.
Pay for a small first milestone before the big project
The cheapest way to learn how someone works is to pay them for a small, real piece of your project, not a test exercise. Pick something that touches the parts that matter: one screen, one integration, one deploy to a real URL. Keep it to a week or two.
What you learn from it is rarely the code. It's whether they ask clarifying questions before starting, whether they send a written summary of what they understood, whether the update arrives when they said it would, and what they do when something takes longer than planned. Those habits predict the rest of the project. You'd rather lose a small milestone than discover them in month three of a fixed-price build.
Get the accounts in your name from day one
The most common reason a takeover is painful is that the repository, the hosting and the domain all sat in the developer's personal accounts. The code might be fine. The client just can't get to it.
Before work starts, create the GitHub organisation, the hosting account and the domain registration yourself, and invite the developer in. If they stop replying, you still hold every key and nothing has to be negotiated. A developer who pushes back on this is telling you something. The full checklist for when it has already gone wrong is in what to do when your developer disappears, and most of it is unnecessary if you do this first.
Who owns the code depends on your contract and where you both live, so put it in writing and have someone qualified review it. I'm not a lawyer and this isn't legal advice.
Have a second developer look at the first two weeks
This is the check I'd pay for first. You can't read the repository, but someone else can, and an hour or two of a second developer's time is cheap next to a failed build.
Ask them to check four things. Does it build and deploy from the repository as it stands? Is anything dangerous sitting in the code, such as API keys, passwords or open admin routes? Is there any record of how to run it? Does the structure look like something a stranger could pick up?
These are the same things I look at when I audit a codebase. On one contract I found and patched a cross-site scripting hole nobody had asked me to examine, and the client hadn't considered it. No amount of reading public reviews would have surfaced that. A short outside review does. That is what my codebase takeover audit is, from $300, and you can use it on a developer you're already working with.
Red flags I'd walk away from
A developer who starts a fixed-price job from a one-line description and asks no questions is planning to renegotiate later. A developer who won't add you to the repository, or says they'll hand it over "at the end", is holding leverage. A quote with no breakdown, from someone who hasn't read your brief, is a guess dressed as an estimate.
A rate far below everyone else's isn't a bargain either. The lowest bids on a page tend to come with more rework, and the cheapest bid is rarely the cheapest project once you count revisions and the time you spend managing it. What US startups actually pay offshore developers goes into why the quoted rate isn't your real cost.
None of these means the developer is dishonest. They mean you're about to take on risk without being paid for it.
Vetting costs you a week and a few hundred dollars, and it feels like friction when you're keen to start. It is still cheaper than a rebuild, and most of these checks cost nothing but attention. If you only do two, make them the accounts in your name and the paid first milestone. Those two would have prevented most of the rescues I've been hired for.
Questions clients ask at this stage
Can I vet a developer if I'm not technical? Yes. Check what you can see: a live app they built, review text rather than scores, how they handle scope in writing, and a small paid first milestone. Then pay a second developer to review the first two weeks.
How much should a first milestone be? Small enough to lose without hurting, large enough to touch something real. One screen, one integration or one deploy to a real URL, over a week or two.
What should I own from the start? The code repository, the hosting account and the domain registration, all in your name, with the developer invited in. It costs nothing and removes the biggest risk if they go quiet.
Should I hire the cheapest developer? Usually not. The cheapest bid tends to cost more once you count revisions, delays and your own management time.
If you want an outside review of a developer or a codebase before you commit more money, you can book a 15-minute call and bring whatever access you have.