Anyone quoting a price for custom AI software before understanding the workflow, the data, and the systems it has to touch is guessing. The range between the cheapest defensible build and the most expensive one is not a factor of two — it is closer to two orders of magnitude, and the variables that move it are entirely knowable in advance.
That is the useful answer to the cost question: not a number, but the list of factors that determine yours. A narrow single-workflow tool reading one system and producing drafts for human review sits at the low end. A multi-department platform integrating half a dozen legacy applications under regulated audit requirements sits at the high end. Most engagements land somewhere in between, and the distance is explained by six drivers.
What follows is how to work out where your project sits, how to build a budget when you do not yet have a specification, and the cost traps that appear after the invoice for the build has been paid.
Driver 1: Scope Depth, Not Feature Count
Feature lists are a poor proxy for cost because they hide the depth question. A system that classifies incoming documents into five categories and one that classifies them into five categories, extracts twenty fields, validates each against a source system, and routes exceptions by reason code look similar on a slide. They are not similar to build.
The genuine cost driver is the number of distinct decisions the software has to make correctly and the number of exception paths each decision creates. One workflow with clean inputs and a human reviewing every output is the cheapest useful thing you can build. Every additional autonomous decision adds evaluation work, error handling, and monitoring — three costs that scale together.
This is why narrowing scope reduces cost far more than removing features. Cutting a build from three workflows to one does not remove a third of the price. It often removes more, because cross-workflow interactions were the complicated part.
Driver 2: What Condition Is Your Data In?
Data readiness is the single largest source of budget variance, and the least visible during early conversations.
At the favorable end, the information the system needs sits in a modern system of record with an API, consistent schemas, and reasonable accuracy. Retrieval work is straightforward and the estimate holds.
At the difficult end, the source material is scanned documents of varying quality, records duplicated across three systems with no reliable key, or a legacy application whose only export is a nightly file dump. None of that is unbuildable, but each condition adds a preparation project ahead of the AI work — extraction, deduplication, reconciliation — and those projects have their own timelines.
There is a third case worth naming: data that is available and structured but wrong. Fields populated inconsistently, statuses that no longer reflect reality, records nobody has maintained since a migration. Cleanup here is unavoidable, because a grounded AI system inherits every inaccuracy and presents it fluently. The cost is real either way — the only choice is whether it lands in the project budget or in the error rate.
The practical implication is that a data assessment before scoping is cheap insurance. It converts the largest unknown into a known.
Driver 3: Integration Surface
Each system the software must read from or write to carries cost, and the cost is not uniform.
A modern SaaS application with documented REST endpoints, sandbox access, and stable webhooks is a modest addition. An on-premise system with an undocumented database schema, no test environment, and a vendor whose support contract does not cover integration is a different proposition entirely — and the same nominal "one integration" line item.
Write access costs more than read access, because writing requires idempotency, rollback handling, and reconciliation when a partial failure occurs mid-sequence. Two-way sync costs more than one-way, because conflict resolution becomes a design problem rather than an afterthought.
When estimating, count integrations by difficulty rather than quantity, and confirm early whether sandbox environments exist. A vendor with no test environment forces development against production, which slows everything and raises the risk premium. The same connection realities govern conventional workflow automation projects, and they are usually underestimated in both.
Driver 4: Compliance and Assurance Requirements
Two functionally identical systems can differ substantially in cost purely because of the regulatory environment they operate in.
Requirements that move the number include data residency in specific jurisdictions, retention and deletion guarantees, audit logging detailed enough to reconstruct any individual decision, role-based access enforced through to the retrieval layer, model output review procedures, and documentation packages for external auditors.
None of these are exotic, and all of them are cheaper to design in than to retrofit. The expensive version is discovering in month five that every decision the system made needs a reconstructable audit trail and the logging was never built to support it. If your industry is regulated, treat the audit requirement as a first-class specification item alongside accuracy — the same discipline applied to an HR compliance audit applies here.
Driver 5: Model Choice and Inference Economics
Model selection affects both build cost and running cost, and the two pull in different directions.
Using a large frontier model with minimal task-specific engineering gets to acceptable accuracy fastest, so it lowers build cost. It also produces the highest per-transaction cost, which compounds with volume. A smaller model, or a fine-tuned one, typically requires more engineering and evaluation effort up front and then costs substantially less to run.
Which is correct depends almost entirely on volume. At low transaction counts, the frontier model is the rational choice — engineering time is more expensive than inference. Past a certain volume, the arithmetic reverses and the optimization pays for itself. The threshold is worth calculating explicitly during scoping rather than defaulting to whichever model the team already knows.
Retrieval design matters here too. A system that sends large amounts of context with every request costs more per call than one with a well-designed retrieval layer returning only relevant passages. That engineering investment is a permanent reduction in the running bill.
The Line Item Teams Forget: Running Costs
The build is a one-time cost. The system is not.
Ongoing costs include inference or API charges, which scale with usage and are the most visible; hosting and vector storage; monitoring and evaluation, because accuracy drift is invisible without a maintained test set; integration maintenance, since upstream systems change their APIs on their own schedule; and periodic model updates, which can be an opportunity as much as a burden when a cheaper model becomes capable enough for the task.
A reasonable planning assumption is that annual run and maintenance costs are a meaningful fraction of the original build — not a rounding error. Budgeting the build alone and treating year two as a surprise is the most common financial mistake in this category.
Budgeting Before You Have a Specification
You can build a defensible budget without a full spec by working through four questions in order.
What is the process worth today? Estimate the hours currently spent, the error rate and what errors cost, and any revenue delayed by the process. This sets a ceiling on rational investment, and occasionally ends the conversation productively.
What is the narrowest version that would still be worth having? Not the eventual vision — the first useful increment. Scope the budget to that, and treat the rest as a subsequent decision informed by real results.
What are the known unknowns? Data condition and integration difficulty. Fund a short paid discovery phase to resolve them. A discovery engagement that produces a real spec costs a fraction of the build and eliminates most of the variance in the estimate.
What is the running budget? Decide what monthly operating cost the value supports before the design starts, so the model and retrieval design are constrained by it rather than discovered to exceed it.
Cost Traps
Scope negotiated after the estimate. Additions arrive framed as small — one more field, one more system, one more user group. Each carries testing and error handling. Agree in advance that changes go to a change log with their own estimate.
Fixed-price bids on undefined work. A fixed price for a vague scope is either padded heavily or will be recovered through change orders. Fixed price is appropriate after discovery, not before it.
Pilots that cannot become production. A demo built without permissions, logging, or error handling is thrown away when production requirements arrive. Building the prototype on the real architecture costs slightly more and preserves the work.
Optimizing the wrong thing. Teams often spend heavily pushing accuracy from good to excellent when a human review step would have absorbed the difference for far less. Decide what the last few percentage points are actually worth before funding them.
The realistic path to a number is a short discovery engagement that examines your data, your systems, and the specific workflow. Workisy scopes custom AI software development that way for exactly this reason — the estimate is only as good as the understanding behind it. If you are comparing a build against a configurable product, the criteria in our guide to choosing software are a sound place to start.
