Inside BSH's Discovery Process

The most expensive code is the code you should not have written

Almost every troubled software project we have inherited had the same root cause: building started before anyone truly understood the problem. At BSH Technologies, discovery is not a sales formality we rush through to get to a contract. It is a deliberate, time-boxed phase with its own deliverables, and it is where we earn a client's trust or lose it.

The goal is simple to state and hard to do well: turn a fuzzy idea into a shared, written understanding of what we are building, for whom, and why, before significant money gets spent. Everything downstream, the scope, the estimate, the architecture, depends on getting this part right, and no amount of skilled engineering later can fully recover from a misunderstood problem at the start.

What a discovery actually looks like

A typical discovery with us runs one to three weeks depending on the size of the engagement. It is collaborative; we are in the room, often virtually, with the people who understand the business, not just the people who will sign the contract. We come with questions, not slides.

1. Stakeholder interviews. We talk to the people who feel the pain: the operations lead drowning in spreadsheets, the support team fielding the same complaint every day, the founder with a vision in their head. We are listening for the problem behind the requested feature, which is often different from the feature itself.
2. Current-state mapping. We document how things work today, including the manual workarounds, the shared spreadsheet that secretly runs the business, and the legacy system nobody wants to touch. The mess is the requirement, and ignoring it is how projects fail.
3. Goal and constraint definition. We get explicit about what success actually means, what the real budget and timeline are rather than the polite ones, and which constraints are genuinely non-negotiable.
4. Risk surfacing. We name the things most likely to go wrong: a fragile third-party integration, an unclear data source, a regulatory wrinkle, a key stakeholder who has not been consulted yet and will have opinions later.

From conversation to artifacts

Talk is cheap and easily forgotten, so discovery produces written artifacts that outlive any meeting. By the end, a client holds documents they can actually use, even if they ultimately decide to work with someone else. These are not throwaway slides; they are working reference material.

• A concise problem statement that everyone in the room agrees describes the real issue.
• A prioritized scope that cleanly separates the essential first release from the nice-to-haves.
• A rough architecture sketch showing how the major pieces fit together and where the integrations live.
• A risk register with our honest assessment of what could derail things and how likely each risk is.
• A realistic estimate range, with the assumptions that drive it spelled out in plain language.

We deliberately present an estimate range, not a single confident number, because anyone who quotes a precise figure for a project they just heard about is guessing and hiding it. The range, and the assumptions beneath it, are far more honest and far more useful than false precision.

Why we push back during discovery

One of the most valuable things we do in this phase is disagree, respectfully. A client comes in asking for a specific feature, and our job is sometimes to say that the feature will not solve the underlying problem, or that a much simpler approach will get them most of the value for a fraction of the cost. Discovery is the cheapest possible place to have that argument, because nothing has been built yet.

We have talked clients out of building things. We have suggested that an established off-the-shelf tool would serve them better than custom development for one part of their need, even though that meant less work for us. That honesty occasionally costs us scope in the short term. It consistently earns us long-term partners and referrals, which is the trade we will make every time.

Discovery is not a leap of faith

Because discovery is time-boxed and produces concrete deliverables, it is a low-commitment way to start. A client does not have to bet a large budget on a hunch. They can fund a short, well-defined phase, see exactly how we think and communicate, and then decide whether to proceed with full knowledge rather than blind optimism. We have had clients use a discovery purely to get a clear plan they then took to their board for funding, and we are glad to be useful in that way too.

It also means the proposal that follows discovery is grounded in evidence rather than guesswork. When we hand over an estimate, it is backed by everything we learned, which is why our post-discovery projects so rarely produce the nasty surprises that custom software is infamous for.

The payoff: fewer surprises later

Discovery is where we replace optimism with evidence. A project that starts from a clear, shared understanding moves faster, changes direction less often, and produces far fewer of the painful, budget-eating surprises that give custom software its bad reputation in the first place.

It is also where the working relationship gets established. By the time we start building, our team in Thrissur and the client's team already know how to talk to each other, where the real risks are, and what we are collectively aiming for. That shared footing is worth as much as any document we produce.

How BSH can help

If you have an idea that is still fuzzy at the edges, a discovery engagement is the lowest-risk way to find out whether and how to build it. Reach out to BSH Technologies and we will help you turn the idea into a plan worth funding.