Feasibility study: the five tests, and how to run them in a day

What a feasibility study actually decides

A feasibility study is a structured pre-commitment assessment that tests whether a proposed venture is technically buildable, economically viable, legally permitted, operationally staffable and schedulable — producing a go, revise or stop decision before capital is committed.

The word doing the work is pre-commitment. Everything a feasibility study is for happens before the money moves. Run afterwards, the same analysis becomes a justification exercise, because the person running it now has a position to defend.

That is also the difference from a business plan. A business plan assumes the venture should exist and describes how it will run. A feasibility study is allowed — required, really — to conclude that it should not. A study that cannot produce a stop is not a study.

The five tests

The standard framework is TELOS: Technical, Economic, Legal, Operational, Scheduling. Five independent tests, and the point of the structure is that any one of them is disqualifying. A venture that scores brilliantly on four and fails the fifth is not four-fifths feasible. It is infeasible.

1. Technical — can it be built?

Not "is it theoretically possible". Whether it can be built by the people you will actually have, with technology that exists now, at a quality the market will accept.

The honest version of this test asks three things. What is the hardest single component, and has anyone shipped it? What does the system depend on that you do not control — an API, a data source, a model provider, a licence? And what happens to the product when that dependency changes its terms?

The last question is where most software feasibility studies are thin. A product built on someone else's platform inherits their pricing decisions and their deprecation schedule.

2. Economic — does the arithmetic close?

This is the test that kills the most ventures, and the one most often replaced with a spreadsheet that grows 20% a month because the cell above it did.

At minimum you need three numbers and their relationship: what it costs to acquire a customer, what a customer is worth over their life, and how long the payback takes. Two widely used floors:

• LTV/CAC of 3.0 is the common definition of healthy. Around 1.5 is the point below which payback becomes arithmetically impossible once you account for churn and margin.
• CAC payback of 18 months is the standard early-stage benchmark. Past roughly 36 months, the model has stopped being a business.

These are not laws. They are the thresholds most investors will apply to you, which makes them the thresholds worth testing against before someone else does.

The market-size half of the economic test has its own failure mode. A single analyst report is not evidence; it is one estimate with a publication date and a methodology you cannot see. Combining several is better, but only if you handle disagreement honestly — dropping wild outliers, and treating a set of estimates published years apart as stale rather than averaging across a changed market. INITE Studio's own implementation drops outliers more than 3σ from the median once there are at least four sources, and flags a set whose published years span more than five.

3. Legal — is it permitted?

The cheapest test to skip and the most expensive to fail, because a legal problem discovered after launch is rarely fixable by iteration.

Three questions. Is the activity itself licensed or restricted in your target markets? What data will you hold, and what regime governs it? And whose intellectual property does the product touch — training data, scraped content, a competitor's protected process?

For anything touching health, money, employment, children or personal data, this test moves to the front of the queue. In those domains the regulatory answer determines the product design, not the other way round.

4. Operational — can you run it?

A product that works in a demo and cannot be operated is infeasible. This test asks who does the work once the thing exists: support, moderation, fraud, onboarding, the slow accumulation of edge cases.

The specific trap for AI products is that the demo is autonomous and the production system is not. If every ambiguous case needs a human, the operational cost per customer is a staffing line, not a compute line — and it scales linearly with customers, which is the shape of a services business wearing a software business's margins.

5. Scheduling — does the timeline survive dependencies?

The weakest of the five as usually practised, because it is normally answered with a Gantt chart drawn backwards from a desired date.

The useful version asks what the project's longest genuinely serial chain is — the things that cannot be parallelised no matter how many people you add. Regulatory approval, a hardware lead time, a partner integration, a seasonal sales cycle. Then it asks what happens to the economic test if that chain runs 50% long, because it usually does.

Where the classic template fails software

The five tests were formalised for capital projects — plants, bridges, systems procurement. Two of the assumptions do not transfer.

The study is not a one-time gate. For a capital project, feasibility is assessed once because the commitment is irreversible. Software commitments are staged, which means feasibility should be reassessed at each stage — and the weights should change. Whether the team can build it matters far more once there is a product than it did when there was only an idea.

That is why INITE Studio's audit weights its lenses by stage rather than applying one fixed formula. At idea stage the problem-solution fit carries 35% of the weight and traction carries 5% — because there is no traction to measure, and pretending otherwise just adds noise. At later stages the distribution moves toward evidence that now exists.

