How to tell if your developer is doing a good job (even if you're not technical)
Seven concrete signals to assess whether your dev is working well, even if you can't read code. No technical jargon, no blind trust.
You've hired a developer or brought on a freelancer, and now you're wondering whether they're doing a good job. You can't read code, so you can't judge it directly. Yet you have to decide: keep paying them, replace them, step in. This guide gives you seven concrete signals to figure it out, even if you know nothing about tech.
Important: every one of these signals is verifiable by anyone— no technical skills required. If even three or four of them are red, it's time for an external assessment.
1. Visible weekly commits
On the code repository (GitHub, GitLab) you can see every change that gets made. They're called "commits". A dev who is actually working produces commits every 2-5 days on average. If a week goes by without commits, something isn't happening — either the dev isn't working, or they're working offline and piling up changes without sharing them (a huge risk).
What to do: ask for read-only access to the repository. Look at the commit frequency over the last 4 weeks. Nothing for 14+ days is a red flag.
2. Regular production deploys
Code that's been written is worth zero until it's in production. A healthy team deploys at least once a week, ideally every 2-3 days. If it's been months of "it's almost ready" but you never see anything new in the app, you have a problem.
What to do: ask the dev to show you today, on a call, the live version (not running locally). If they refuse or say "I'll show you next week", that's a strong signal.
3. Straight answers to your questions
A competent dev answers "yes, I can do that in 3 days" or "no, because X, but I can do Y instead". A dev who's struggling answers "it depends, let's see, let's touch base later", or keeps steering the conversation toward technical details you don't understand to avoid giving you a concrete answer.
What to do: next time you ask for an estimate, count the days it takes them to give you a concrete answer. More than 48 hours and you have a seniority or motivation problem.
4. Written documentation of the work
A senior dev writes things down. Not for fun — to avoid rebuilding everything from memory every three weeks. Look for: a README on the project, technical notes on Notion/Confluence, architectural decisions written down somewhere. If there's nothing, know that the day your dev disappears, you've lost everything.
What to do: ask "where is the deploy process documented?" If they can't answer or send you a 5-minute voice note on WhatsApp, the answer is: it isn't documented.
5. Tests that run (even if you don't know what they are)
"Automated tests" are code that automatically checks that other pieces of code work. A serious project has them. A junior dev writes them at the last minute (or never). A senior dev writes them as part of the work.
What to do: ask directly "how many tests does the project have?" and "when did you last run them?". It doesn't matter if the answer is technical — what matters is how quickly they give it. If they have to think about it, having no tests is better than having badly written ones.
6. The courage to tell you no
This is the most important signal and the most ignored. A dev who always tells you "yes, we can do that" is a mediocre order-taker, not a technical partner. A dev who tells you "this feature doesn't make sense, because X" is saving you weeks of pointless work.
What to do: think back to the last time your dev told you no. If you can't remember it, you have a pure order-taker. That's fine for executing things already defined. It's not fine for building a product.
7. Owner of nothing sensitive
This one isn't a signal of technical quality — it's about business security. You must be the owner of: the repository, hosting, domain, Stripe account, cloud account. The dev has access as a collaborator, never as an owner.
If instead the dev is registered as the owner of these things, fix it today. Not because your dev is dishonest — because you're building a point of failure you can't recover from if they disappear.
What to do if 3+ signals are red
The temptation is to fire them and look for another freelancer. Terrible idea. You don't know whether the problem is the dev, the scope, the specs, or the inherited code. Without an external assessment you're risking repeating the same mistake with the next one. And if the red signals are mostly silence and deliveries that never arrive, what you need is a plan for when your developer stops responding: how to take back control before it becomes irreversible.
What actually makes sense:
- An independent external technical audit: 2-3 days, limited cost, a written report on what works, what doesn't, and where the problem actually is. I cover this on the software technical audit page.
- Based on the audit, you decide: keep the dev and pair them with a technical lead, replace them, or rewrite specific parts.
- Never again rely on blind trust. Set up the 7 signals above as a weekly routine from day one.
To sum up
You don't need to be technical to know whether your developer is doing a good job. Seven practical signals, verifiable by anyone, are enough:
- Visible weekly commits.
- Regular production deploys.
- Straight answers to your questions.
- Written documentation of the work.
- Automated tests in place.
- The courage to tell you no when it matters.
- Owner of nothing that's yours.
Frequently asked questions
Can I evaluate my developer if I can't read code?
Yes, and that's the whole point of this guide. All seven signals — commit frequency, regular deploys, straight answers, documentation, tests, the courage to say no, and account ownership — are verifiable by anyone, no technical skills required. You just need read-only access to the repository and the right questions to ask.
How often should a developer commit and deploy?
A dev who's actually working produces commits every 2-5 days on average: nothing for 14+ days is a red flag. On deploys, a healthy team ships to production at least once a week, ideally every 2-3 days. If it's been months of 'it's almost ready' but you never see anything new in the app, you have a problem.
Is it a bad sign if my developer tells me no?
The opposite — it's one of the best signals. A dev who always says 'yes, we can do that' is an order-taker, not a technical partner. One who tells you 'this feature doesn't make sense, because X' is saving you weeks of pointless work. If you can't remember the last time your dev said no, you have a pure order-taker.
Should my developer own the repository, domain, or accounts?
No, never as the owner. You must be the owner of the repository, hosting, domain, Stripe account, and cloud account; the dev gets access as a collaborator. It's not about honesty: if they're the owner and they disappear, you're building a point of failure you can't recover from. If it's already set up that way, fix it today.
What do I do if three or more signals are red?
Don't fire them on impulse and go hunting for another freelancer: you don't know whether the problem is the dev, the scope, the specs, or the inherited code, and you risk repeating the same mistake. The sensible move is an independent external technical audit of 2-3 days, and only then deciding whether to keep the dev with support, replace them, or rewrite specific parts.
If 3+ of these are red, don't wait. An external technical audit costs a small fraction of what you risk by staying on the wrong path. Want a second opinion on your situation? Let's talk for 30 minutes — I'll get back to you within 24 hours.