General · · 4 min read
Feasibility First: Why Skipping Proof is Deferred Pain
Skipping feasibility checks feels fast but costs more later. Use evidence-based assessment across four pillars before committing budget to any build.
Skipping the feasibility check feels fast. It isn't. It's just deferred pain with interest.
Here's the thing I keep seeing: a team gets excited, someone shows a slick demo, and suddenly there's budget attached to a build nobody has actually proven can work. Confidence is cheap. Proof is the expensive bit, and that's exactly why people skip it. But the bill comes anyway, usually three months in, when the thing that "should be straightforward" turns out to need data the company doesn't have, or an integration the other side won't open up.
For studios this is worse. A studio runs on a portfolio of bets and a finite runway, so every wrong bet that limps along is a right bet that never got funded. Killing things early isn't pessimism, it's how you keep money for the builds that might actually work.
So what does a genuine assessment look like? Not a slide deck. A set of questions you answer with evidence, and I mean evidence you can poke at. I think of it as four pillars, and if any one of them is rotten, the whole thing wobbles.
Technical constraints come first. What does the product need to do, and what are the hard limits on doing it? Latency, accuracy, cost per call, the hardware it runs on, whatever the actual ceiling is. The trap is assuming a capability exists because you've seen something similar. Similar isn't the same. A feasibility pass means you build the ugliest possible version of the riskiest part and see whether it holds. Not the whole product. Just the scary bit.
Data availability is where I've watched the most optimism die. Everyone assumes the data is there, clean, and legally usable. Anyway, it usually isn't, or it's there but scattered across three systems, or it exists but nobody's allowed to touch it. Ask to see it. Actually open the files. Check volume, quality, labelling, who owns it, and whether you can use it for this purpose. If the answer is "we'll sort that out during the build," you've just found your first red flag, right?
Integration risk is the quiet killer. The product might work beautifully in isolation and then meet the real world, where it has to talk to a legacy system, a vendor with a slow API, or a security team with opinions. Map every point where your build touches something you don't control. Then ask who controls each one, and whether they've agreed to anything. Verbal enthusiasm from a partner is not an integration plan. I mean it; I've seen whole roadmaps hang on a single "yeah, we can probably expose that endpoint."
Team capability fit is the one people find awkward to say out loud. Can the people you actually have build this? Not people you could hire, not people who'd be perfect. The ones in the room. A brilliant team can still be wrong for a specific problem, and a build that needs deep expertise in something nobody's done before is a different bet from one that's a stretch of what they already know. Be honest about the gap, then decide whether closing it is part of the budget or a hidden cost.
Now, who runs this? Internal or external?
Internal teams know the context, which matters, and they're faster to start. But they're also the people who want the project to happen. That's a conflict, even if nobody means it badly. Nobody likes writing the report that says their own idea doesn't hold up. External reviewers have no stake in the answer, so they can say the awkward thing, though they lack the history and need onboarding. My view: use an internal lead for the legwork and give an outsider the right to challenge the conclusions. For a studio, where the same operators back multiple ideas, that independent check is worth more than it looks. You want someone whose job is to be sceptical, not supportive.
Finally, make it usable. Here's a one-page scorecard you can adapt, and please change it to fit your own bets.
List the four pillars down the left. For each, write the single riskiest assumption in plain words. Next to it, note the evidence you actually have, not the evidence you expect to get. Then score confidence on a simple scale of your choosing, and be strict: no proof means a low score, however good the story is. Add a column for "cheapest test," the smallest thing that would confirm or kill that assumption. Add another for an owner, because an unowned risk is just a worry. Finish with a short decision line: go, go with conditions, or stop.
The rule that makes it work is simple. Any pillar scoring low blocks the build until a test moves it. No exceptions for enthusiasm, no "we'll de-risk it later." Later is where budgets go to die.
None of this is glamorous. It's a gate, and gates are boring. But I'd rather be the person who killed a bad idea in a fortnight than the one explaining where the runway went. Proof first, then build. Confidence can come along afterwards, if it wants.
Filed under General