A feasibility assessment tests whether a software idea can be built, integrated, secured, operated, and justified before serious budget is committed. It is a short, evidence-led gate before development, aimed at finding the assumptions that could make the project too risky, too expensive, or too weak to fund.
This is different from broad discovery or requirements work. Discovery may explore user needs, service shape, and business context. A technical feasibility assessment asks a narrower question: can this idea survive contact with real systems, data, constraints, costs, people, and delivery capacity?
Bad software ideas often fail because a hidden dependency appears too late. It might be a legacy integration, weak source data, security limit, poor operating model, or unsupported vendor assumption. CISQ estimated the cost of poor software quality in the U.S. at $2.08 trillion in 2020, including $260 billion tied to unsuccessful IT and software projects.
A good feasibility assessment helps you kill bad ideas cheaply, reshape risky ones, and fund the ones that have a credible path.
What a feasibility assessment should prove
A feasibility assessment should prove whether the proposed product can work in the environment where it must live. It should test technical fit, integrations, data readiness, security, operations, delivery capacity, and commercial logic. The output should be a clear go, change, or stop decision, backed by evidence.
At minimum, the assessment should answer five questions. Can we build it with known technology and available skills? Can we connect it to the systems it depends on? Can we access and trust the data? Can we secure and support it? Is the result worth the cost?
PMI's guidance on project feasibility says project selection should assess performance, strategic contribution, economic feasibility, and alternatives. That matters because a technically possible product can still be the wrong investment if a smaller release, SaaS tool, workflow change, or integration solves the same problem faster.
Government delivery guidance also says a feasibility study should assess whether a proposal is achievable and worthwhile before committing time, money, and resources. It recommends an evidence-based and proportionate approach, which is the right mindset before software development starts.
The proof does not need to remove every unknown. It needs to be strong enough to support a funding decision.
When to run one before software development
Run a feasibility assessment when the idea is defined enough to test, but before the team commits to a full build plan, fixed scope, or vendor contract. It is most useful when technical unknowns could change budget, timeline, architecture, compliance path, product scope, or the decision to proceed.
Common triggers include a new digital product, workflow automation project, legacy modernization, AI feature, data platform, or product that depends on third-party APIs. You should also run one when stakeholders want a fixed estimate before engineers have checked the real constraints.
The GOV.UK Service Manual describes discovery as a phase that explores user needs and constraints such as legislation, contracts, legacy systems, and processes before deciding whether to continue to alpha. It says a typical discovery takes around 4 to 8 weeks. A technical feasibility assessment can sit inside discovery or run as a tighter pre-build gate.
It is especially useful before a major estimate. If the team has not tested data access, integration limits, security requirements, hosting constraints, and support needs, the estimate is mostly a guess with formatting.
For early-stage products, this work can shape an MVP development plan by separating assumptions that must be tested from scope that can wait. For internal systems, it can support business analysis work before requirements become too detailed.
The seven checks that matter most
The seven checks that matter most are technical approach, integration reality, data readiness, security and compliance, operational support, delivery capacity, and commercial logic. Together, they show whether the idea is buildable and worth funding. Skip one, and the project can look healthy while carrying a serious hidden risk.
1. Technical approach
Start with the architecture, platforms, frameworks, hosting model, and build path. The goal is not to design the whole system. It is to see whether the core approach is credible.
Look for parts of the idea that depend on untested assumptions. This might include real-time processing, AI accuracy, offline sync, device compatibility, complex permissions, or performance under heavy load.
Useful evidence includes proof-of-concept code, architecture notes, benchmark results, vendor documentation, platform limits, and engineer review. The result should be a short position: proven, plausible with risks, or not proven enough to fund yet.
2. Integration reality
Many software ideas depend on systems the product team does not control. Payment providers, ERPs, CRMs, EHRs, logistics platforms, identity providers, and government systems can all shape the build.
Check API access, rate limits, authentication, data formats, vendor costs, sandbox quality, webhook support, uptime history, and contract restrictions. A short requirement such as "sync with the ERP" can hide months of work.
The best evidence is a live API test, sandbox connection, sample payload, or written confirmation from the system owner. If the integration is blocked, unstable, or manual behind the scenes, the plan should change early.
3. Data readiness
Data problems often look like product problems until someone inspects the source. The team needs to know whether required data exists, who owns it, how clean it is, how often it changes, and whether the product can legally use it.
Check duplicates, missing fields, old records, inconsistent naming, access rights, retention rules, and migration effort. If AI or analytics are involved, test whether the dataset is large enough and reliable enough for the expected output.
Do not accept "we have the data" as proof. Ask for a sample, profile it, trace its source, and test the most important transformations.
4. Security and compliance
Security feasibility is not a final audit, but it should find constraints that can change scope. Authentication, authorization, encryption, audit logging, data residency, consent, regulatory duties, and vendor risk can all affect architecture.
Government project guidance for digital discovery includes testing service demand, user needs, technical feasibility, cyber security, service operation, and maintenance. That is a useful baseline for private-sector projects too, because security issues become expensive when found after architecture decisions.
Evidence can include threat modeling notes, compliance requirements, identity provider constraints, penetration testing needs, data classification, and legal review. The decision should state whether the current concept can meet the expected security bar.
5. Operational support
A product that can be built but cannot be operated is not feasible in practice. Someone must monitor it, respond to incidents, handle failed jobs, manage user support, patch dependencies, pay vendors, and own uptime.
Check support hours, SLA expectations, admin tools, logging, observability, backup, disaster recovery, release process, and ownership. If the product touches revenue or regulated workflows, operations cannot be left until launch week.
6. Delivery capacity
Feasibility also depends on whether the organization can deliver the work. The right plan may still fail if experts are unavailable, stakeholders cannot make decisions, or procurement delays block dependencies.
Assess team skills, vendor availability, timeline pressure, decision rights, budget range, procurement needs, and dependencies on other programs. For custom builds, connect this to the custom software development process and real delivery capacity.
7. Commercial logic
Technical feasibility does not mean the project should proceed. The assessment should compare likely cost, benefit, alternatives, and risk of doing nothing.
Ask whether the same outcome could be reached with a workflow change, SaaS product, integration, internal tool, or smaller release. Compare build cost with maintenance cost, migration cost, training, support, and future change.
A practical feasibility scorecard
A practical scorecard turns mixed findings into a decision that executives, product owners, and engineers can discuss without vague confidence levels. Score each dimension using evidence, record red flags, and assign a likely decision. Keep it short enough to use in a workshop.
| Dimension | Evidence to collect | Red flags | Likely decision |
|---|---|---|---|
| Technical approach | Architecture sketch, prototype, platform limits, performance test | Core feature depends on unproven technology or unclear scaling path | Change or stop |
| Integrations | API docs, sandbox test, sample payloads, vendor confirmation | No API access, strict rate limits, fragile manual exports | Change |
| Data readiness | Data sample, field profile, ownership map, migration estimate | Missing source data, poor quality, unclear rights to use data | Change or stop |
| Security and compliance | Data classification, identity needs, audit logging, legal constraints | Regulated data with no security owner or no compliance path | Stop until resolved |
| Operations | Hosting plan, support model, monitoring needs, runbook outline | No owner for incidents, maintenance, releases, or vendor failures | Change |
| Delivery capacity | Role map, delivery plan, decision owners, dependency list | Timeline assumes people, approvals, or vendors that are unavailable | Change |
| Commercial logic | Cost range, benefit case, alternatives, support cost | Build cost only counts first release and ignores lifetime cost | Change or stop |
Use a simple rating for each row: green, amber, or red. Green means evidence supports proceeding. Amber means proceed only with a scope, design, budget, or timeline change. Red means stop or run a focused spike before approving the build.
This is where feasibility separates itself from normal requirements work. Requirements gathering captures what the system should do. Feasibility asks whether the proposed way of doing it survives proof.
How to turn findings into a go, change, or stop decision
Turn findings into a decision by tying each risk to evidence, impact, and the next funding step. A feasibility assessment should end with one of three calls: go, change, or stop. Anything softer leaves the team with the same uncertainty it had before the work began.
A go decision means the major risks have evidence behind them and the remaining unknowns can be handled during delivery. It does not mean the project is risk-free. It means the risk is understood, priced, and manageable.
A change decision means the idea is worth pursuing, but the current plan is wrong. The team may need a smaller MVP, different architecture, phased rollout, new vendor, revised integration path, or more time for data cleanup.
A stop decision means the evidence does not justify the next investment. This can be a good outcome. Stopping a weak idea after two weeks is far cheaper than stopping it after six months of development.
The decision should include:
- A short verdict: go, change, or stop
- Evidence behind the verdict
- Top technical risks and owners
- Scope changes required before build
- Budget and timeline implications
- Open questions that still need proof
- Next approval gate
For larger projects, connect this decision to delivery governance and project management so risks remain visible after the assessment ends.
Common red flags that should change the plan
Common red flags include untested integrations, missing data access, unclear ownership, security assumptions, vendor lock-in, unrealistic timelines, and business cases that ignore support costs. One red flag does not always kill a project, but it should change scope, sequencing, budget, or approval conditions before development begins.
Watch for these warning signs:
- The product depends on an API nobody has tested.
- Required data exists in spreadsheets with no owner or quality checks.
- Security review is planned after architecture decisions.
- The timeline was set before technical review.
- The business case ignores maintenance, hosting, support, and vendor fees.
- The first release tries to solve every workflow variant.
- Users need real-time behavior, but the source systems update slowly.
- A legacy system owner cannot confirm access, format, or change windows.
- Nobody owns post-launch operations.
- The team cannot explain what would make the project stop.
These red flags do not always mean the idea is bad. They mean the current plan is under-tested. In many cases, the right move is a smaller proof of concept, a narrower MVP, or a staged build that tests the riskiest assumption first.
A useful feasibility assessment protects the budget before optimism becomes expensive. It gives decision-makers the evidence they need to fund with confidence, change the plan while change is still cheap, or stop before development momentum takes over.
