There is no useful universal price for an “AI app” without defining the application. A drafting feature in existing software and a new multi-user product contain different work even when they call the same model.
A useful budget separates implementation, operation and uncertainty.
Implementation: price the deliverables
Break the project into product definition, design, frontend, backend, data preparation, integrations, AI behaviour, evaluation, deployment and handover. Identify which items already exist and which must be created.
Then define the work inside each item. “Integration” might mean one documented endpoint or several systems with incomplete test environments. “Document processing” might mean a single template or multiple languages, layouts and quality levels.
A scoped estimate records these assumptions. Without them, comparing two totals tells you little about what is actually included.
Operation: separate fixed and usage-related costs
Model calls are one line, not the whole operating budget. Include hosting, storage, search, document processing, observability, third-party subscriptions, support and human review where applicable.
Usage estimates should follow the workflow. One user action may trigger several processing steps or retries. A monthly budget based only on the cost of one successful model response can miss those conditions.
An illustrative calculation—not an inAi price
Suppose a fictional workflow processes 2,000 cases each month. Assume its combined variable processing cost is €0.12 per case, fixed hosting and tooling total €180 per month, and review takes one minute per case at an assumed internal labour cost of €30 per hour.
Variable processing is 2,000 × €0.12 = €240. Review is 2,000 ÷ 60 × €30 = €1,000. Adding fixed costs gives €1,420 per month, before maintenance, implementation, taxes or any omitted items.
These are deliberately hypothetical inputs, not market rates, measured inAi costs or a commercial quote. The point is the structure: in this example, review effort matters more than processing cost. A real estimate replaces every assumption with project-specific evidence.
Uncertainty: expose it rather than hide it
When data quality or system access is unknown, a discovery or pilot can reduce uncertainty before a larger commitment. The early stage should have its own bounded deliverable and decision criteria.
Do not apply an unexplained contingency to every line and call the result precise. Explain which assumptions could change the estimate and how they will be resolved.
Compare the same scope
Ask each supplier to identify exclusions, third-party charges, ownership, handover, acceptance tests and post-launch responsibilities. Check whether the price assumes customer-provided infrastructure, sample preparation or internal review time.
An implementation proposal and a support agreement should not overlap ambiguously. Specify which defects are covered by the project arrangement, what counts as a change and how future improvements are priced.
Make the budget a decision tool
The best first release is not automatically the cheapest prototype or the largest complete product. It is the smallest scope that can answer the business question while leaving a credible route to operation.