Writing · Adapt Progress Evolve

Personal

The Four Pillars of Feasibility: Before You Build

Most studios fail not because they built wrong, but because they never tested if their idea could exist. A feasibility gate with four pillars—technical constrai

Filed 23 October 2026 · 4 min read

Most studios don't fail because they built the wrong thing badly. They fail because they built the right-sounding thing without ever checking whether it could exist. That's the cost of skipping a feasibility assessment, and it isn't a slow leak. It's runway, gone, on a bet nobody actually tested.

Confidence is cheap. Everyone in the room has it. The pitch deck has it, the demo has it, the founder who's been living with the idea for six months has it in bucketloads. What's expensive is proof, and the gap between the two is exactly where budgets go to die.

So here's what a genuine feasibility gate looks like. Not the full build lifecycle (that's a different piece, and it's the pre-build checklist's job). Just the gate. The single moment where you decide whether to commit money, or walk away with your runway intact.

Anyway, four pillars. Each one needs evidence, not opinion.

The first is technical constraints. You need to know whether the thing you're describing is possible at the quality you're promising, with the tools you can actually get your hands on. I mean really possible, not "the model did it once in a notebook" possible. Run the ugly prototype. Throw real inputs at it, the messy ones, the ones your customers will definitely send. If the answer only works on the clean examples, you don't have an answer yet. You have a demo, and demos lie politely.

The second is data availability. This one trips up more builds than anything else, honestly. A team falls in love with an approach and only later realises the data it needs is locked in someone else's system, or doesn't exist, or exists in a state that would take months to clean. Ask the boring questions early. Who owns it? Can you legally use it? Is there enough of it? Is it any good? If nobody can answer those in plain language, that's your finding, and it's a significant one.

Third, integration risk. Your product doesn't live alone. It has to plug into somebody's existing stack, and existing stacks are weird, brittle, half-documented things held together by habit. Find out what you're connecting to before you promise anything. Get a look at the actual interfaces, the actual limits, the actual people who control access. A feature that depends on a partner's goodwill isn't a plan, it's a hope with a deadline attached.

Fourth is team capability fit. This is the pillar people dodge because it feels personal. But the question is simple: does the team you have, or can realistically hire, have the skills this specific build demands? Not skills in general. These ones. A brilliant generalist squad can still be the wrong squad for a problem that needs deep, narrow expertise. Be honest here. Feeling capable and being capable are different things, and I say that as someone who has absolutely confused the two before.

Now, who runs it?

Internal people know the context. They understand the market, the customer, the politics, the history. That's genuinely useful. But they also have skin in the game, and that bends judgement in ways nobody notices. If you've been championing an idea for months, you're not the person to assess whether it works. You're the person who wants it to.

External assessors bring distance. They've seen the same failure modes across lots of builds, and they have no reason to flatter you. The downside is they lack your context, so they can miss the thing that only an insider would catch.

The practical answer, for most studios, is a mix. Let internal people supply the context and the access, and let someone outside the idea's emotional orbit make the call on the evidence. Separate the people who gather from the people who judge. That single rule fixes more bias than any scoring system will.

Which brings me to the scorecard. Keep it to one page, because if it takes longer than that nobody will use it.

List the four pillars down the side. For each, write the single biggest assumption the build depends on. Next to it, write what evidence you actually have (not what you expect to find). Then mark the evidence as proven, partial, or unproven. That's it. Proven means you've seen it work on real inputs. Partial means you've got signals but gaps. Unproven means it's belief.

Add one more column: what would change your mind? If nothing could, you're not assessing, you're decorating a decision you've already made.

The rule for reading it is blunt. Any pillar that's mostly unproven stops the build until you've closed the gap cheaply, or you walk. Two or more unproven pillars, and you probably shouldn't be spending build money at all. You should be spending small experiment money.

That's the whole point of the gate, really. It turns a big scary commitment into a handful of small, answerable questions. Studios live or die on how many bets they can place before the cash runs out, and every bet you kill early is runway you get to spend on one that might actually work.

Skipping the gate feels fast. It's the slowest thing you can do.