What a discovery phase should actually hand you

Every agency sells a discovery phase. Most of them produce a slide deck. This is what ours produces, and how to tell whether the one you are being offered is worth paying for.

A written problem statement

One page, in plain language, describing what is wrong today, who it affects and what fixed looks like in terms you could measure. If we cannot write this page, we do not understand the project well enough to quote it, and neither does anyone else.

A map of the current process

Not a diagram of the software. A description of what people actually do: which spreadsheet they open first, what they copy where, who they call when the system is wrong. The gap between the official process and the real one is where most of the value hides.

A scope with edges

A list of what the first version does, and a list of what it explicitly does not. The second list matters more. It is what stops a ten-week project from becoming a thirty-week one, and it gives everyone a place to put good ideas that are not for now.

An architecture outline

Two or three pages: the main components, where data lives, what we integrate with, what we buy versus build, and the one or two decisions that would be expensive to reverse. This is written for you to read, not for us. If a technical document only makes sense to engineers, it is not doing its job.

A fixed quote and a date

The output of discovery is a price and a calendar. Not a range, and not a velocity estimate. If the scope has edges and the architecture is settled, the number can be fixed. If it cannot, discovery is not finished.

What it costs

One to two weeks, priced separately, so you can walk away with the documents and take them to anyone, including someone else. Some discovery clients do exactly that, usually because the honest answer was to buy an existing tool. We count those as successes.