You don't need to assess code quality to hire well. You need to assess product judgment, process, and communication — and all three are visible to a non-technical founder if you know what to look at. That's the whole answer. This is one part of how to hire a developer for your MVP; everything below is how to actually run the check.

The instinct most founders have is to try to become technical enough to evaluate technical skill. It doesn't work, it takes months, and it's aiming at the wrong target. Among developers who can plausibly build your MVP — and there are many — the differences that decide whether your project succeeds are almost never about raw coding ability.

The signal that predicts everything: they try to build less

The strongest developers spend a surprising amount of the first conversation trying to reduce your project.

If your first meeting ends with the developer enthusiastically agreeing to every feature on your list, treat that as a warning, not enthusiasm. Most MVPs fail from being too big, not too small. Someone who has watched that happen a few times will push back on your scope before they've been paid a cent, because they'd rather have a project that succeeds than a project that's large.

What that sounds like in practice:

"I'd cut the admin dashboard and the second user role. Neither one tests whether people will pay, and together they're probably a third of the build."

Versus the answer you should worry about:

"Yeah, we can do all of that."

The second answer feels like great service. It's the single most expensive trait a developer can have.

The eight-point scorecard

Weighted roughly in order of how much each one predicts a good outcome:

Notice what isn't on the list: which programming language they use. For an MVP that's far less important than execution, and it's the one thing founders feel qualified to ask about — which is exactly why it becomes the focus of bad interviews.

How to check technical claims without technical skills

Four techniques that work:

1. Ask them to explain a decision to you. Pick anything in their proposal — a database choice, a hosting choice — and ask why. You're not grading the answer's correctness. You're checking whether they can explain it without jargon. A developer who can't translate their reasoning into plain English will be difficult to work with for months, regardless of skill. Someone hiding behind terminology is usually hiding.

2. Open their live products and use them properly. Sign up. Complete the main flow. Try to break it — submit an empty form, refresh mid-flow, use it on your phone. You don't need to read code to notice that a product falls over when you look at it sideways. Ask which parts they personally built; on team projects "we built this" can mean they attended standups.

3. Ask what went wrong on a past project. Everyone has a project that went badly. A developer who says none have is either inexperienced or not being straight with you. A good answer is specific and includes their own contribution to the problem: "I underestimated the payment integration by three weeks because I assumed the client's provider had a sandbox and it didn't. Now I verify that before quoting."

4. Ask a third party. Paying an independent senior engineer for two or three hours to review the proposals before you sign is the highest-return money available to a non-technical founder. A few hundred dollars catches unrealistic estimates, ownership terms worth renegotiating, and architecture choices that will cost you later. Hire them separately from anyone bidding — their value is in not being a candidate.

What to ask the references

Founder references are worth more than portfolio links, but only if you ask behavioural questions rather than satisfaction questions. "Were you happy?" gets you nothing.

• Did they stay on budget? If not, what changed and how was it handled?
• Did they push back when you asked for something unwise?
• What happened the first time something broke in production?
• How long did it take to get an answer when you had a question?
• Would you hire them again — and if there's a hesitation, what's behind it?

If a candidate can't produce two references who'll take a call, that's a finding. Not a fatal one for someone genuinely early in their career, but it changes what you should be willing to commit upfront.

The process questions

How the work runs matters more than most founders expect, because it determines whether you find out about problems in week two or week ten.

Ask: "Walk me through what happens in the first two weeks."

A good answer is specific — discovery, wireframes, technical planning, a first reviewable increment, a milestone review. A bad answer is "we'll start developing."

Ask: "How will I know you're making progress?"

You want a staging environment you can open, a demo cadence, and a visible board. You do not want "we'll email you updates." If you can't see it working, you're taking progress on trust, and by the time trust turns out to be misplaced the budget is gone. How to tell if your build is on track covers what you should be receiving throughout, not just at the end.

The ownership check

Separate from skill, and the one that costs the most to get wrong. Before you sign, confirm you will own: the source code, the Git repository and its history, the cloud accounts, the domain, the designs, the documentation, the databases, and the API keys.

The practical version: those accounts should be created under your company from day one, with the developer given access — not created in the developer's name and transferred later. Transfers get forgotten, contested, or become impossible when someone stops replying.

Full detail in who owns the source code.

Red flags, in one list

• Every feature is "easy."
• A price quoted after a twenty-minute call, with no discovery.
• They never ask about your users.
• They won't explain why they chose a technology.
• They avoid discussing what's excluded.
• They refuse reference calls.
• Everything is "under NDA" and nothing can be shown.
• Only polished mockups, no live products.
• They insist on owning the repository.
• All payment upfront.
• No testing or QA process at all.
• They go quiet between milestones.

The subtle one is when every answer is yes. Good partners say "I wouldn't build that yet" and "I'd validate that before spending money on it." That's not obstruction — it's someone protecting your budget rather than maximising the project.

The full red-flag breakdown has the reasoning behind each.

How I'd actually run it

Send three candidates the identical one-page spec. Ask each what they'd cut and why. Open their live products yourself. Call two references each. Compare proposals on exclusions and assumptions rather than headline price.

Then pick the one who challenged your assumptions, cut features, gave the clearest plan, produced the strongest evidence from previous clients, and was completely transparent about ownership and communication.

That will not always be the cheapest quote. It's usually the cheapest project.

If you want a set of proposals reviewed by someone who isn't bidding on them, get in touch.