How to Evaluate Tech When You're Not Technical

Let’s get the uncomfortable part out of the way first: you are never going to look at your product’s code and know whether it’s good. That’s fine. Neither can most investors, most CEOs, or most of the people who will one day acquire your company.

Here’s the reassuring part: you don’t need to. The mistake founders make isn’t that they can’t read code. It’s that they think code quality is invisible to them, so they stop looking entirely and just hope. Then they hand over judgement to the one person whose work they’re supposed to be judging.

We get called in when that bet goes bad. In every stalled build we’ve taken over, the founder had a bad feeling months before they could point to why. The signals were sitting in plain sight. They simply didn’t know where to look.

You can evaluate tech without being technical. You just have to look at the right things: what the software does, how the work behaves over time, and how people answer you when you ask a real question. All three are visible from where you’re standing.

Stop Evaluating the Code. Evaluate the Evidence.

Code quality leaves fingerprints everywhere except the one place you can’t look. You don’t need to open the safe to know something’s wrong inside it. You watch the behaviour around it.

Here are the signals that are fully visible to a non-technical founder.

Does it survive you going off-script?

The single most useful test you have costs nothing. When they demo something, don’t follow the path they show you. Click the back button. Refresh halfway through. Enter a weird value. Try to do the second thing before the first thing finished.

Good software shrugs and keeps going. Bad software falls over the moment you step off the exact route they rehearsed. You don’t need to know why it broke. You just saw that it did.

Are changes getting faster or slower?

Watch the pace over months, not days. In a healthy codebase, small changes stay small: “move that button” takes an afternoon, not a week. As a project rots, the opposite happens. Simple requests start coming back with “that’s actually a big change” attached to them.

If development keeps getting slower for no obvious reason, that’s not a vibe. There are structural causes, and they’re worth understanding.

Does the same bug keep coming back?

Fix it, it returns. Fix it again, something next to it breaks. This whack-a-mole pattern is one of the clearest tells of a fragile system, and it’s completely observable without technical knowledge. Good systems let you fix a thing once. Bad ones make every fix a gamble.

The Two-Question Test for Any Technical Answer

You’ll spend a lot of time listening to explanations you can’t fully verify. You don’t need to verify them. You need to notice how they’re delivered.

Run every technical answer through two questions:

Could a smart 12-year-old follow the shape of it? Not the details, the shape. A good developer can explain almost anything at the right altitude: “Right now the app checks who you are every single time you click, which is slow. We want it to remember you for a bit. That’s the change.” Someone who understands their work can always find that version. Someone hiding behind their work can’t.

Did they tell me the trade-off? Every real technical decision costs something. Faster to build but harder to change later. Cheaper now but pricier to run. More features but more things that can break. When someone presents a choice as pure upside with no cost, they either haven’t thought it through or they don’t want you thinking about the cost.

What Good and Bad Actually Look Like

None of the left column requires you to read code. All of it requires you to pay attention and refuse to be talked out of what you’re seeing.

The Thing Worth Paying For: An Independent Review

There’s one move that punches far above its cost, and almost no first-time founder uses it early enough: pay a senior engineer who has nothing to do with your team to look under the hood and tell you the truth.

This is a technical audit, and it’s normal. A good one gives you a plain-language read on: is the code in reasonable shape, is it built to grow or is it a wall you’ll hit soon, are there security or ownership landmines, and is the team’s account of where things stand actually true.

We’ve been that outside engineer more than once. Every agency build we’ve been called in to rescue started as a founder who wanted a second opinion and waited too long to get one. By the time we looked, the answer was usually clear in an afternoon. The expensive part was the six months of hoping that came before it.

A health-tech company came to us after months with an agency that wasn’t moving. The founders were non-technical, and they’d done what everyone does: judged the team by the confident senior engineer in the sales meeting. The senior was real. He just wasn’t the one writing their code. A junior was, unsupervised, and the backend was nowhere near done, built the hard way instead of on services that already existed. None of that was visible from where the founders sat. What was visible, if they’d known to look, was the pace: months in, still nothing they could open and use themselves.

The instinct founders have is to skip the audit to avoid offending the team. Reframe it. A confident, competent team welcomes an independent review, because it validates their work to the one person who can’t otherwise see it. A team that reacts badly to the idea of someone checking their work has just told you something important, for free.

Build a Bench Before You Need It

You don’t have to hold this knowledge yourself. You have to know two or three people who do.

Founders who navigate technical decisions well almost never became technical. They built a small circle of trusted technical people, other technical founders, a former colleague who’s now a senior engineer, an advisor, whoever, and they use it as a sanity-check line. Before signing, before a big spend, before a decision that feels irreversible, they run it past someone with no stake in the answer.

This is worth building deliberately, before you’re in a crisis. When something feels off mid-project, you don’t want to be scrambling to find someone who can tell you if you’re being played. You want them already in your phone.

If you’re weighing whether to bring some of this capability in-house permanently, that’s a different question worth its own answer: do you actually need a technical co-founder, or something lighter?

If you got this far and quietly recognised your own project in the warning signs, that feeling is worth listening to. Run the checklist below with your build in mind. If it comes back thin, that’s usually the exact moment an outside read pays for itself, and it’s a big part of what we do.