A technical feasibility assessment answers one question before you spend months building: can this product be made to work, with the money, people and time you have? It is mostly desk research and expert calls, and it takes two to four weeks. The output is a component list rated by readiness, a cost and time range, and a short list of unknowns that need a proof of concept. Founders who skip it discover the hardest part of their product halfway through the build.

What is a technical feasibility assessment and when should you use it?

A technical feasibility assessment breaks a product into the capabilities it needs and checks, one by one, whether each already exists, needs adapting or has never been done. The most widely used yardstick is NASA's Technology Readiness Level (TRL) scale, which runs from level 1 (scientific principles observed and reported) to level 9 (proven in real operation). The NASA TRL definitions are public, and EU programmes such as Horizon Europe use the same scale in their calls.

Use this SOP:

Before you hire developers or sign a development agency, so you know which parts are routine and which are research.
When your idea depends on AI accuracy, new hardware, sensors or a scientific result.
Before applying for grants or deep tech funding, where you must state your TRL.
When a customer asks "Can you really do that?" and you need an honest answer.

This SOP happens on paper and in conversations. Building the riskiest part to prove it works is the proof of concept SOP, and choosing languages, frameworks and hosting is the technology stack validation SOP.

What do you need before you start?

A product description in plain words: what it does for the customer, with the numbers that matter (accuracy, speed, cost per use, battery life).
Evidence the problem is real, from customer interviews.
Access to 2 or 3 technical experts in the relevant field, through your network, a university or LinkedIn.
A research log in Notion or a document where every claim gets a source.
A budget ceiling for the first version, so feasibility includes "within our means".

How do you run it, step by step?

1. Turn the product into capabilities with numbers

List what the system must do, each with a measurable requirement: "recognise 20 plant diseases from a phone photo with 85% top-3 accuracy, offline, in under 3 seconds." Requirements without numbers can't be judged feasible or not. Five to fifteen capabilities cover most early products.

2. Split capabilities into components

For each capability, list the parts needed: data, models or algorithms, hardware, third-party services, user-facing software. Mark each component as off-the-shelf, adapt existing or new. Most of your risk sits in the "new" column.

3. Rate each component on the TRL scale

Give every component a TRL from 1 to 9 and write the evidence next to it: a product already on sale, an open-source library with active users, a published paper, a lab demo. No evidence means a low score. A component is only as ready as the best real-world proof you can point to.

4. Research prior work

Search GitHub for open-source projects, Google Scholar and arXiv for papers, Google Patents for patents, and competitor products for proof that something works at scale. Note where results were achieved: lab data and real-world data give very different numbers. Check licences and patents that could block you.

5. Talk to 2 or 3 technical experts

Bring specific questions: "Is 85% accuracy on field photos realistic with 5,000 training images?" Ask what failed for them and what they would test first. The expert interview SOP has a script that adapts well to technical calls.

6. Estimate cost, time and dependencies

For each component, give a range of cost and weeks, plus who could build it (you, a hire, an agency, a vendor). Add rules and certifications that apply, such as data protection law for personal data or medical device rules for health claims. Rank risks by likelihood and impact.

7. Write the feasibility verdict and proof of concept plan

Choose one of four verdicts: feasible as planned, feasible with a narrower scope, feasible only after a proof of concept, or not feasible within your means. For each component below TRL 6, write what a proof of concept must show, with pass criteria and a budget.

Template you can copy

Capability	Requirement (with number)	Component	Type (off-the-shelf / adapt / new)	TRL 1-9	Evidence and source	Cost range	Weeks	Risk (likelihood x impact)	Needs proof of concept?

FEASIBILITY VERDICT
Lowest TRL component: ________ (TRL __)
Total build estimate: $____ to $____, ____ to ____ weeks
Rules and certifications: ________
Verdict: feasible / feasible with narrower scope / proof of concept first / not feasible
Proof of concept plan: component ____, must show ____, budget $____, deadline ____

Worked example: an offline plant disease app for small farms

This is an illustrative case. A founder wants a phone app that identifies crop diseases from a photo without an internet connection. Her assessment rates five components:

Component	TRL	Evidence
Camera capture and image handling	9	Standard phone features
On-device model inference	8	Mobile machine learning libraries such as TensorFlow Lite run in shipped apps
Disease classifier trained on lab photos	6	Public plant disease image datasets and published papers
Accuracy on real field photos (mixed light, dirt, angles)	4	Papers report much lower accuracy outside lab conditions
Treatment advice in local languages	9	Content work with agronomists

Two experts confirm that field accuracy is the open question. Her verdict: proof of concept first. The plan: collect 300 field photos from 10 farms, fine-tune an existing model and reach 85% top-3 accuracy within 6 weeks and $4,000. Everything else waits until that result is in.

What should you measure, and when do you stop?

Metric	Pass signal	Warning signal
Components rated with evidence	Every component has a TRL and a source	Ratings based on "should be possible"
Lowest readiness level	All components at TRL 6 or above, or a funded proof of concept for those below	A component at TRL 1-3 that the product can't work without
Unknowns needing a proof of concept	1 to 3, each with pass criteria	More than 5, or none identified at all
Estimate range for build cost and time	Upper estimate fits your budget and runway	Upper estimate exceeds your runway

Stop when every component has a rating with a source and two experts have reviewed the riskiest ones. If a must-have component sits at TRL 1 to 3, the project is research, and research needs grant funding or a longer runway before it becomes a startup.

Which mistakes should you avoid?

Rating from demos and press releases. A video of something working is not the same as a product on sale.
Trusting lab results for real conditions. Ask what data and environment produced the number.
Skipping rules and certifications. Medical, financial and children's products carry approval steps that change cost and time.
Only asking people who want to build it for you. Agencies have a reason to say yes; independent experts don't.
Leaving out cost per use. A model that works at $2 per request fails a product priced at $5 a month.

How can AI speed this up?

AI research assistants can find papers, repositories and patents for each component in minutes and summarise the reported results. Ask for the source of every claim and open each one yourself, because AI tools produce convincing citations that don't exist. Never assign a TRL from an AI summary alone. Use it to build the reading list and the expert questions, then let real sources and experts set the ratings.

The F/MS AI co-founder can help you turn the verdict into a build plan and a budget.

Where does this SOP fit in your validation plan?

Run it after you have evidence of customer demand and before you commit money to building.

Prove the riskiest component with the proof of concept SOP.
Pick tools for the routine parts with the technology stack validation SOP.
Check how the components fit together with a technical architecture review.
Add the security validation SOP when you handle personal or payment data.
Compare with rivals' technical choices through competitive technology analysis.

See all Technical Validation SOPs. If your TRL rating points to grant funding, the F/MS guide to EU grants for startups explains which programmes fit which stage, and the EU Funding and Tenders Portal guide covers how to find open calls.

FAQ

What is included in a technical feasibility study?

A list of capabilities with measurable requirements, a component breakdown, a readiness rating for each component, prior work and expert input, cost and time estimates, and a verdict with a plan for the unknowns.

What are technology readiness levels?

A nine-level scale created by NASA, from TRL 1 (scientific principles observed and reported) to TRL 9 (proven in real operation). EU funding programmes use the same scale.

How long does a technical feasibility assessment take?

Two to four weeks for most startups. Hardware and deep tech products take longer, since expert calls and literature searches cover more ground.

Do I need a technical co-founder to assess feasibility?

It helps, but you can run the process yourself with expert calls. Pay 2 or 3 independent experts for an hour each instead of relying on someone who wants the build contract.

Technical Feasibility Assessment SOP