Feasibility Studies
Before committing to a major build, understand what is realistic. Technical feasibility assessment covering architecture options, cost implications, and delivery timelines.
Before You Commit
The most expensive software projects are the ones that shouldn't have been started. Not because the idea was bad, but because nobody took the time to properly assess whether it could be built within the constraints that actually existed - the budget, the timeline, the team, the technology. A feasibility study is that assessment. It sits between "we have an idea" and "we've started building", and its purpose is to give you the information you need to make a sound decision about whether to proceed, and if so, how.
This isn't about producing a document that tells you what you want to hear. It's about understanding the technical reality of what you're proposing, identifying the risks early enough to do something about them, and giving you a clear picture of what the build will actually involve. Sometimes the answer is "yes, and here's how". Sometimes it's "yes, but not the way you're thinking". Occasionally it's "not yet" or "not at this budget". All of those are useful answers if they come before you've spent six months and a significant portion of your runway finding out the hard way.
What a Feasibility Study Covers
The scope depends on what you're assessing, but it typically includes several core areas.
Technical viability is the starting point. Can the thing you're describing actually be built? This sounds basic, but it's surprising how often a product vision assumes capabilities that don't exist yet, or that exist but carry costs or limitations that haven't been considered. I look at the proposed functionality, the data requirements, the integrations, and the performance expectations, and assess whether they're achievable with the technology and resources available.
Build vs buy is a question that comes up in almost every feasibility study. For any given piece of functionality, there's usually a spectrum of options: build it from scratch, use an existing service or platform, adapt an open source solution, or some combination. Each has different implications for cost, timeline, control, and long-term maintenance. I help you understand those tradeoffs rather than defaulting to "build everything" or "buy everything".
Architecture options matter because the same product can be built in very different ways, and the choice of approach affects everything that follows - the team you need, the infrastructure costs, the speed of iteration, the difficulty of scaling later. I'll outline the realistic options, explain the tradeoffs of each, and recommend an approach based on your specific constraints.
Cost and timeline are what most people want to know first, and they're the hardest to answer honestly. I provide realistic estimates based on the architecture and approach we've discussed, with clear assumptions stated. I'd rather give you a range that's honest than a single number that's optimistic. I've written about the challenges of scoping MVPs and the same principles apply here - clarity about what's included, what's deferred, and what the risks are.
Team requirements round out the picture. Based on the proposed build, what skills do you need? How many people? For how long? Do you need to hire, or can you contract? This feeds directly into the cost model and helps you plan the next steps if you decide to proceed.
What You Get
The output is a written report that covers each of the areas above, with clear recommendations and the reasoning behind them. It's designed to be useful to both technical and non-technical readers - founders, investors, and board members should be able to read it and understand the implications without needing a translator.
The report is yours. If you decide to proceed with a different engineer or team, the feasibility study gives them a head start. If you decide not to proceed, you've saved yourself the cost of finding out later. Either way, the investment in understanding the problem properly before committing to a solution is one that pays for itself.
When to Commission One
The right time is before you've made irreversible commitments - before you've hired a team, signed a contract with a development agency, or promised a launch date to your investors. If you're at the stage where you have a clear idea of what you want to build but haven't yet committed to how, a feasibility study will give you the foundation to make that commitment with confidence.
If you're considering a significant technical investment and want an honest assessment before you commit, get in touch.