How to Tell If Your Developer Is Building the Right Thing

Most non-technical founders I work with describe the same quiet anxiety. The developer is shipping. Things are happening. The product is taking shape. But there's a feeling — usually somewhere around month three or four — that they have no real way to tell if any of it is good.

You can see what's been built. You can use what's been built. What you can't do is judge the decisions underneath it. And the further the project goes, the harder those decisions become to unwind.

I've spent more than a decade leading engineering teams across finance, health, and government — hiring, mentoring, and inheriting other people's developers. What I've learned is that you don't need to be technical to know whether your developer is building the right thing. You just need to know what to ask, what to look for, and what to be quietly suspicious of.

Here's the framework I use.

"Shipping fast" isn't the metric you think it is

The first instinct most founders have is to judge progress by velocity. Are features going out? Are demos getting more impressive? Is the developer working long hours?

It's understandable, and it's wrong.

A developer who ships fast in month one and month two can quietly bury you in problems that surface in month six — at exactly the point you're trying to raise, hire, or onboard real customers. Shipping fast and shipping well aren't the same thing. Some of the worst codebases I've inherited were built at impressive speed by people who knew exactly what they were doing — they just weren't thinking past the demo.

The right question isn't "how much got built this week?" It's "are the decisions being made today still going to look reasonable in 18 months?"

Five questions you should be asking, every fortnight at least

You don't need to understand the answers in technical detail. You need to listen to how your developer answers, and how comfortable they are explaining it to you.

What's the riskiest part of the system right now, and what would you do differently if you started again? A confident developer will give you a real answer. Someone who can't think of anything is either very junior, complacent, or hiding something.
If you got hit by a bus tomorrow, how long would it take a new developer to get up to speed? This isn't morbid — it's about documentation, code clarity, and whether the whole thing lives in one person's head.
What did we choose not to build, and why? Good developers can articulate the things they deliberately said no to. If yours can't, they're probably saying yes to too much.
Where are we accruing technical debt deliberately, and where is it accidental? Some technical debt is a sensible trade for speed. The dangerous kind is the debt nobody planned to take on. A developer who can't tell the two apart is one I worry about.
What metric tells us this feature is working? "Working" should mean something specific. Page load under two seconds. Sign-up flow under 90 seconds. Crash-free sessions above 99%. Vague answers here are a tell.

If you ask these every two weeks, two things happen. Your developer starts thinking more carefully because they know you'll ask. And you build a sense — over time — of whether the answers are converging or drifting.

What good early-stage architecture actually looks like

A founder once asked me to "review the architecture" of their MVP. I told them the truth: at the MVP stage, the architecture should be small enough that there is barely anything to review. That's the point.

Good early-stage architecture has a few hallmarks, all of which you can spot without writing a line of code yourself:

It's boring. It uses well-known tools that most developers have heard of. Exotic technology choices at this stage are almost always a red flag — the developer is solving for their own interest, not the business.
It's small. Two or three core components, not eight. Every additional moving part is one more thing that can go wrong, and one more thing the next developer has to learn.
It's reversible. Decisions that are hard to walk back from — picking a database, picking a payment provider, picking a hosting setup — should be questioned harder. A developer who picks an obscure database in week two should have a very specific reason.
It defers what it can. A good developer leaves room for the things you'll learn later, rather than building elaborate scaffolding for problems you might never have.

If your developer is building something that takes 15 minutes to explain and includes the words "service mesh," "event sourcing," or "polyglot persistence" while you're still pre-revenue — pause. Ask why. Ask what would break if they didn't.

Warning signs your developer is solving the wrong problem

The single biggest risk for a non-technical founder isn't bad code. It's a developer who's solving an interesting technical problem instead of your business problem. The two often look identical from the outside.

A few patterns to watch for:

They keep building infrastructure rather than features the user can see. Months pass, demos look the same.
They describe what they're working on in language you can't follow, and seem reluctant to translate it into business terms.
The work always takes longer than estimated, and the explanations are always technical.
They resist talking to actual users, or push back when you bring real customer feedback into the conversation.
They want to rewrite something that was working, on the grounds that it wasn't done "properly."
They're more interested in the framework than the product.

Any one of these in isolation is normal. Two or three together, sustained across a quarter, is a problem you need to address.

The single most useful sanity check

If you do nothing else from this post, do this: every six months, pay a trusted senior engineer you don't already work with to spend two hours reviewing what's been built and what decisions are coming up.

Not to replace your developer. Not to undermine them. Just to give you an independent read on whether the technical direction is sensible.

This costs less than most founders expect — usually a few hundred pounds — and it does two things at once. It tells you whether you're on track, and it tells your developer that someone independent will be looking at the work. The second effect alone is often worth the cost.

A good developer will welcome it. A defensive developer is telling you something useful all by themselves.

Confidence comes from process, not faith

The mistake non-technical founders make most often is treating their developer as either an oracle or a black box. Either you trust everything they say without question, or you've no way of evaluating it at all and you try to ignore the unease.

There's a third option. You can build a simple, regular practice of asking the right questions, listening to how they're answered, and bringing in independent eyes a couple of times a year. That's all it takes to move from anxiety to informed confidence — without having to learn to code.

Building software with a developer you can't fully evaluate is one of the most stressful things about being a non-technical founder. It doesn't have to be.

STAAL & Co provides senior technical leadership backed by a delivery team — for founders who want both senior oversight and execution. If you're building with a developer and not sure how to tell whether the work is good, a short, no-cost call usually gets you further than another quiet quarter of wondering. Get in touch.