The most expensive bugs are the ones written into the requirements document before development starts. Our discovery process is designed to surface those before they become code — and every client who's skipped it has paid the price.
The most expensive conversation in software development is the one you don't have before you start building. We learned this the hard way.
In 2021, we took on a logistics management project for a mid-sized freight company in Chittagong. The brief was clear — or so we thought. "We need a system to track shipments and manage driver assignments." We scoped it in a week, started development, and eight months later delivered something that technically did what the brief said.
The client was disappointed. What they actually needed, we discovered after go-live, was a system that interfaced with their customs broker's software, handled multi-currency invoicing for cross-border shipments, and generated the specific C&F agent reports required by their largest clients. None of that was in the brief because nobody asked the right questions.
We rebuilt 40% of the system. It cost us more than the profit on the original project. That's when we formalised our discovery process.
Discovery is not requirements gathering. Requirements gathering is passive — you ask the client what they want, they tell you, you write it down. It produces a list of features, not an understanding of the problem.
Discovery is active investigation. It's asking why, not just what. It's mapping the actual process before designing the software process. It's finding the constraints nobody mentioned because they assumed you already knew.
Day 1–2: Stakeholder interviews. We talk to the sponsor (who's paying), the operational owner (who's accountable for results), and the end users (who will actually use the thing). These are separate conversations — what the CEO thinks the process is and what the accounts payable clerk knows the process is are often different.
Day 3–5: Process observation and mapping. We watch how work actually happens. We map the current state — every step, every handoff, every tool. We note where things break, where people create workarounds, where data gets created that nobody uses and where data gets used that doesn't exist yet.
Day 6–8: Integration and data mapping. What other systems does this need to talk to? What data goes in, what data must come out? What are the reporting requirements (the ones the CFO needs, not the ones they think they need)?
Day 9–10: Constraints and non-functionals. Performance requirements, security requirements, budget constraints, timeline constraints. These often don't get discussed until they become a problem.
Day 11–14: Synthesis and proposal. We produce a discovery document: current state map, problem statement, proposed scope, key risks, a realistic timeline and budget range. This document is the contract for the rest of the project.
After doing enough discoveries, we've identified the questions that most reliably reveal hidden complexity:
The last question — the edge case question — is particularly revealing. Edge cases aren't always rare. In every manufacturing client we've worked with, returns processing is considered an edge case. In reality, return rates average 3–8% and the process for handling them is often more complex than the forward flow.
Every client we've worked with has more existing systems than they think, and more integration requirements than they mention. An ERP project for a pharmaceutical distributor turned out to require integration with the government's Drug Administration tracking system — something not mentioned in any documentation but absolutely required for compliance. Discovery found it in week one.
What people say they need in reporting and what they actually need are different. We've been told "basic sales reports" and discovered that "basic" means a 47-column export that feeds a decades-old Excel model that the CFO uses for board presentations and will not change.
Regulatory constraints, auditor requirements, bank covenants, customer-imposed formats — these exist outside the client organisation but constrain what the software must do. They almost never appear in initial briefs.
Some clients see discovery as delay. They want to start building. We've learned to be direct about why this is wrong: starting to build without discovery doesn't save time. It creates a debt — of misaligned assumptions, missing features, and wrong data models — that gets repaid at the worst possible time, which is during development when changes are expensive.
We've also learned to make discovery a deliverable with tangible output. The discovery document — process maps, data model sketches, integration diagrams, risk register — is something the client can read, critique, and approve. It's not consulting theatre. It's the specification the development team actually builds from.
Work With Us
From ERP to HealthTech to custom SaaS — we partner with businesses that want software built properly.