Prototype before you sign

A manufacturing company with about 250 employees spent four months writing a requirements document. An external consultant helped. The specification looked thorough. The RFP was clear. An agency bid a fixed price of 340,000 euros. The contract was signed.

Eighteen months later the project ran roughly 60 percent over budget. The ERP integration did not work. The specification assumed an export format the production system had never provided in that form. Agency and client argued about scope. The specification was thorough. It was also written around facts nobody had checked.

The specification trap

Traditional procurement assumes software can be fully specified before construction starts. That works for physical goods with known tolerances. It breaks for software that touches real integrations, undocumented workflows, or unclear process ownership. The failure mode is rarely bad faith. It is the wrong instrument.

Force exploratory work into a fixed-price deliverable contract and you bury uncertainty in the vendor's margin. Vendors underbid to win, then recover through change orders. Project postmortems and studies such as the Standish Group CHAOS reports show a persistent pattern: efforts without a structured discovery phase often overrun substantially, frequently by 50 percent or more. With a real discovery phase, typical variance sits closer to 10 to 20 percent.

53 percent of companies see managing digitalization projects as a major challenge.

Bitkom, Digitalisierung der Wirtschaft

That Bitkom finding is not a fringe result. The planning gap is structural. In the German Mittelstand, a failed large project is rarely something a company can simply write off.

What discovery means here

At Partial Labs, a discovery prototype is not a Figma click-through and not a slide deck. It is a vertical slice: one representative workflow built end to end, with real data sources, real authentication, and real business rules. The output is a narrow but running piece of software and a better-grounded effort estimate.

• UX prototypes validate interface assumptions. Discovery validates technical and organizational reality.
• Typical duration: three to six weeks, time-boxed, with explicit deliverables.
• Common findings: integration limits missing from documentation, process steps nobody wrote down, and data quality that only appears under real use.
• Output: a working slice plus a scoping report with revised effort and named risks.

The commercial structure

Phase one, discovery, is a fixed fee with clear deliverables and acceptance criteria. That phase can be a true fixed-scope contract because the outcome is definable. Phase two, production, starts only once scope and risks are known. Either as a fresh fixed-scope build or as a framework agreement with individual statements of work.

Framework plus SoW is standard in corporate IT. The framework covers IP, liability, confidentiality, and payment terms. Each SoW defines deliverables, timeline, and price. For mid-market buyers this is not exotic. It is the clean answer to exploratory uncertainty without accepting open-ended time-and-materials exposure for the whole project.

Vendor lock-in remains a real concern. In Bitkom surveys, more than half of respondents name provider dependency as a procurement risk. Mitigations in phase one: clear IP transfer, documented architecture, and no proprietary toolchain that makes exit impossible.

Procurement friction in practice

Friction concentrates before the start. Most obstacles to discovery are administrative. They do not vanish, but they are plannable.

• NDA and data access: discovery needs real system access early. Put NDA and data-handling terms into kickoff logistics, not week four.
• IT security sign-off: in many mid-market firms this is one person with a long queue. Budget two to three weeks for first access.
• Budget thresholds: a low five-figure discovery engagement often sits below formal tender thresholds and can be framed as preparation cost.

When discovery is the wrong tool

Not every project needs an exploration phase. Discovery costs time and money and must produce new information.

• Replacing a well-documented legacy system with a known standard product: scope is already clear.
• Hard regulatory or contractual deadlines that leave no room for a three-to-six-week front end.
• Internal tooling with one product owner who knows every integration and data source in verified detail.
• Purely organizational deadlock: if business units cannot agree on what the system should do, no sprint resolves that conflict.

A case from practice

A logistics provider with about 180 employees wanted to automate order-to-invoice matching between WMS and ERP. Discovery ran four weeks at a fixed fee of roughly 18,000 euros, with one engineer and one business analyst. Finding: the WMS exported different formats by customer configuration. The "standard" format in the original requirements document covered only about 40 percent of real cases.

Without discovery, the production contract would have been wrong for most intended use cases from day one. With discovery, production delivered in 14 weeks against an original estimate of 22 weeks. Budget variance stayed under eight percent. The example is anonymized and composite; the orders of magnitude are realistic.

Why this matters more now

AI integrations such as document extraction or workflow automation depend on how real data behaves. You cannot write a reliable specification for an AI feature until you have seen candidate models on actual inputs. This is not a new problem. Any system built on processes that lived only in someone's head has always had the same failure mode. AI simply raises the cost of ignoring that gap.

• Many mid-market firms feel pressure to "do something with AI" without an internal technical definition. A three-week exploration turns that vague brief into a scoped list of inputs, outputs, and failure modes.
• When the brief is vague, a time-boxed exploration before the main contract carries more weight.

The company in the opening scenario did not have a dishonest agency or a careless project manager. It had a structural mismatch between what traditional procurement can reliably produce and what exploratory software work requires. Treat discovery as a priced line item for finding the real scope, not as an after-the-fact insurance policy.