The honest answer is that an AI product can cost almost anything.
A focused experiment may take a few days. A dependable commercial platform with multiple integrations, sensitive data and operational commitments may require a six-figure investment. Both can be described as “an AI app”, which is why feature lists and screen counts are poor ways to discuss cost.
The useful question is: what level of evidence and operational confidence does the business need next?
Three different things people call an MVP
1. Validation prototype
A prototype tests whether the core interaction is plausible. It may use controlled data, manual steps and limited security. It should answer a specific question and is not presented as customer-ready.
A sensible budget is often below £10,000 when the workflow is narrow and integrations are mocked or simple. The deliverable is evidence, not a miniature production platform.
2. Narrow production MVP
A production MVP serves real users and completes one valuable workflow. It normally includes authentication, data handling, integrations, testing, deployment, observability and a support plan.
For a focused product, a realistic envelope is often £20,000–£60,000. Complexity, security requirements and integration quality can move that range substantially.
3. Commercial platform
A multi-tenant product with several workflows, administrative features, payments, complex integrations, reporting and formal operational requirements is no longer a small MVP.
These builds commonly begin in the high five figures and move into six figures. The important decision is usually how to sequence the investment so the riskiest commercial assumptions are tested before the full platform is commissioned.
These figures are directional, not AlanOps quotes. Geography, inherited assets, team composition and the required launch standard all matter.
The seven cost drivers that matter most
1. Uncertainty
Ambiguity creates research, rework and contingency. A short readiness engagement can reduce the cost of delivery by resolving the assumptions that would otherwise be discovered during implementation.
2. Workflow depth
A screen that displays information is not equivalent to a workflow that validates it, changes another system, sends notifications and supports reversal. Count business paths and failure modes, not pages.
3. Integrations
Well-documented APIs with test environments are relatively predictable. Legacy systems, unreliable webhooks and undocumented data rules are not. Integration risk often dominates the estimate.
4. Data readiness
AI products depend on the quality, accessibility and permitted use of their data. Cleaning, classifying, migrating and governing data can take more effort than connecting a model.
5. Consequence of error
A drafting assistant and an autonomous operational agent require different levels of control. As the consequence of a wrong action increases, so do the requirements for evaluation, approval, auditability and security.
6. Operational standard
Backups, monitoring, incident response, recovery, support hours and service commitments are part of the product. Excluding them makes the initial build look cheaper by moving cost into the first production incident.
7. Ownership and handover
A documented system that another team can operate requires deliberate work. So does a managed service with ongoing security updates and product iteration. The commercial model should make those responsibilities explicit.
Where AI genuinely reduces cost
AI assistance can accelerate exploration, routine implementation, test creation, documentation and analysis. That allows a senior-led team to cover more ground with less ceremony.
It does not eliminate product discovery, integration work, stakeholder decisions, security review or operational accountability. A quote based on “AI writes most of the code” confuses one activity with the complete delivery system.
How to spend the first money well
Before committing to a full build, spend enough to answer the decisions that could invalidate it:
- Is the user problem real and commercially meaningful?
- Can the required systems and data support the workflow?
- What is the smallest release that creates complete value?
- Which risks require a prototype or technical spike?
- What evidence will justify the next investment?
This is the purpose of the AlanOps Build Readiness Sprint. It turns a broad ambition into a decision-grade plan before an expensive implementation commitment is made.
Ask for options, not one mysterious number
A useful proposal may show several credible paths: a smaller validation release, a focused production build, and a more complete platform delivered in phases. Each option should state its assumptions, exclusions, operating model and definition of done.
The cheapest number is not automatically the lowest-cost decision. The best option is the one that produces the right evidence without leaving the business exposed to hidden work.
Want a credible range for your product?
Send the PRD, prototype or workflow you have today, along with the budget envelope and desired outcome. I will review the material personally and identify what must be resolved before a responsible quote can be produced.