The conversation almost always starts the same way: "How much would a system like this cost?" And almost always the question comes with a half-page description: we need a client portal, an integration with the accounting system, an app for iOS and Android.
You can name a number in reply. It will not be true.
Why quoting from a description is a lottery
The same phrase — "integration with the accounting system" — means different amounts of work in two projects. In one case it is a daily export of stock levels in a ready-made format. In the other it is a two-way exchange of orders, reservations and statuses, on top of a configuration the client has been customising for seven years, with no documentation of those changes.
The difference between the two is not percentage points, it is multiples. A contractor who quotes immediately prices that uncertainty in: either the number is padded until it scares you, or it sounds pleasant and turns into a change request later.
There is a third way, an honest one: understand first, then count.
What happens during discovery
Discovery is not a meeting or a two-page brief. It is a stage of work with its own deliverable.
We map the process as it is. Not as the regulations describe it, but as it actually runs: who enters the data, where it is duplicated by hand, what people do when the system "won't let them".
We look at the systems you will live with. Which version, which customisations, whether there is API access, who maintains them. This is often where it turns out the task is not a new system at all, but two existing ones that do not talk to each other.
We find the constraints. A network with no internet access, personal data requirements, deadlines tied to a reporting period, staff who cannot be retrained in a month.
We write requirements that can be checked. "A convenient interface" cannot be verified. "A sales manager creates an order in three steps without leaving the customer card" can.
What the client keeps
A process map, requirements, and an estimate of timeline and cost broken down by stage. All of it is a document that belongs to the client.
From there you can work with us. You can also take that document to another contractor and get comparable offers — because now it is clear what exactly is being priced. It happens, and it is fine: discovery costs a fraction of six months spent building the wrong thing.
When discovery is not needed
Not every project needs it. If the task is small and clear — extend an existing section, build a landing page with a form, add one screen to an app — we simply estimate the work and do it.
Discovery earns its place where the cost of a mistake is high: a system a whole department will work in, an integration that sales depend on, a replacement for something that already runs.
Put simply: the more the task is tied to how the company works, the more expensive misunderstanding becomes — and the faster discovery pays for itself.