Can it be done? The most expensive way to answer that is to try for six months.
We do the hard research up front, the unknowns, the constraints, the places it could quietly fall apart, and come back with a clear yes, no, or here is what it would take.
Weighing the options
Every path gets evaluated. Some hold up. Some are dead ends. Better to learn which on a whiteboard than in month four.
The problem
"It should be possible" is not a plan. It is a guess wearing a suit.
Big technical bets usually start with a sentence like "it should be possible." Possible how, with what data, under what constraints, at what cost, nobody is quite sure, but the project gets greenlit on the strength of the optimism in the room. The hard questions get deferred, because answering them is work and the deadline is now.
The trouble is that "should be possible" hides the parts that actually decide the outcome. The model that works on English but not on your customers' languages. The integration that the documentation describes but the API does not actually support. The latency budget the architecture cannot physically hit. The data you assumed you had that turns out to be locked in a vendor's system. Each one is the kind of thing that, discovered late, does not slow the project down. It ends it.
A feasibility study answers the hard questions before the commitment, not after. We go after the unknowns deliberately, test the claims the plan depends on, and map where the real risk sits. You get a clear verdict, can it be done, at what cost, with what risks, and what would have to be true, so the go or no-go decision is made with the facts instead of the vibe in the room.
Maybe this is you. You pitched a feature in a planning meeting, it sounded reasonable, and somebody nodded and put a date on it. The model would summarize the documents. The system would sync in real time. The integration would just work, because the other vendor's site has a logo that says it does. Nobody in the room had actually tried it, but the optimism was contagious and the date was set. Three months later the team is fighting the one thing nobody checked, and the date is a memory. A feasibility study is the boring meeting that would have caught it while it was still cheap, a week of someone asking "wait, has anyone actually proven that part?" before the budget is gone.
The thing nobody says out loud
Most things are hard. A few are impossible. They cost the same to find out by guessing.
Here is the part that gets skipped. When a project stalls, everyone assumes it hit something impossible. It almost never did. Most of the things that sink a build are just hard: tedious, fiddly, underestimated, but doable by people who know what they are doing. Truly impossible things are rare. The problem is that hard and impossible look identical from the planning room. They both show up as confident nods and a date on a calendar, and you cannot tell them apart by arguing about them. The only way to find out which one you have is to go and try, and if you try by building the whole thing, the hard problem and the impossible one cost you the exact same six months before they confess.
A feasibility study is how you separate the two cheaply. You take the question that decides the project, the riskiest, most load-bearing assumption, and you attack it directly with a small test before you build anything around it. If it is hard, you learn what hard actually costs: the time, the workaround, the price tag, and you can plan for it with your eyes open. If it is impossible, you learn that in a week instead of a year, and you keep the rest of the budget. The verdict is not the only prize. The cheap, early no is the prize.
There is a second trap that hides behind the first. Buildable is not the same as worth building. A thing can clear every technical bar, you can prove it works, prove it scales, prove the integration holds, and still be a terrible idea, because the market does not want it, the unit economics do not close, or it solves a problem nobody is paying to fix. That is the line between technical risk, can we build it, and business risk, should we. We will tell you when the honest answer is "yes, this is buildable, and you still should not build it." A feasibility study that only ever validates the dream is not a study. It is a permission slip.
And the worst risks are the ones you did not think to list. The unknown unknowns, the constraint you never imagined because it lives two layers below the part you were looking at. You do not surface those by thinking harder at a whiteboard. You surface them by touching the real thing for a few days, where the surprises live. That is the quiet reason a short, deliberate spike beats months of careful planning: planning can only reason about the risks you already know to name, and the ones that kill you are usually not on the list.
How we run it
Go straight at the unknowns.
A feasibility study is worthless if it only confirms what you already hoped. The value is in interrogating the assumptions hard enough that the answer can come back no. These are the principles we run it on.
Name the questions that decide it
We start by writing down the specific questions whose answers determine whether this works: not 'is it feasible' in the abstract, but the concrete unknowns, the data, the latency, the integration, the accuracy, that the whole thing hinges on. You cannot study feasibility in general; you study the questions that actually move the verdict. Then we sort them, because not every unknown carries the same weight. A handful of questions are load-bearing: if the answer comes back wrong, the whole project falls over. The rest are details you can solve later. We find the load-bearing ones and put them first, so the study spends its time where a bad answer would hurt the most, not where it is comfortable to look.
Test the claims, do not take them
The vendor says the API supports it. The paper says the model hits that accuracy. The plan assumes the data is clean. We check, with a small test against reality, instead of taking the claim at face value. The claims that turn out to be wrong are exactly the ones that sink projects, and they only reveal themselves when somebody actually tries them. The classic version: the integration works perfectly against the free tier and the sample data, then falls over in production with real volume, real rate limits, and edge cases the docs never mentioned. Reading the documentation tells you what the API promises. Calling it with your actual data tells you what it does. We test against the second one, because that is the one you have to ship on.
Map the risk honestly
We lay out where the real risk sits, how likely each problem is, and how bad it would be if it happened. Not a wall of caveats to cover ourselves, but a clear-eyed view of what could go wrong and what it would cost, so you can decide with the downside in plain sight instead of discovering it the expensive way later. We separate the risks we tested and now understand from the ones still sitting in the unknown column, because pretending an untested risk is small is how plans quietly lie to the people approving them. A risk you have sized is a number you can plan around. A risk you have only hoped about is a trap with a date on it.
Cost the realistic version, not the dream
Feasible at what price is half the question. We estimate the real effort, the real infrastructure, and the real ongoing cost of the version that actually works, including the unglamorous parts the optimistic plan skipped. 'Possible, but it would cost triple the budget' is a no, and you deserve to know that now rather than later. The dream version is always cheaper, because it forgets the monitoring, the retries, the data cleanup, the second integration nobody mentioned, and the maintenance bill that arrives every month after launch. We cost the version with all of that in it, so 'feasible' means feasible for you, with this budget, this quarter, not feasible for someone with twice your money and no deadline.
A verdict, not a hedge
The deliverable is a decision you can act on: yes and here is the path, no and here is the wall, or yes-if and here is exactly what has to be true. We do not hide behind 'it depends.' You hired us to take a position, and we take one, with the reasoning laid out so you can push back on it. The reasoning is the point. A verdict with the evidence attached can survive a skeptical board, a nervous investor, or a new exec who shows up in month two and wants to relitigate everything. A verdict without it is just our opinion against theirs, and opinions do not hold up in the rooms where the money gets decided.
Attack the thing most likely to kill it, first
We sequence the work by what is cheapest to disprove and most expensive to be wrong about. The riskiest assumption gets tested first, in a short timeboxed spike: a thin, deliberately narrow slice aimed straight through the scary part, run on a clock so it cannot quietly grow into a half-built product. Kent Beck named this move in Extreme Programming, driving a spike through the whole design to see if it holds, and it is still the fastest way to learn. If the spike comes back no, you found out in days and saved everything downstream of it. If it comes back yes, you have earned the right to keep going, with the worst unknown already behind you instead of waiting in month four.
"'It should be possible' has killed more projects than any bug. We answer the hard questions while the answer can still change the plan, instead of ending it."
What you get
A go or no-go you can defend.
A written, evidenced answer to whether this can be built, at what cost, with what risks, clear enough to take to a board or an investor.
- A clear verdict on each question that decides the outcome: yes, no, or yes-if
- Small, real tests of the riskiest claims, instead of assumptions taken on faith
- A risk map: what could go wrong, how likely, and how much it would cost if it did
- A realistic cost and effort estimate for the version that actually works, not the optimistic one
- The constraints and conditions that any real build would have to respect
- A recommendation: proceed, stop, or proceed only if these things are true
- A written report you can hand to a stakeholder, a board, or an investor
Sitting on a big technical bet that everyone says "should be possible"? Tell us what it depends on, and we will tell you what it would actually take to be sure.
Invoke usIs this the right call
When this fits.
Good fit
- You are about to commit serious budget or time to something nobody has proven can be done
- An investor, board, or stakeholder wants evidence the idea is technically sound before they back it
- The plan rests on claims, a vendor's, a paper's, an assumption's, that nobody has actually tested
- You suspect there is a hard problem hiding in the project and want it found before you start
Wrong call
- The approach is well understood and proven. You do not need a study to tell you a standard build works.
- You have already decided to proceed no matter what the study says. Then it is theatre, and we will not take your money for it.
- You need the thing built, not assessed. If feasibility is not in doubt, skip to building it.
How it runs
Short, written, and impossible to ignore.
A feasibility study is a focused sprint, not an open-ended research project. It runs in days to a couple of weeks, sized to the questions that matter, because its value is in unblocking a decision quickly, not in producing a thick report nobody finishes reading.
The output is written and concrete, because a verdict you cannot point to is a verdict that gets relitigated in every meeting. You get the questions, the evidence, the risks, and the recommendation in a form you can forward, defend, and decide from, not a vague "we think it is probably fine."
It connects to whatever comes next. A yes flows into a proof of concept or a build with the hard parts already understood. A no saves you the budget and points at what would have to change. A yes-if gives you the exact conditions to negotiate or design around. The study ends with a next move, not a shrug.
What we settle before we begin: the specific questions that decide whether this is feasible, what evidence would make each a convincing yes or no, and the constraints, budget, timeline, data, that any real answer has to respect. Everything else follows from those three.
Tell us what everyone is assuming will work.
Describe the idea and the part everyone is taking on faith, the claim, the constraint, the data, the integration. We will tell you how to put it to the test, and give you a verdict you can actually take to a decision.