Writing · Adapt Progress Evolve

Personal

Prove It First, Then Build It: The Feasibility Gate

Skip the feasibility check and pay for proof later with runway. Run an honest assessment against four pillars: technical constraints, data availability, integra

Filed 26 October 2026 · 4 min read

Here's the thing about skipping a feasibility gate: it feels like speed. You've got an idea, a bit of conviction, maybe a studio slot opening up, and everything in you says just start building. Confidence is cheap. Proof is the expensive bit, and you pay for it either way, just at very different moments.

If you pay before the build, it costs a few weeks of honest digging. If you pay after, it costs runway, and runway is the one thing a studio can't print more of. I've watched the pattern play out in the abstract so many times that I can describe it in my sleep: a team commits budget, discovers in month three that the data doesn't exist in the shape they assumed, and then spends month four pretending that's a pivot. It's not a pivot. It's a bill arriving late.

So what does a genuine assessment look like? Not a slide deck. Not a gut check in a kickoff meeting. It's evidence, gathered on purpose, against four things.

Technical constraints

Start with the boring question: can this actually be done with what exists today, at the quality you need? Not "can a demo be done." Demos are liars. A demo works on the three examples somebody picked. A product has to work on the ugly forty-first example nobody planned for.

So you write down the hard limits early. Latency, accuracy thresholds, cost per run, anything that would make the whole thing pointless if it missed. Then you test against those, with a throwaway prototype if you have to. The point is to try to break the idea, not to admire it. If you can't say what failure looks like in advance, you'll just redefine success when it arrives (we've all done this, I'm certainly not above it).

Data availability

This one kills more projects than anything else, quietly. Everybody assumes the data is there. Fewer people check whether it's clean, whether it's legally usable, whether it actually covers the cases that matter, or whether somebody has to spend a fortnight begging another department for access.

Look at the real thing. Open the files. Count what's missing. Ask who owns it and whether they'll say yes. A model is only as good as what you feed it, and "we'll sort the data out during the build" is basically a confession that nobody has looked yet.

Integration risk

Right, so the thing works in isolation. Great. Now it has to live inside somebody's actual systems, with their authentication quirks and their undocumented legacy API and their one engineer who knows how it all hangs together.

Integration is where tidy plans go to get humbled. Map every point where your build touches something you don't control, and then ask the awkward question about each: who can change this without telling us? If the answer is "a third party, anytime," that's a risk you price in now, not a surprise you absorb later. Absolutely nothing is more expensive than a dependency you found out about in production.

Team capability fit

The last pillar is the uncomfortable one, because it's about you. Does the team you've got actually have the skills this build demands? Not skills they could pick up. Skills they have.

A studio can talk itself into believing a team will grow into the work. Sometimes they do. But planning around a hope isn't planning, and the gap between "has shipped this before" and "is excited to try" is where schedules quietly double. Be honest about it. If the fit is partial, fine, name the gap and decide how you'll close it before the budget is committed.

Who should run it

Internal or external? Honestly, a bit of both, but not in equal measure.

Your own team knows the context, the politics, the data's quirks. That's valuable. It's also the problem, because they're emotionally invested in the idea being good, and nobody marks their own homework fairly. An external reviewer has no stake in the answer being yes. They'll poke the soft spots you've stopped seeing.

My rule of thumb: let insiders gather the facts, but let someone with nothing to lose make the call. If the same people who pitched the build are the only ones judging whether it's feasible, you haven't run an assessment. You've run a ceremony.

A scorecard you can steal

Here's a one-page framework. Take the four pillars, and for each one write three lines: what we believe, what evidence we have, and what would change our mind. Then give each pillar a simple rating, green, amber or red, based only on evidence, never on enthusiasm.

Any red stops the gate until it's resolved. Two ambers need a named owner and a deadline. All green means you've earned the right to spend the money. Add one last box at the bottom for "what we're choosing not to know yet," because pretending there are no unknowns is its own kind of dishonesty.

Keep it to one page on purpose. If it needs more, you're hiding in detail.

That's the whole gate, really. It's not glamorous, and it won't make anyone feel like a visionary. But it's cheaper than being wrong, and a studio that checks before it builds keeps its runway for the bets that deserve it.

Anyway, that's the argument. Prove it first, then build it.