AI implementation costs: development, operations and payback

An estimate for “AI implementation” can cover very different results. One proposal might provide an assistant that answers questions. Another might cover a system that receives documents by email, extracts information, checks it and records it in accounting software, with uncertain cases sent to an employee. The development effort and consequences of errors differ considerably.

I start an estimate by defining the process: where the data comes from, what the system must produce, where it must save the result and what happens when processing fails. Then I separate one-time work from the costs of running the system. This gives you a basis for comparing proposals and assessing the investment.

My starting prices and what they cover

For business process automation and AI integration, I offer the following formats. We agree on the cost before development begins, with the work covered by a contract and payments made by stage. All prices below are starting amounts in USD.

Discovery provides preliminary understanding and a plan for the next step. Where useful, I include a high-level diagram or an illustrative prototype. It does not include detailed specifications or a finished prototype. I credit the discovery fee toward the first working version if development starts within one month after discovery is completed.

The first version includes agreed data migration, launch and staff training. Two weeks of joint debugging and fixes after handover are included without a support subscription. I also fix defects in the agreed functionality at no extra charge during a period of up to 30 days.

The 3-⁠6 week estimate applies to an agreed first-process scope. Complex integrations, substantial migration or particular security requirements may call for a different schedule.

When comparing proposals, check whether each includes integration with your systems, testing on real data, error handling, launch and handover. Establish who will investigate failures afterward. A lower development price may simply leave more work to be paid for separately.

What belongs in the implementation estimate

Connecting a language model is only part of building a usable system. Data must reach it, its output needs checking, and the result has to reach the people or software that use it.

Understanding the process and connecting systems

If employees perform the same task differently, I need to establish the rules and exceptions before automating it. Otherwise, the contradiction appears during development: the system follows the agreed description while users expect different behavior.

Development includes receiving emails or documents, calling the model, performing calculations, checking results and saving them. Connections to a CRM, accounting or enterprise resource planning system, email or a website often use an API: a software interface through which systems exchange data. Limited API capabilities, request limits and dependence on manual exports can increase the work required.

Checks, exceptions and failure investigation

A few correctly processed documents do not establish that a system can handle an ongoing workload safely. Important errors need to be detected before they affect accounting records or trigger further actions.

I generally use the language model to read text and extract information. Ordinary code handles calculations, checks defined rules and writes results to business systems. Ambiguous cases go to a human review queue. Irreversible actions may require approval, and action logs make it possible to investigate failures.

The estimate needs to account for these controls, especially where the process involves money or documents. Rare cases can require substantial work even when the main workflow is straightforward.

Launch and adoption

Moving accumulated data, testing on part of the live workload and introducing the system to users all take time. Staff need to know where to find processed records, how to review uncertain cases and what to do when something fails. Without that knowledge, a technically complete system may remain outside everyday work.

Running costs should appear separately: model usage, servers, document recognition, external data sources and tools, maintenance, and employee time spent reviewing exceptions. Connecting a paid service is development work; paying for its subsequent use is an operating expense.

How to estimate model usage costs

Cloud language models commonly charge by tokens, the pieces of text that make up a request and response. A word can contain several tokens, and token counts vary by language. Providers may also charge separately for search, document recognition, tools or other operations, so use the actual billing units of the service being considered.

A preliminary estimate needs four inputs:

• The monthly number of documents, emails or conversations processed.
• The number of model calls per operation.
• The average input size, including instructions, documents and conversation history.
• The average response size.

One document does not necessarily mean one call. A system might classify it, extract fields and then examine an ambiguous passage separately. These calls can differ in size and may use different models, so calculate them separately.

For each call type:

Monthly cost = number of calls × (average input tokens × input rate + average output tokens × output rate).

Keep the units consistent. If the provider quotes a price per million tokens, divide the token quantities by one million before multiplying by that price. Add the costs of all call types, then allow for retries and any applicable reasoning or caching charges.

Include OCR, or optical character recognition, for reading text from scans and images, along with search and external tool charges. Keep the application's own infrastructure on a separate budget line.

This produces a preliminary estimate. Testing on real workloads reveals actual document lengths, retry frequency and how often additional processing is necessary. Poor scans and lengthy correspondence can change the assumptions substantially.

Controlling usage without sacrificing quality

Sending an entire document or conversation with every request can increase costs even when the number of operations stays constant. The system should supply the information needed for the next action rather than automatically resending everything.

Different tasks also require different amounts of reasoning. In a Telegram self-help bot based on a psychologist's method, I implemented automatic reasoning-depth selection alongside controls for conversation state and adherence to the method. I also added caching to reduce token costs.

These mechanisms can help manage cost and response time in other conversational systems, but their effect on answer quality needs testing for the intended workflow. The article on paid AI products in Telegram explores the economics of that type of service in more detail.

How hosting affects cost and data handling

The choice between a managed model service and self-hosting depends on processing quality, workload and the company's requirements for handling data.

Managed model APIs usually charge for usage. Before choosing one, test it on your examples and check service and payment availability, processing terms and whether the specific data may be sent to that provider. A model's reputation does not establish its suitability for your documents.

Enterprise service arrangements require examination of the specific service, usage mode and contract. Check data location, access controls and the full processing chain, including additional components. A provider's location or an enterprise account label does not establish where and how every part of the application handles information.

