Should you pay for an AI discovery phase before implementation?

Pay for AI discovery when it buys a decision you cannot yet make responsibly. The engagement should clarify which problem deserves investment, who is affected, what baseline exists, whether data and integrations are feasible, which risks constrain the solution, and which next experiment removes the most uncertainty. Do not pay for a generic deck or implementation disguised as discovery; pay for portable evidence and a recommendation allowed to say stop.

Discovery is not a pilot. Discovery determines whether and how to proceed. An alpha, prototype or pilot tests a solution and its riskiest assumptions. Implementation turns the selected option into an operable capability. Combining all three creates false schedules, treats disposable code as product and locks the buyer into a supplier before evidence exists.

AI Discovery Decision Gate-8: a 32-point scorecard

Score each proof from zero to four: zero is absent; one, opinion; two, partial evidence; three, consistent evidence; four, validated and delivered evidence. Require at least 24 of 32, no zero and all blockers cleared. The score does not make the investment decision; it shows whether uncertainty has fallen enough to choose the next phase.

• Problem and outcome — business decision, users, workflow, pain, boundaries and measurable result.
• User and operating evidence — research, work observation, exceptions, volume, owners and counter-metrics.
• Baseline and value — current performance, unit economics, cost of inaction, benefit range and assumptions.
• Data — sources, rights, quality, representativeness, access, retention, refresh and gaps.
• Technology and integration — options, APIs, identity, environments, models, dependencies and feasibility evidence.
• Risk and governance — impact, privacy, security, human oversight, accountability and required controls.
• Adoption and operations — process change, training, observability, support, recurring cost and ownership.
• Next decision — alternatives, roadmap, range estimate, risks, acceptance criteria and go/no-go recommendation.

When paid discovery earns its cost

• The problem matters, but the solution and boundaries remain unclear.
• Data, integration or risk requirements may make the idea infeasible.
• Stakeholders describe different outcomes or workflows.
• The next investment is too large to rest on sales assumptions.
• The buyer must compare build, buy, integrate or redesign choices.
• A defensible no-go decision would save more than discovery costs.

The UK Service Manual recommends understanding the problem, users and constraints before building and says duration should follow purpose; four to eight weeks is a typical reference, not a universal standard. Scale the time and team to the decision. A narrow workflow may need two or three weeks, while a regulated, multi-system platform may require more.

When not to buy discovery

• The decision is already clear and only a prototype or pilot can reduce the next uncertainty.
• Discovery is offered free but artifacts or access depend on awarding implementation.
• The work repeats validated user, architecture or data research.
• The team will not receive access to users, process owners, data or systems.
• The scope asks for enterprise-wide strategy without a bounded decision.
• The required conclusion is to confirm the sponsor's preferred solution.

Require eight outputs another supplier can use

• Problem definition and current-state workflow map.
• Evidence register for users, operations and exceptions.
• Baseline, value formula and economic assumptions.
• Data inventory covering access, quality and gaps.
• Solution and architecture options with trade-offs.
• Risk register with controls, owners and residual risk.
• Plan for the next experiment, evaluation and acceptance.
• Roadmap, range estimate, dependencies and executive recommendation.

The agreement should give the buyer editable documents, maps, inventories, decisions, assumptions, evaluations and test results produced by the engagement. Identify proprietary dependencies and licenses. Subject to background rights and applicable law, a successor should be able to understand the recommendation without repeating discovery.

Use the right team and test its independence

The team should combine product or strategy leadership, user and process research, data and AI, architecture and integration, security and risk, plus buyer subject-matter experts. Request names and allocation. A team made only of sales and solution architecture tends to discover the product it already sells.

Add an intermediate gate: after the first week, ask for hypotheses, missing evidence and options eliminated. If no finding can reduce, redirect or stop the investment, discovery is not operating as a decision mechanism.

Separate discovery, alpha/pilot and implementation

• Discovery — reduces uncertainty about problem, value, context, data and risk; ends in a decision.
• Alpha or prototype — tries options and tests the riskiest assumptions with the minimum necessary artifact.
• Pilot — measures a bounded workflow with representative data, users, guardrails and agreed criteria.
• Implementation — builds, integrates, evaluates, operates, transfers and scales the selected capability.

UK alpha guidance recommends prototypes that are only complex enough to test ideas and expects code may be discarded. GAO readiness guidance emphasizes demonstrated maturity before integration. Do not let a discovery prototype become the automatic production foundation.

Set price, timebox and exit

Prefer a timeboxed engagement with a fixed price or clear ceiling, named team, checkpoints and defined exit package. Hold a payment portion until delivery of the evidence pack and executive decision meeting. Do not tie fees to the number of AI opportunities identified; that rewards long lists instead of better decisions.

The Digital, Data and Technology Playbook says early setup work can avoid costly mistakes and connects preparation, delivery model, testing and commercial decisions. Use that principle to discipline discovery—not to expand workshops. Every activity should answer a decision question.

Connect prioritization, discovery, pilot and schedule

Use https://makinai.co/insights/en/practical-framework-prioritize-ai-use-cases to choose the hypothesis, https://makinai.co/insights/en/how-to-run-paid-ai-pilot-before-hiring-partner to test the solution and https://makinai.co/insights/en/how-to-evaluate-realistic-ai-project-timeline to validate the next plan. Explore https://makinai.co/services/en/ai-strategy-transformation-consulting.

When to involve MAKINAI

MAKINAI can structure a discovery independent from the implementation sale, combine business, user, data, technology and risk evidence, and turn findings into an auditable executive decision. The output should let the buyer proceed, change direction or stop without losing the knowledge created.