Paid Discovery Software Project: What You Get

What is a paid discovery software project?

A paid discovery software project is a fixed-scope, separately invoiced engagement before any build is quoted. The buyer pays a vendor to map the workflow, test assumptions and produce a fixed-price quote. The buyer owns the documents and can build from them with anyone.

What you get from Viithiisys is:

• Current-state workflow map, built from interviews and observed work, not from the org chart.
• ROI matrix ranking each candidate improvement by effort against payoff.
• Target architecture, with the decisions recorded and the alternatives rejected.
• Risk and assumptions register, with an owner and a test for each entry.
• Fixed-price build quote, scoped from the documents above.
• Handover pack: editable source files, not PDFs only.

Free vs paid discovery: how do the incentives differ?

Free discovery is paid for by the vendor's sales pipeline, so it has to end in a proposal. Paid discovery is paid for by the buyer, so it can end in whatever the evidence supports.

A free session has to be short, because the vendor is not being paid, and it has to end in a number, because the vendor needs a contract. That pressure can push scope low, with the gaps handled later through change requests.

That is not a character flaw in the vendor. It is how the incentives are set up, and good vendors work around it.

But the structure matters, because the cost of untested assumptions is well documented. Flyvbjerg and Budzier's analysis of 1,471 IT projects in Harvard Business Review found that one in six overran its budget by an average of 200% and its schedule by about 70%. The study does not assign a cause to each overrun, so it does not show that discovery would have prevented them. What it does show is how costly a wrong estimate can be. In our experience, many surprises on a project are things nobody checked before the price was set, and discovery is where they get checked.

Why does a paid discovery phase change the incentives?

When the buyer pays for discovery, the deliverable is the product. The vendor is rewarded for finding the awkward integration, the undocumented approval step and the data that does not exist, because those findings are what the buyer paid for.

What does a paid discovery software project deliver, item by item?

Each document answers a question the buyer would otherwise answer by guessing. Nothing is a slide deck of impressions. Every item is something a second vendor could price from.

The structure follows the same logic the UK government applies to its own services. The GOV.UK Service Manual describes discovery as the phase in which a team finds out what users need and what constraints exist before committing to build.

What does a redacted sample discovery look like?

The sample below is an illustrative extract, with client names, systems and real figures removed. The numbers show the level of detail a document records, not the result of a specific engagement.

• Workflow: order-to-dispatch approval, 7 manual handoffs, 3 systems.
• Manual effort observed: order details re-keyed by hand at several handoffs, with the effort recorded step by step in the workflow map.
• Top ROI item: replace re-keying between two systems with a single API call.
• Risk register entries: each risk has a named owner and a test, for example a dispatch approval that depends on a spreadsheet nobody owns.
• Format: a written document set with editable diagrams, so a second team can work from it without a walkthrough.

Which documents form the chain from map to quote?

The four core documents form a chain: the map shows what happens today, the matrix decides what to fix first, the architecture says how, and the quote says what it costs. Each depends on the one before it.

Why does the architecture record rejected options?

A good architecture document records what was not chosen and why. Microsoft's guidance on architecture decision records makes the same point: the reasoning is what lets a later team change course safely.

What does a fixed-price quote cover in a discovery?

The quote is fixed against a written scope. Anything outside that scope is named as excluded, so a change request is a visible conversation instead of a surprise.

Can you take the discovery documents to another vendor?

Yes. The buyer owns every document outright and can hand it to any vendor or internal team. We write them to be read cold, by someone who was never in the interviews and has no loyalty to us.

This matters because a discovery that only works with its author is a lock-in device. Ours is meant to be the opposite.

If another agency quotes lower from the same scope, that is a useful market test of the scope, and the documents have still done their job.

Projects that fail at the handoff often fail because the knowledge lived in one person's head. Handing over editable source files, with assumptions written down, is the cheapest insurance against that. It also means the buyer can bring in a new engineer, a new vendor or an auditor without paying for the same conversations twice.

What if the buyer builds in-house?

Then the architecture and risk register become the engineering team's starting point. Some buyers pair this with CTO-as-a-Service so a senior engineer reviews the plan on a fractional basis while their own team builds. The decision records also give that reviewer something concrete to challenge, which is faster than reviewing a plan that exists only in a slide deck.

Is the discovery fee credited against the build?

If the same team builds the project, the discovery fee is credited in full against the build. It works as a deposit on the work, not a separate charge on top of it.

The mechanic is simple to state. Discovery is scoped and invoiced on its own, before a build quote exists. The build is then quoted as a fixed price from the finished documents, and the discovery fee is deducted from it.

We publish no rate card, because the work is scoped per project after a discovery call. What we can say is the shape: discovery is a bounded, fixed-scope engagement, and the build that follows is fixed-price against a written scope.

What if the buyer walks away?

Then the fee has bought the documents, and nothing more is owed. That is the honest trade-off: a buyer who never intended to build pays for the discovery work up front, instead of having it absorbed into a build price. For smaller bets, a fixed-scope Moonship MVP can follow directly from the discovery.

How long does a paid discovery take?

Paid discovery is a short, fixed-length engagement, not an open-ended consulting retainer. We agree the length in writing at the scoping call, before any fee is invoiced.

It is sized to the number of interviews, systems and workflows in scope. The calendar time depends mostly on how quickly interviewees and access arrive, not on how much writing the vendor does.

Three things stretch it in practice:

• Slow access. Interviews that wait on diaries, or systems that need credentials raised through a ticket queue.
• Disagreement on the problem. If two directors describe the workflow differently, reconciling them is real work and belongs in the findings.
• Undocumented systems. Legacy platforms with no schema or owner take longer to map, which is common on system modernisation work.

We would rather report an extension early than compress the interviews to hit a date. A workflow map built on rushed interviews tends to miss the exceptions, and the exceptions are where estimates go wrong.

What do we need from you?

We need access to the people who do the work, read access to the systems involved, sample data, and one named decision-maker who can approve the scope. Without those four, a discovery produces opinions instead of evidence.

Specifically:

• Two to four people who run the workflow day to day, not only their managers.
• Sample data and documents, with sensitive fields masked if needed.
• System access or screen-share sessions for the tools in scope.
• A decision-maker available to confirm priorities at the end.

These requirements are what keep a discovery grounded in how the work is actually done rather than how it is described in a meeting. You can see the kinds of projects we take on in our case studies.

If you have a process that feels broken but cannot yet say where, the broken workflow assessment is a separate, earlier step from the paid discovery described above. Start there if you want help locating the problem before committing to a scoped, fee-credited discovery.