The 10 axes I check before building anything

Why I check before I build

Most software projects don't fail in the code. They fail before the code: an idea nobody validated, a scope nobody trimmed, a budget that ended on launch day. Or they fail around the code: accounts the owner doesn't own, knowledge that lives in one person's head, systems nobody dares to touch.

I've built and led products for over a decade, and these failures are remarkably repetitive. So before I take on any project, I run through the same set of questions. Ten axes, three questions each, split across two situations: you haven't built yet, or you're running something today. The interactive version is The Full Picture Check: fifteen questions, about six minutes, an honest score. This page is the methodology behind it, written out in full.

Two things make it different from a marketing quiz. First, the questions are the content; each one teaches something on its own, whether or not you ever talk to me. Second, the verdict can be genuinely negative. "Don't build yet" is a real result, and for a good share of the people who take the check, it's the right one. A consultant telling you not to hire him yet is unusual; it's also the only version of this I'd be willing to put my name on.

How the scoring works: evidence over confidence

Every question takes one of four answers, and the two ends are worded for that specific question: a concrete No (0 points) that names the situation it describes ("No, the same bugs and surprises keep coming back"), and a concrete top Yes (4 points) that names the evidence ("Yes, and incidents are tracked, not just remembered"). In between sit Partially (1 point) and "Yes, I'd say so" (2 points), the honest yes without proof behind it.

The jump from 2 to 4 is deliberate. Anyone can answer "yes" to "do you know who your product is for?", because confidence is cheap. What separates projects that land from projects that drift is evidence: the sentence written down and tested on strangers, the interview notes you can reread, the usage data instead of impressions. Doubling the score for evidence isn't a gimmick; it's the single most useful habit I can teach through a questionnaire.

Fifteen questions, maximum 60 points, normalised to a score out of 100, plus a score per axis, because the shape of your result matters more than the number. A 70 with a collapsed ownership axis is a very different situation from a flat 70.

Two questions override the average entirely: the red flags below. Some answers matter more than any total.

Ready to build? The five readiness axes

This branch is for the moment before the first line of code: an idea, a project, maybe a prototype. The question underneath all fifteen: if you spend real money building version 1, what are the odds it lands?

1. Problem clarity

Can you say, in one sentence, who this product is for and what it replaces for them? Have you talked to at least five people who have the problem today, not friends being encouraging? And do you know what those people currently do to cope?

That last one is the question I care about most. Your real competitor is rarely another app. It's the workaround: the spreadsheet, the WhatsApp group, the intern who does it by hand. If you don't know the workaround intimately, you don't know what you're replacing, and "better than nothing" is a much weaker pitch than "better than what you do today".

2. Validation & demand

Has anyone committed something real to this idea: money, a pre-order, a signed letter of intent, hours of their own time? Could you name your first ten users as actual people or companies, not segments? Have you tested the riskiest assumption without writing code: a landing page, a concierge version, a pilot run by hand?

Compliments are not validation; commitments are. And the cheapest iteration is the one you never had to build: a week of manual piloting routinely teaches more than three months of development, at roughly one percent of the cost.

3. Scope & sequencing

Do you know what version 1 deliberately does not do, ideally as a written "not now" list? Could a usable v1 realistically ship in under three months? And do you know which part of the product is the genuinely hard part, versus which parts are commodity?

Most budgets die rebuilding commodity features (logins, dashboards, settings pages) instead of nailing the one thing that's actually hard and actually differentiating. A version 1 earns the right to exist by what it leaves out.

4. Resources & runway

Do you have a budget for building version 1 and for the six months after launch? Do you have weekly time reserved to make product decisions during the build? If v1 teaches you the idea needs to change, and it usually does, can you afford a second iteration?

Launch day is the midpoint of the spend, not the end. The projects that die quietly are the ones that spent everything getting to launch and had nothing left to act on what launch taught them.

5. Ownership & partner fit

Do you know who runs this product day to day after launch? Will you own the accounts, code, and data from day one: domain, hosting, repository, third-party services, all in your name? And do you know what you actually need from a technical partner: pure execution, or product thinking and pushback too?