Self-hosted models replace external per-token charges with computing, hosting and maintenance costs. Hardware requirements depend on the model and workload; not every setup needs a GPU. Self-hosting gives you control over infrastructure, but isolation still needs to be designed. Other application components may have external dependencies or transmit data to outside services.

Neither a cloud contract nor local hosting automatically satisfies a company's data-handling obligations. The company defines those obligations with the appropriate specialists; I implement the agreed technical requirements for access, data location and deployment. For document workflows, the article on AI invoice processing also explains checks needed before extracted data reaches accounting.

Constraints worth testing before the main build

Accurate extraction is useful, but it does not resolve access to source data or the ability to record the result. Those parts of a project can materially change its budget and schedule.

External systems may limit processing speed

In the ad campaign optimizer I developed, integrations were a substantial source of complexity. The system handled hundreds of campaigns across multiple ad networks, whose APIs differed in reliability and request limits. Some returned delayed statistics or intermittent errors. Those conditions affected how frequently campaigns could be checked and how safely the data could be used.

A line item saying “connect the API” should therefore account for the source's actual behavior, including delays, errors and allowed request volume. Some constraints become clear only during integration. Identify those uncertainties in the estimate and test them early.

Data access has a maintenance cost

An external source may offer an API, or information may need to be extracted from website pages, a method known as scraping. An API is not necessarily paid or stable. Scraping is not necessarily inexpensive: its cost depends on the website's structure, access restrictions and frequency of changes.

Compare the actual options, including usage terms, access fees, initial development, maintenance and the consequences of losing access. A year of operation is a more useful comparison than the build cost alone.

Corporate requirements can change the design

When I led the development of a reservoir-planning product at Gazprom Neft, an energy company, the work had to account for corporate security standards, data-handling rules and approved-software requirements. These affected the system's design and the work required.

For an AI project, establish which information may go to external services, where components may run and which software is permitted before selecting the architecture. Discovering these restrictions after development starts can require earlier decisions to be revisited.

Ways to reduce the initial budget

Start with one recurring process whose result can be checked. For example, the first version could handle one document type and record only the information needed for its next step. That limits integrations and exceptions while preserving a useful outcome.

Test the main technical risk early. If the project depends on extracting fields from invoices and completion records, try that on your documents before building the rest. A focused test can be included in discovery where needed, with its scope agreed in advance. It reduces uncertainty but does not replace testing the complete system.

Some rare exceptions are cheaper to route to an employee. Compare the cost of automating a case with its frequency, manual handling time and consequences of error. The system still needs to recognize when to hand it over.

Also check whether custom AI development is needed at all. Native CRM or accounting configuration may be sufficient. Fully defined rules can often be implemented with ordinary code. If employees change the procedure every week, agreeing on the process may be the most useful first step.

Platform-specific configuration and sales pipeline setup belong with a specialist in that platform. I can define the requirements for their part and connect it to the rest of the automation.

Calculating payback without overstating the benefit

A payback estimate needs one-time investment, monthly financial benefit and monthly running costs. During discovery, I work with you to estimate these from available information and identify assumptions that need testing.

One-time investment includes discovery, development, agreed migration, launch and training. If the discovery credit applies because development starts within one month after discovery is completed, do not count that fee a second time.

Monthly financial benefit includes actual reductions in labor and error costs, plus additional contribution profit. Contribution profit means additional revenue minus the costs associated with earning it. If automation helps win more orders, the full value of those orders is not the financial benefit.

Monthly running costs include model usage, servers, external sources and tools, maintenance, and staff time spent reviewing uncertain cases. An internal technical team consumes resources even when there is no separate contractor invoice.

When the monthly difference is positive:

Simple payback in months = one-time investment / (monthly financial benefit - monthly running costs).

If the difference is zero or negative, this method gives no payback period. Revisit the scope, operating costs or business case rather than forcing an attractive number into the estimate.

Freed-up time is not automatically a cash saving

If employees receive the same pay and the available hours are not put to another use, reducing manual effort does not itself lower spending. A financial benefit can arise when the company avoids additional hiring as workload grows, or when employees use those hours for work that produces additional contribution profit.

Keep those effects separate and avoid double counting. If the value of freed-up time is already reflected in additional profit, do not automatically add the cost of those same hours. Likewise, a recovered inquiry should not count both as the full cost of an avoided error and as additional profit. The article on choosing the first process to automate explains this assessment approach further.

Support is optional; operating costs remain

Ongoing work from $3,000 per month is an option for continued maintenance and development, not a mandatory subscription attached to every build. I can hand the running system over to your team. The code is stored in your repository, and you keep the documentation.

If your team maintains it, the budget still needs to include model usage, infrastructure, exception handling and technical work when external systems change. The included post-handover debugging does not remove those longer-term costs.

Test the economics at both current and expected volumes. More documents or conversations can increase model usage, infrastructure needs and manual review work. The estimate should show the conditions under which continued operation makes financial sense, as well as whether the first version is worth building.

For a free initial written exchange, send a short description of one process, its approximate monthly volume and the systems involved. That is enough to discuss a suitable approach and identify what needs clarification before estimating the budget.