Challenge
The vendor has an API, but access needs a partner program or a sponsoring customer.
Agnotic approach
We read the program terms, request sandbox access and make a real call during the study.
Software Feasibility Study
Software feasibility study before you build
Most stalled software projects fail on an assumption nobody checked: an API that needs a partnership, data you cannot use, or a rule that changes the design. Agnotic Technologies tests those assumptions first and gives you a clear go, change or stop recommendation.
Fixed scopeEvidence per questionSpike on the riskiest partGo, change or stop
Trusted by global innovators
What is a software feasibility study?
A software feasibility study is a short, fixed-scope piece of work that tests whether a planned product can be built with your systems, data, rules and team before you commit to the build. Agnotic Technologies checks technical, integration, data, regulatory and operational feasibility and ends with a go, change or stop recommendation.
It is not a design sprint or a business plan. We do not size the market or design screens; we check whether the build can work and what would have to change if it cannot.
User experience discovery belongs to our product discovery sprint, and testing whether an AI model can do a task belongs to an AI proof of concept. A feasibility study often comes before both.
Feasibility checklist
Which questions does a feasibility study answer?
Every study covers these five dimensions. The evidence column is what we collect before we give a verdict.
| Dimension | Question | Evidence that answers it | Possible verdicts |
|---|---|---|---|
| Technical | Can this stack and team build the hardest part? | A spike on the riskiest component, run against real constraints such as data volume or response time | Proven, proven with changes, not proven |
| Integration | Do the vendor APIs we need exist, and can we get access? | API documentation, partner program terms, sandbox access and a working test call | Available, available through a partnership, not available |
| Data | Is the data good enough, and do we have the right to use it this way? | Profiled sample extracts, data contracts and the consent under which data was collected | Usable, usable after cleanup, not usable |
| Regulatory | Which rules apply to this product, and do they change the design? | A data flow map and product description reviewed with your counsel | Known and buildable, needs specialist advice, blocks the plan |
| Operational | Who runs it after launch, and can they? | Support model, on-call owner, hosting owner and running budget owner | Owned, owned with new hires, no owner yet |
A "change" verdict is common and useful: it tells you what to adjust, such as a different integration route or a smaller first release, to turn a no into a yes.
Failure points
Which unchecked assumptions most often stop a build?
What we see when projects come to us after stalling, and how the study catches each one early.
Challenge
The data has the right fields but not the right quality.
Agnotic approach
We profile real sample extracts for gaps, duplicates and formats before anyone designs around them.
Challenge
The data was collected under consent that does not cover the new use.
Agnotic approach
We check contracts and consent wording with your team and flag what needs new consent.
Challenge
A planned feature turns out to be a regulated medical device function.
Agnotic approach
We describe the intended use clearly and take it to your counsel or regulatory adviser during the study, not after the build.
Challenge
Card data would pass through your servers and bring them into PCI DSS scope.
Agnotic approach
We test a design that uses the payment provider's hosted fields or tokens instead.
Challenge
Nobody owns the product after launch.
Agnotic approach
The study names the support, hosting and on-call owners, or records that they are missing.
How it runs
How does a feasibility study run?
The same six steps on every study, scaled to the questions in scope.
Frame the decision
We write down the one decision the study supports, who makes it and what evidence would change their mind.
List and rank assumptions
Every assumption the plan depends on, ranked by how likely it is to be wrong and how much damage that would do.
Collect evidence
API documentation, sandbox requests, data samples, contracts and interviews with the people who would run the product.
Spike the riskiest assumption
A small piece of working code that tests the hardest technical or integration question against real constraints.
Review rules with your counsel
We map data flows and product functions so your legal or regulatory adviser can answer the regulatory questions quickly.
Report and read out
A written verdict for each dimension, the recommendation and a session with the decision makers.
The report
What does the feasibility report contain?
A document your team, investors or board can act on.
- A verdict for each of the five dimensions, with the evidence behind it
- One recommendation, go, change or stop, and the reasons for it
- The spike code and what it proved or disproved
- Open risks, each with an owner and a way to close it
- The scope changes that would turn a stop into a go
- Inputs for scoping the build, which you can carry into our scope builder or a discovery sprint
When to commission one
When should you commission a feasibility study?
When being wrong about one assumption would waste most of the budget.
Before committing a build budget
Leaders who want evidence before approving a full product build.
Feasibility study for startups
Founders checking that the integration or data their product depends on is really available before they raise or hire.
Before signing a vendor contract
Teams confirming a vendor's API and terms support the product they plan to build on it.
After a stalled project
Teams restarting a build that stopped, who need to know which assumption failed.
Regulated product ideas
Health, finance and payments products where one rule can change the whole design.
Scope and cost
What changes the size of a feasibility study?
We do not publish prices or fixed durations. These are the things that set the scope, and we agree them on the scoping call.
Questions in scope
All five dimensions, or a focused study on one, such as a single integration.
Integrations to check
How many vendor APIs need documentation review, sandbox access and test calls.
Data sources
How many sources need profiling and contract or consent review.
Spike size
A small proof of one function, or a working slice through several systems.
Regulatory questions
How many rules need mapping for your counsel to review.
Stakeholders
How many people need interviews and a say in the final decision.
Frameworks
Frameworks we check against
The rules and methods that come up most often in our studies.
NIST SP 800-30PCI DSS45 CFR 164.502(e)45 CFR 170.315(g)(10)FDA device software
Facts and sources
Facts behind a feasibility study
Rules and methods that often decide feasibility, each linked to its primary source.
NIST SP 800-30 Rev. 1, Guide for Conducting Risk Assessments (September 2012), describes risk assessment as giving decision makers the information they need to choose a course of action on identified risks.
Source: NIST SP 800-30 Rev. 1 (NIST CSRC)PCI DSS applies to entities that store, process or transmit cardholder data or sensitive authentication data, or that could affect the security of the cardholder data environment.
Source: PCI DSS overview (PCI Security Standards Council)A HIPAA covered entity may share protected health information with a business associate, such as a software vendor, only under a business associate agreement that commits the vendor to safeguard it.
Source: 45 CFR 164.502(e) and 164.504(e) (eCFR)ONC certification criterion 170.315(g)(10) requires certified EHRs to offer a standardized API for patient and population services based on HL7 FHIR.
Source: 45 CFR 170.315 (eCFR)
Frequently Asked Questions
It depends on how many questions are in scope, so we fix the scope and the end date on the scoping call. A focused study on one integration is much smaller than one covering all five dimensions.
Each study gets a fixed price for its scope. That scope depends on the dimensions, integrations, data sources and spike size you need checked, which we confirm in writing after the scoping call.
In software, yes. Both test whether a planned product can be built with your systems, data, rules and team. We call it a study because it ends in a written recommendation, not only an analysis.
A feasibility study asks whether the product can be built. A discovery sprint asks what the product should be for its users and plans the first release. When both are needed, the feasibility study comes first.
You save the build budget, and the report shows exactly which assumption failed and what would have to change. Some teams revisit the idea later when an API opens up or a data agreement is signed.
Usually to samples and sandbox environments, not production. We work under your data agreement, and for health data we sign a BAA before any PHI is shared.
It includes a spike, which is working code aimed at the riskiest question, not a prototype of the whole product. If the riskiest question is whether an AI model can do the task, we recommend an AI proof of concept instead.