The cost of an AI development project depends on the workflow around the model. A demonstration that answers a question is different from an application that authenticates users, respects permissions, connects to business tools, handles exceptions, and can be maintained after launch.
Before requesting a price, define the first outcome and the systems it depends on. This produces a more useful estimate than asking for a generic AI chatbot, agent, or automation package.
Separate discovery, implementation, and operation
Discovery establishes the workflow, available data, integration constraints, and acceptance criteria. Implementation creates the application and its controls. Operation includes provider usage, hosting, source updates, monitoring, and the work needed when dependencies change.
These costs have different owners and timing. A small first release can still need substantial discovery if its information sources are unclear. A simple interface can conceal a difficult integration. A model usage bill can be modest while review and maintenance require meaningful staff time.
Five drivers to make explicit
Scroll sideways to view the full table.
| Driver | What changes the scope | Evidence to bring |
|---|---|---|
| Workflow complexity | Exceptions, approval steps, and multiple actors | A process walkthrough and real examples |
| Source readiness | Conflicting, inaccessible, or poorly structured information | A source inventory and named owners |
| Integrations | Authentication, incomplete APIs, and unreliable callbacks | API documentation and test access |
| Evaluation | Different user roles, failure paths, and quality requirements | Representative tasks and expected outcomes |
| Operations | Usage, retention, support, and change frequency | Expected workload and maintenance responsibilities |
This is a scoping framework, not a published rate card. Each driver can increase or reduce the work depending on what already exists.
Compare two fictional knowledge assistants
The first organization has one approved handbook, one employee role, and a small set of recurring questions. Its pilot might need ingestion, retrieval, source-linked answers, and a missing-evidence response.
The second organization has multiple departments, conflicting policy versions, restricted documents, and several systems that must stay synchronized. It also needs source ownership, permissions, update handling, and separate evaluation cases for different users.
Both could be described as an internal AI assistant. Quoting them as equivalent projects would hide the work that makes the second one reliable. These examples are illustrative; they do not represent measured client costs.
Estimate usage with an explicit worksheet
Start with tasks per month. For each task, estimate model calls, input and output size, retrieval activity, integration calls, and expected retries. Then add infrastructure and human review work.
A useful planning relationship is:
Monthly operating estimate = model usage + retrieval/storage + hosting/integrations + review/support work.
Use current provider prices and measured prototype usage when filling in the worksheet. Record assumptions separately from measurements. Avoid treating a successful sample request as the average for every production task.
For a voice workflow, include session duration and handoff behavior. For a knowledge system, include re-ingestion and permission changes. For an agent, include tool failures and bounded retry attempts.
Scope a pilot around uncertainty
A pilot should resolve the uncertainty that prevents a sensible implementation decision. It might test whether the necessary information can be retrieved, whether an API supports the required write, or whether the review process fits the user's working day.
The Artebello readiness approach connects those questions to a roadmap. Narravo illustrates why source provenance and reviewed knowledge belong in the product scope, rather than being deferred indefinitely.
Ask for an estimate with named assumptions
A useful proposal distinguishes confirmed scope, assumptions, exclusions, dependencies, and change control. Ask what could change the estimate and which discovery step would narrow that uncertainty. Compare deliverables and acceptance criteria before comparing headline totals.
For AI product engineering, a short brief about the workflow and current systems is enough to begin that conversation. Public fixed prices are not listed here because the implementation boundary needs to be established first.
Prepared with AI assistance using Paul’s documented project work and the linked sources. Examples are illustrative unless identified as project records.