The output is usually a number, and a number is not a decision. Most feasibility templates end in a score or a rating. A score with no threshold is an opinion with a decimal point.

The fix is to write the failure conditions before you gather evidence: the specific metric, the specific value, and the date by which it must be true. Pre-committing those conditions is what makes the eventual stop a decision rather than an argument, because the person who has to accept it already agreed to the terms.

For the same reason it is worth being explicit about what a positive result requires. INITE Studio's audit will only return GO when four conditions hold together: a composite score of at least 80, zero red flags, average confidence across lenses of at least 0.6, and no unresolved contradiction between lenses. Any one missing and the verdict is REFINE or KILL — not because the idea is bad, but because a confident answer is not available yet.

What it is not: four adjacent artifacts

Half the confusion about feasibility studies comes from four documents that overlap with them and answer different questions.

The two that get substituted most often are the business plan and the proof of concept, and both substitutions are expensive in the same way: they answer a narrower question and get treated as though they answered the broad one. A working prototype proves the technical test and says nothing about the economic, legal or operational ones. A polished plan proves someone can write.

Who runs it, and the conflict nobody names

A feasibility study is usually commissioned by the person who wants the project to happen. That is a structural conflict, and it is the reason so many studies conclude that the project is feasible.

Three practical defences.

Write the kill conditions before gathering evidence. Once you know the numbers, you will pick thresholds the numbers already clear. Twenty minutes spent on thresholds first is the cheapest bias control available.

Give one dimension to someone who does not want the project. The legal and operational tests are the two most often waved through, and they are the two where an unmotivated reader adds the most.

Record what would change the answer. A study that says "go" without stating what evidence would flip it to "stop" has not been falsifiable at any point, which means it was never a test.

The failure patterns

Six that recur, and what each looks like from outside:

The fourth deserves a note, because it is the one that looks most like work. A single published market figure is one estimate with a methodology you cannot inspect. Two figures that disagree are more informative than one that does not, and a set published years apart describes several different markets rather than one.

A worked example

A team wants to build a compliance-reporting tool for clinics in three European countries. Run the five tests in the order that can end the study soonest.

Legal, first, because the domain is regulated. Patient data in scope means GDPR plus national health-data rules that differ across all three target countries. The finding is not "this is illegal" — it is that the product needs a data-residency story per country, and that changes the architecture. Cost of finding this now: an afternoon. Cost of finding it after building: the architecture.

Economic, second. Say roughly 9,000 clinics of the right size across the three markets, a plausible ACV of €4,000, and a sales motion that needs a person in the loop. That is a SAM near €36M and a CAC that is not self-serve-shaped. At €4,000 ACV and a 70% gross margin, monthly gross profit per customer is about €233, so an 18-month payback allows a CAC around €4,200 all-in — which a field sales motion will exceed comfortably, and an inside-sales motion might clear. The test does not fail; it tells you the channel is the constraint, and the channel now has to be proven, not assumed.

Technical and operational together. The reporting logic is tractable. The operational question is who resolves ambiguous records — and in a compliance product, an ambiguous record cannot be auto-resolved. That is a human review queue, which is a staffing line that scales with customers.

Scheduling last. The serial chain is the per-country data-residency work plus at least one reference customer per market before the second will sign. Re-run the economic test with that chain 50% long and see whether the funding plan still closes.

The verdict here is not go or stop. It is revise: the product is feasible with an inside-sales motion and a review-queue cost model, and infeasible with the self-serve assumptions the team started from. That is the most common useful outcome, and a study that can only say yes or no cannot produce it.

Running one in a day

For a software product, the sequence that works:

1. Write the kill conditions first. Before any evidence. Three to five, each with a metric, a threshold and a date. This takes twenty minutes and determines whether the rest is honest.
2. Legal test first if the domain is regulated. It can end the study, and it is the one test that cannot be fixed by building differently.
3. Economic test second. LTV/CAC, payback, and a market size assembled from several sources with the disagreement left visible rather than averaged away.
4. Technical and operational together. They interact: the technical shortcut usually shows up as an operational cost.
5. Scheduling last, against the serial chain, then re-run the economic test with the timeline 50% long.
6. Write the decision, not the score. Go, revise or stop, and the specific evidence that would change it.

The last step is the one that gets dropped, and it is the whole point. A feasibility study exists to make a decision cheap to reverse and expensive to fudge.