Each format should answer a different question. Choosing the right stage helps avoid paying for a demonstration when the business actually expects an operable service.
These labels are sometimes used as sales terms when they should describe an objective, a level of real-world use and an end-of-stage decision. Ask what will actually be usable, connected, secured and maintained.
For every proposal, complete this sentence: “At the end of this engagement, we will have … and we will be able to decide …”.
Duration and budget cannot be generalized without scope, data, integrations and the expected production level. Compare responsibilities first.
| Criterion | Objective | Deliverable | Risk level | Data | Users | IT integration | Duration | Decision enabled |
|---|---|---|---|---|---|---|---|---|
| Audit | Understand the current situation, opportunities and constraints. | Diagnosis, risks, priorities and recommendations. | Low implementation commitment. | Inventory, samples and interviews as needed. | Decision-makers, business teams, data, IT and security as relevant. | Dependencies are analyzed; integration is not required. | One-off phase sized to the depth of analysis. | Decide what to investigate next, in which order and under what conditions. |
| Discovery | Turn a priority into a scope that providers can quote. | Scope, assumptions, target architecture, criteria and governance. | Limited commitment, although structural choices may already be made. | Representative samples and access rules need to be clarified. | Sponsor, end users, product or business owner and IT. | Interfaces and constraints are described before implementation. | Until scope and the next test decision are sufficiently clear. | Launch a test, approach providers, revise the need or stop. |
| POC | Test a technical or feasibility hypothesis. | Test result, limitations, measurements and recommendation. | Controlled when the hypothesis and end condition are explicit. | Representative sample, sometimes prepared specifically for the test. | Project team and experts, plus selected users when needed. | Often limited or simulated. | Short evidence phase bounded by one precise question. | Confirm, reject or reformulate the hypothesis. |
| Prototype | Make the idea tangible and test the user journey. | Demonstrable interface or workflow not intended for operations. | Risk of being mistaken for a finished product. | Example or limited data, clearly identified as such. | Pilot users providing qualitative feedback. | Partial, simulated or absent. | Limited to the fidelity needed to learn. | Revise the use case, refine requirements or prepare an MVP. |
| MVP | Provide the smallest usable service in a defined context. | Limited product tested with real users and monitored. | Higher because usage becomes real. | Real data with quality, access and protection rules. | Identified user group with support and organized feedback. | Essential integrations are operational. | Depends on the smallest genuinely usable scope. | Improve, expand, maintain the scope or stop. |
| Pilot | Test the service in a limited part of the organization. | Service deployed to a controlled population or scope. | Close to production risk inside the pilot boundary. | Real data, real volumes and observable incidents. | Supported pilot population, sponsor and support team. | Real within the pilot scope. | Long enough to observe usage and exceptions. | Scale, correct, extend the pilot or stop. |
| Production | Make the service reliable, secure and usable every day. | Deployed, monitored, documented and supported service. | High because users and processes depend on it. | Real, governed, logged and protected data. | Target population, support, operations and business owners. | Complete according to architecture and IT rules. | Delivery cycle followed by ongoing operations. | Accept the service and organize future changes. |
| Industrialization | Keep the service reliable over time and at greater scale. | Stronger monitoring, procedures, capacity, maintenance and continuous improvement. | Operational, financial and dependency risks must be controlled. | Real flows, drift, quality and cost monitored over time. | Full user population, operations and governance. | Hardened, automated and documented. | Continuous activity driven by change and incidents. | Maintain, optimize, expand, replace or retire. |
An audit describes the current situation and options. Discovery turns one option into a provider-ready scope covering users, data, integrations, risks, success criteria and responsibilities.
At the end, you should know which decision to make and which unknowns still need testing.
A POC answers a precise feasibility question. It should not accumulate features. Data and the test protocol must be representative enough to support a useful conclusion.
At the end, the hypothesis is confirmed, rejected or reformulated.
A prototype helps learn about the journey, interface or sequence of tasks. It may use shortcuts that would be unacceptable in production.
At the end, user feedback should help revise the use case or prepare a genuinely usable scope.
An MVP provides a limited but usable service. It involves real users, real data, support responsibility and quality criteria appropriate to the scope.
At the end, you should know whether the service deserves improvement, expansion or retirement.
A pilot tests the service inside part of the organization and should expose real operating conditions: load, exceptions, adoption, support, errors and process impact.
At the end, you should have evidence to decide whether to scale or rework the service.
Production requires security, monitoring, access management, incident procedures, documentation, service criteria and an operating owner.
At the end, business and technical owners should have accepted the service with a defined operating model.
Industrialization addresses capacity, reliability, costs, updates, drift and continuity. Maintenance must cover changes in data, tools, models and usage.
At each cycle, the organization decides whether to maintain, improve, expand, replace or retire the service.
The test produces a demo but no criterion defines what happens with the result.
Shortcuts in data, security or integration remain hidden.
The service is delivered without a named population, support or feedback loop.
Errors, costs, drift and incidents are not detected or assigned.
Changes in data, tools and processes only surface after delivery.
Scope, population or observation period remain open, preventing a decision.
To align scope and cost lines, pair this guide with the AI project budget guide and the AI agency pricing guide.
Answers should make the shortcuts of the current stage explicit and show which work remains before real-world use.
A consultant is often useful before implementation, an agency to build and test, and an integrator when production depends heavily on existing IT. Compare actual responsibilities rather than titles.
For designing and delivering a use case with a project team.
For auditing, prioritizing, scoping and supporting a decision.
For connecting, securing and operating a solution in the existing IT environment.
Describe the decision you need to make, available data, systems involved and expected level of production readiness. A shortlist can help compare providers against the same stage and responsibilities.