The number, stated plainly.
Most mid-market AI engagements land between $45K and $180K. That is the band for a $8M-$50M operator commissioning a custom build for a real workflow constraint. It is a fixed fee, not an hourly estimate that drifts, and it is set after a diagnosis call rather than guessed at before anyone has looked at the work.
The band is wide because the work is not uniform. A single-workflow build into a system with a clean API sits near the bottom. A multi-workflow build into a stack with several systems of record, messy historical data, and a human-in-the-loop review layer sits near the top. The number is not arbitrary; it tracks four specific cost drivers, and once you can see those drivers, you can place your own engagement inside the band before you ever get on a call.
The four cost drivers.
Every credible AI engagement fee comes down to the same four variables. They are worth naming because a vendor who cannot tell you which of these moves your number is a vendor who has not scoped the work.
Scope, measured in workflows. One named workflow (intake triage, document classification, lead qualification) is the cheapest possible build. Each additional workflow adds cost, not linearly but close to it, because each one needs its own integration boundary, its own validation, and its own handoff. Operators who try to put "AI across the whole business" into one engagement are quoting themselves into the top of the band and usually past it.
Integration complexity. A workflow that lives in one modern system with a documented API is cheap to integrate. A workflow that spans three systems, one of which is a legacy platform with no clean API, is expensive. The integration is where most of the engineering hours actually go, and it is the single biggest reason two engagements with the same headline scope can differ by $80K.
Data readiness. If the data the AI needs is already structured, labeled, and accessible, the build is faster. If it lives in PDFs, inconsistent spreadsheets, or free-text notes that have to be cleaned and validated before anything runs, that preparation is real work and it shows up in the fee. Data readiness is the cost driver operators most consistently underestimate.
Decision authority. A system that surfaces a recommendation for a human to approve is simpler and cheaper than a system that takes an action autonomously. The moment the build is allowed to make a decision a human currently makes, the testing, the guardrails, and the review layer all expand. That expansion is correct and it is not free.
The three-part structure most engagements follow.
The headline fee is usually composed of three parts, and understanding the structure tells you where your money goes and where you can flex.
Discovery and diagnosis. The front of every engagement is a structured look at the constraint: which workflow, which systems, which success metric, what the integration boundary is. At ColabContent this is a 45-minute diagnosis call that produces a written scope, and it is free. At larger firms it is a paid discovery phase that can run $15K-$40K on its own before a single line of code is written. Either way, the diagnosis is the part that determines whether the rest of the money is well spent. Skipping it is the most expensive thing an operator can do.
The commission, or the build. This is the bulk of the fee. It covers architecture, build, testing on the operator's real data, documentation, and the transfer session where the operator's team takes ownership. This is the $45K-$180K core, and it is where the four cost drivers do their work. The deliverable is a system running in production on the operator's data, not a slide deck or a strategy document.
Optional ongoing support. After handoff, maintenance is an optional agreement, roughly $3,500-$5,000 per month, covering model updates, integration drift, and quarterly output reviews. It is not a required retainer and it is not a lock-in. The code is in the operator's cloud tenant, versioned and owned, from the moment the engagement closes. Most operators run the system internally for the first year before deciding whether ongoing support is worth it.
What cheap-and-wrong looks like.
There is a market below $15K for "AI implementation" aimed at mid-market companies, and operators should understand exactly what they are buying and not buying at that price.
A sub-$15K engagement for a non-standard mid-market workflow almost always skips the two parts that make a system actually run: the discovery work that names the constraint correctly, and the integration work that connects the build to the operator's real data. What gets delivered demos beautifully on sample data in a sales meeting. Then it reaches production and fails, because the data was never validated, the integration boundary was never tested, and ownership was never transferred. The cheap number is real. The working system is not.
The other failure mode at the bottom of the market is the thin wrapper: a generic chatbot or a light automation pointed at a problem that needed a custom build. It works for the average company because it was built for the average company. The mid-market operator with a non-standard workflow is, by definition, not the average company, which is the whole reason a product did not already fit. Paying a little for something that was never going to fit is not a discount; it is a write-off plus the time lost before the rebuild.
The honest version of cheap is a narrower scope, not a cheaper process. If the budget is not there for a full commission, the right move is to commission one workflow properly rather than five workflows badly. A single workflow shipped, owned, and running beats a broad engagement that never reaches production.
A worked example (illustrative).
The following is an illustrative composite, not a specific client, framed to make the band concrete. Suppose a $22M professional-services firm wants to automate intake triage: inbound inquiries arrive across email and a web form, a staffer reads each one, classifies it, and routes it. The constraint is named, the leakage is real (staff hours and slow response time), and the data lives in two systems the firm already owns.
Scoped as one workflow with a clean integration into a modern system of record and a human-in-the-loop approval step, this build sits near the bottom of the band, in the $45K-$70K range. Now change two variables. Add a second workflow (drafting the first-response message) and a third system with no clean API (a legacy platform holding historical matter data that has to be cleaned first). The same firm is now in the $110K-$160K range, because two of the four cost drivers moved at once: scope went from one workflow to two, and integration complexity went from clean to messy.
The point of the example is not the exact figures, which depend entirely on the specific systems and data. The point is that the band is legible. If you can name your workflows, your systems, your data state, and your decision-authority requirement, you can place yourself inside $45K-$180K before anyone quotes you, and you can tell whether a quote you receive is anchored to the work or pulled from the air.
How to read a quote you receive.
A defensible quote ties the number to the four drivers and to the three-part structure. It tells you how many workflows are in scope, what the integration boundary is, what data preparation is assumed, and whether the build has decision authority or stays advisory. It separates discovery, build, and optional support. It states what you own at handoff and where the code lives.
A quote that cannot do those things, that lands on a round number with no scope behind it, or that buries an open-ended monthly fee as the real revenue model, is not a quote you can compare to anything. The mid-market operator's protection is not negotiating the headline number down. It is forcing the number to be explained, because a number that can be explained is a number that was scoped, and a number that was scoped is a number the work can actually be delivered against.