I build for your autonomy, not your dependency, and that starts at account creation, not at handover. A partner who sets up your infrastructure under their own accounts is building you a rental, whatever the contract says.

Scores at 40 or below on this branch get told, in plain terms, not to build yet, and get pointed at the validation work to do first. That's not a sales tactic in reverse; it's the same advice I'd give across a table.

Tech health check: the five health axes

This branch is for operators running a product or system today, often one they didn't build themselves. The question underneath: is your tech an asset that accelerates you, or a liability you're renting?

1. Product direction

Can you state what the product must achieve in the next six months in business terms, not a feature list? Do you know which features are actually used, backed by usage data rather than impressions? When a new feature idea appears, is there a way to decide, or does the loudest voice win?

Without a direction stated in business terms, every roadmap conversation becomes a negotiation between opinions. Data doesn't end those debates, but it changes what wins them.

2. System health

Does the system behave predictably, or do the same bugs keep coming back? Can one part be changed without fear of breaking the others? Is there a written map of the system: what talks to what, where the data lives, what runs where?

The written map is the cheapest of the three and the one almost nobody has. It turns "we don't dare touch it" into "we know what touching it involves", which is most of the difference between a fragile system and a workable one.

3. Delivery speed

Does a small change go from "decided" to "live" in days, not weeks, not "it depends"? Can you deploy any day of the week without ceremony, and roll back calmly if something goes wrong? Are changes tested before your users find the bugs for you?

Delivery speed is the honest indicator of technical health; you can't fake it. When it's slow, the cause is usually process and fear rather than technology, and both are fixable.

4. Dependency & ownership risk

If the person who built your system disappeared tomorrow, could someone else pick it up within a few weeks? Do you own, and can you access right now, every account that matters: domain, hosting, code repository, databases, third-party services? Does knowledge about the system exist anywhere outside one person's head?

The first question is the one every operator hopes nobody asks. Both red flags live on this axis, because dependency is the failure mode that doesn't show up day to day, until the day it does, at which point it's the only thing that matters.

5. AI & data leverage

Is your data somewhere you can actually query it, or scattered across spreadsheets and tools that don't talk to each other? Have you identified where automation or AI would remove real drudgery: specific tasks, not "we should do AI"? Have you piloted any of it, even small, and measured whether it helped?

This axis deliberately comes last: leverage built on unhealthy foundations amplifies the problems along with the output. But once the other four axes hold, this is where a small business punches far above its size, and "piloted and measured" beats "strategised" every time.

The two red flags that override everything

Averages hide emergencies. Two answers trigger a warning in the check regardless of the total score:

You don't own your accounts. If the domain, hosting, code repository, or data isn't in your name, your business runs on someone else's permission. A great score everywhere else doesn't offset this; it just means the thing you'd lose is more valuable. The fix is usually a week of unglamorous admin work, and it's the highest-leverage week available to you.

One person holds the whole system. If the person who built it disappeared tomorrow and nobody could pick it up within a few weeks, you have a continuity problem that compounds silently. A written system map and shared access to every account are the first two steps, and neither needs a big budget.

These carry practitioner judgment, visibly: I'd rather the check be slightly unfair to a good average than politely quiet about the two situations that actually sink businesses.

Six minutes, honestly scored.

The interactive version asks these questions and gives you a score, a per-axis picture, and a verdict I'd stand behind in person. Free, no email.

Take The Full Picture Check →

Frequently asked questions about the methodology

Is The Full Picture Check really free, with no email?

Yes. No account, no email, no PDF gate: results render on screen immediately. The share link encodes your answers, not your identity, so no personal data ever travels.

Can the verdict really be negative?

Yes. "Don't build yet" is a real result of the readiness branch, and "Hostage" is a real tier of the tech health branch. Below a certain score the check explicitly recommends not hiring anyone to build. Validation work comes first.

I'm not technical, is the check for me?

It's calibrated exactly for you. The questions are plain language, no jargon, and the tech health branch is designed for operators running a system someone else built.

What happens to my answers?

Nothing. They never leave your browser. Everything is computed client-side and nothing is stored on a server. If you want my personal read on your result, you bring it to a call yourself.