How to tell if your developer or agency is doing a good job, without reading code

Hiring a developer or an agency when you aren't technical means paying for something you can't inspect. You see invoices and progress updates. You don't see whether the thing underneath is solid, or held together with tape.

The good news: you don't need to read code to get a fair picture. Good engineering leaves visible traces in how the work is delivered. So does bad engineering.

Signs things are going well

• You see working software regularly. Every week or two there is something new you can open and click through yourself, on a real link, not a slide.
• New releases don't break old features. What worked last month still works this month.
• Estimates roughly hold. When they slip, you hear about it early, with a reason and a new date, not on the day of the deadline.
• They sometimes push back. A good developer will tell you when an idea is expensive, risky or unnecessary. A team that says yes to everything isn't always doing you a favour.
• You have access. You're an owner on the code repository, the hosting account and the task board.
• Questions get straight answers. "Why is this taking longer?" gets an explanation you can follow.

Warning signs

Any one of these can happen on a healthy project. Several at once is a pattern worth acting on.

• "Almost done" for weeks. The last 10% taking as long as the first 90% is a classic sign the foundations were rushed.
• Demos are screenshots or recordings rather than something you can use yourself.
• The same bugs keep coming back, or fixing one thing breaks another.
• Every small change is "big". If a simple text change or a new field takes days, the code is probably hard to work with.
• You don't have access to the code, hosting or accounts, and requests for access get delayed.
• The people keep changing. A new developer every few weeks means knowledge keeps walking out of the door.
• Invoices grow but visible progress doesn't.
• Nothing is written down: no task list, no release notes, no documentation.
• Defensiveness when you mention getting a second opinion.

Six checks you can run yourself this week

None of these need technical knowledge. Most take a few minutes.

1. Ask for a test link and use it yourself. Open it on your phone. Try to do the three things your customers most need to do. Note where it breaks or confuses you.
2. Ask to be added as an owner on the code repository. On GitHub, GitLab or Bitbucket you can see when work was last saved (each save is called a "commit"). You don't need to read the code. Long gaps while you're being billed are worth a question.
3. Ask for a simple status list: done, in progress, not started. Compare it with the original plan. Is the "done" pile growing?
4. Ask: "If your lead developer left tomorrow, how long would it take someone new to pick this up?" A good team has an answer involving documentation. A worrying answer is a long pause.
5. Find out where the product is hosted and whose card pays for it. If it's their account, see our guide on making sure you own everything.
6. Ask how the database is backed up, and when a restore was last tested. Backups that have never been tested are hopes, not backups.

Be fair: things that look bad but often aren't

• Slow visible progress in the first few weeks. Setting up foundations (accounts, databases, logins, deployment) produces little you can see. It should speed up after.
• Bugs. All software has them. What matters is how quickly they get fixed, and whether they stay fixed.
• Being told no. A developer who explains why something is a bad idea may be saving you money.
• An estimate that changed after you changed the scope. That's how it should work, as long as it was agreed first.

When to get an independent review

An outside review is worth it when a wrong call would be expensive. The most common moments:

• Before paying a large milestone or final invoice.
• When estimates have slipped twice and the explanations don't add up.
• Before raising money, when investors may ask about your technology.
• When you're thinking about switching developers, and need to know whether the code is worth keeping.
• When a new developer says everything needs to be rebuilt, and you want a second opinion before you pay for it.

Here is what an independent code review covers and what you should get back from one.

Common questions

How can a non-technical founder evaluate a developer?

Judge what you can see: whether working releases arrive regularly, whether estimates roughly hold, whether bugs stay fixed, and whether plain questions get plain answers. Make sure you own the code repository and hosting accounts. For a deeper read, ask an independent technical person to review the code and the plan.

Is it normal for software projects to run late?

Some slippage is normal, especially when scope changes. What isn't normal is hearing about delays only at the deadline, or repeated slips without a clear reason and a new, believable date.

Should I tell my developer I'm getting a second opinion?

It's your decision. Many founders frame it as standard due diligence, and good teams tend to welcome it. You will usually need their help to grant read access to the code anyway.