How to Evaluate a Developer When You're Not Technical

You're a founder. You've got a great idea, maybe some funding, and you need someone to build it. Problem is, you can't tell the difference between a brilliant developer and one who's going to take your money and deliver a mess.

I've been on the other side of this for 16 years. I've seen what founders go through. I've also inherited projects from developers who talked a great game and delivered nothing. So here's what I'd look for if I were hiring me — but wasn't technical enough to evaluate the code.

What Good Developers Do

They ask uncomfortable questions.

This is the single biggest tell. A good developer will hear your pitch and immediately start poking holes in it. Not to be difficult — because they're trying to understand what they're actually building.

"What happens when a user cancels halfway through the booking?" "Who pays the Stripe fees — you or the customer?" "What if two cleaners accept the same job at the same time?"

If your developer hears your idea and says "yeah, I can build that, no problem" without asking any questions — that's not confidence. That's someone who hasn't thought about it enough to know what they don't know.

When I started working on TidyLinker with Adele, we spent weeks on calls before I wrote any code. What types of cleaning? How does the quoting system work? What happens if a cleaner fails their DBS check? Who handles complaints? These conversations saved months of development time because we weren't building the wrong thing.

They push back.

Good developers will tell you when your idea is bad, or at least when your approach is wrong. "You don't need a custom CMS — use WordPress for the blog." "Don't build an admin panel from scratch — use Filament." "That feature can wait until v2."

This feels annoying in the moment. You want someone who shares your vision and says yes. But a developer who says yes to everything is either not thinking critically or doesn't care enough to have an opinion. Both are bad.

I push back on my clients regularly. Sometimes they're right and I'm wrong — and that's fine. But the conversation itself is valuable. It means we've both thought about it.

They show you working software every week.

Not mockups. Not wireframes. Not "progress updates" in a document. Actual working software that you can click through in a browser.

This is the single most important process requirement you can insist on. A weekly demo forces the developer to actually finish things. It makes scope creep visible immediately. It gives you the chance to say "that's not quite right" when fixing it is cheap instead of after three months when it's expensive.

If a developer can't show you something working after a week of development, something is wrong. Either they're stuck, they're not actually working, or they're building something so poorly architected that nothing works until everything works.

They give you access to the code.

From day one. No exceptions. The code should live in a repository that you own or have admin access to. GitHub, GitLab, Bitbucket — doesn't matter which. But you should be able to see commits happening, even if you can't read the code itself.

This isn't about trust. It's about protection. If your developer disappears tomorrow, you need to be able to hand that code to someone else. If they won't give you access, ask yourself why.

They write tests.

You won't be able to evaluate the tests themselves, but you can ask: "Do you write automated tests?" and "What's the test coverage like?" If the answer is no tests, or they look uncomfortable with the question — that tells you something.

Tests are how developers prove their code works. No tests means they're relying on manual clicking to verify things, which means bugs ship constantly. On every project I work on, I write tests. The Rezzy rescue went from 0 tests to 59. It's not optional.

The Red Flags

"It's almost done" — for three weeks running.

Software is either working or it isn't. "Almost done" means they've done the easy 80% and are stuck on the hard 20%. Or they've done nothing and are hoping you won't notice. Either way, if you hear this more than once, have a direct conversation about what's actually blocking progress.

They disappear.

Radio silence for days at a time. Don't reply to messages. Miss calls. Then suddenly reappear with a burst of activity. This pattern means either they're working on other projects and squeezing you in, or they're struggling and too embarrassed to tell you.

Consistent communication is more important than constant communication. I don't need to talk to my clients every day, but they always know what I'm working on and they never have to chase me.

They won't explain technical decisions in plain English.

If a developer can't explain why they chose a particular approach without drowning you in jargon, they either don't understand it themselves or they're deliberately keeping you in the dark. Neither is acceptable.

You should be able to ask "why did we choose Stripe Connect instead of regular Stripe?" and get an answer like "because we need to split payments between the platform and the service providers, and Connect handles that natively instead of us building it ourselves." Clear. No jargon. You understand the reasoning even if you don't understand the implementation.

Scope keeps growing without conversation.

"Oh, I also built this notification system" or "I added a role management feature." Sounds good, right? Except nobody asked for it, and it took two weeks that should have been spent on the features you actually need.

Good developers build what was agreed. If they think something additional is needed, they raise it with you first. Developers who just build whatever they think is cool are optimising for their own interest, not yours.

They blame the tools.

"React doesn't support that." "Laravel can't do this." "The API is broken." Sometimes tools genuinely have limitations. But a developer who consistently blames external things for slow progress is usually covering for their own gaps.

The Interview Questions That Actually Matter

Forget technical trivia. You can't evaluate the answers anyway. Instead, ask these:

1. "Walk me through the last project you built." Listen for: specificity, honesty about challenges, mentions of trade-offs. Vague answers mean vague thinking.

2. "What would you push back on in my idea?" If they can't find anything to question, they're either not listening or not thinking critically.

3. "How do you handle it when you're stuck?" Good answer: "I timebound it, try a few approaches, and if I'm still stuck after X hours, I ask for help or propose an alternative." Bad answer: "I don't get stuck."

4. "Can I talk to your last client?" A developer who won't provide references is hiding something. Full stop.

5. "What would you not build for the MVP?" This tells you whether they understand prioritisation and restraint. A good developer will suggest cutting scope. A bad one will try to build everything.

The Process That Protects You

You don't need to be technical to manage a developer effectively. You need three things:

1. Weekly demos of working software. Non-negotiable. If they can't demo it, it doesn't exist.
2. Code access from day one. In a repository you control.
3. Written scope before work begins. Doesn't need to be a 50-page spec. A one-page document listing what's being built this sprint is enough.

That's it. Those three things will catch 90% of problems before they become expensive. The developer who balks at any of these requirements is telling you something important about how they work.

Trust your gut. If something feels off, it probably is. The best working relationships I have are with founders who ask hard questions and hold me accountable. It makes me a better developer and them a better client.

---

I've been building web products for 16 years. If you're looking for a senior developer you can actually trust, get in touch.