How much does an AI project cost for a 20 person business?

It depends on scope, and any number quoted before someone has seen your process is a guess. What moves it: how many systems have to talk to each other and whether they have usable connections, how clean your existing data is, how many exceptions need a human to approve them, how much of the scope is still undecided, and whether the build lives in accounts you own or accounts the vendor rents you. The one price we publish is the $4,500 AI Audit, four weeks, fixed scope, ending in a ranked plan you keep whether we build from it or not. Builds are quoted to the work before you commit.

Why won't you publish a price range for builds?

Because a range honest enough to cover the real spread would be too wide to help you, and a narrow one would be fiction. Two projects that sound identical in a sales call turn out to be different projects once you know that one system has an API and the other does not, or that the records need reconciling first. Publishing a number we would then walk back on the call is worse than saying plainly that it depends and naming exactly what it depends on, which is what this page does.

Is the $4,500 audit worth it for a company our size?

It is worth it when you have several candidate projects, no defensible way to rank them, and a decision that is expensive to get wrong. It is not worth it when you can already name the one job that bleeds money every week: in that case ask for a quote on that single fix and skip the four weeks. The audit interviews the people doing the work, goes through the tools you already pay for, and returns a written plan specific enough that a different company could build from it, so buying it commits you to nothing afterward.

How do I compare two quotes that are far apart?

First check they were quoting the same thing, which usually means they were not. Send both vendors one written page describing the process, the systems, the volume, and the exceptions, and ask each to requote against it. Then compare what each itemizes rather than the totals: what is out of scope, who owns the accounts at handover, what happens to cases the automation cannot handle, and which running costs sit with you. The gap between two quotes is almost always a gap in scope, and the cheaper one is often cheaper because it left out the part that turns out to matter.

Should we just hire someone instead of buying a project?

Sometimes, and it is worth doing the comparison honestly. A hire is a fixed annual cost that keeps producing after the first project, so if you have a year of queued work and a manager who can direct technical work, hiring can beat buying. But at 20 people the usual reality is one or two projects worth doing, no one internally to supervise them, and a hire who would spend most of the year underused. Whichever way you go, do the ranking first: knowing what to build is the part that decides whether either spend pays back.

A straight answer

How do I work out what an AI project should cost for a 20 person business?

Benian Technologies works it out the way you would size a hire: you establish what the job is worth per year first, and only then ask what it costs to fill. At 20 people you can do the first half of that arithmetic yourself, in an afternoon, before any vendor quotes you anything, and doing it first is what turns a quote from a mystery into a decision.

We publish exactly one price: the AI Audit at $4,500, fixed fee and fixed scope, four weeks, half at kickoff and half when the plan is delivered. Every build is quoted to its own scope, and we do not publish a range for builds because any range wide enough to be honest is too wide to be useful, and any range narrow enough to be useful would be a guess dressed up as a fact.

So this page does the more useful thing. It sets out what actually moves the number, what a real quote itemizes line by line, how to read a quote that is suspiciously cheap or suspiciously vague, and when the right answer is to spend nothing at all.

Start with what the job is worth, not with a price list

Pick the one process you would automate first and count what it currently costs you. Hours per week, whose hours, and their loaded cost, meaning salary plus payroll tax and benefits, not the hourly rate you imagine. Then add the money that leaks rather than gets spent: calls nobody picked up, invoices that went out late, orders re-keyed into a second system with a typo in them, quotes that took three days when the customer wanted one. That leakage is easy to miss, and it is the part most owners never total up.

At 20 people this is countable by hand. Ask the two people closest to the process to keep a tally for one week: every time they retype something, chase something, or fix something that should not have broken. A week of tallies from real people beats a month of estimating from a spreadsheet, and it also tells you whether the process is stable enough to automate at all.

Now you have the number that governs everything else. A build worth having should pay back its cost inside a year, and that is a bar you can hold any vendor to out loud in the sales call. If the process is losing you very little, a quote to automate it is not worth taking whatever the number on it is. If the process is bleeding serious money every month, the question stops being what it costs and becomes how quickly it can ship and how confident anyone is that it will hold.

That ranking exercise is the whole substance of an audit. For Nobel Tip Kitabevleri, a medical publisher and retailer, we audited 100% of departments in person (measured) and delivered one prioritized AI roadmap, which the company then executed (measured). The client reports operating costs down 18% since (client-reported). The ranking is what made the spend decidable: not a list of things AI could do, but an ordered list with a value and a build time attached to each line.

What actually moves the number on a build

Five things move it, and everything else is detail. The first is how much of the project is still undecided. Nobody can price what has not been decided, so an undecided scope is priced with a risk margin baked in, and you pay for that margin whether or not the risk shows up. The single cheapest thing you can do to lower a quote is to arrive with the process written down, the exceptions listed, and the decision already made about what happens when the automation is unsure.

The second is integrations: how many separate systems have to talk to each other, and whether they have usable connections. Two systems with real APIs is ordinary work. The same two systems where one is an older package with no API, or a portal a person has to log into, is a different project with a workaround at the center of it, and workarounds cost more to build and more to keep alive. Ask any vendor to name the connection method for each system before they name a price.

The third is the state of your data. If your customer records live in three places with three spellings of the same company name, someone has to reconcile that before anything automates cleanly, and that someone is either your team for free or the vendor for money. The fourth is exception handling and human review: a workflow that runs unattended is cheaper than one where a person approves each result, and the approval step is often the right call, but it is a design decision with a cost, not an afterthought.

The fifth is ownership. A build that lives in your own accounts, with credentials in your name, costs more up front than one assembled inside a vendor's platform, because you are buying the build rather than renting access to it. Our builds work that way as standard, and the honest tradeoff is that the invoice is larger on day one and the running cost afterward is your own usage at cost, with nothing marked up on top. Which is cheaper for you depends on how long the automation lives and how hard it runs.

What a real quote itemizes

A quote you can actually evaluate names the exact processes in scope and, just as importantly, what is explicitly out of scope. It lists each system it will touch and whether new access has to be created. It says what happens to exceptions, meaning the cases the automation cannot handle, because that is where every disappointing project goes wrong. It names the deliverable in terms a non-technical person can check on the day, and it names who owns the accounts and credentials at handover.

It also separates two kinds of money that get blurred together constantly: what you pay the vendor, and what you pay your own suppliers afterward. Model usage, phone minutes, and any platform subscriptions are running costs you carry directly in accounts you hold. A quote that folds all of that into one monthly figure is hiding which part is the vendor's margin and which part is the meter. Ask for it split.

Ours states the payment schedule plainly: milestone based and always split in half, 50% at kickoff and 50% at launch for a build, and the same split for consulting except the second half falls when the plan is delivered, because nothing launches in that engagement. Typical builds ship in 14 to 21 business days, and smaller single-workflow projects in 7 to 10. Every project includes one week of post-launch support, and ongoing support after that is an optional retainer priced to how much you want covered.

If what arrives is one line and one number, it is not a quote. It is a hope with a total at the bottom, and the gap between the hope and the work will be settled later as change orders, at a moment when you have already paid a deposit and lost your leverage.

How to judge any provider on price, including us

Get two or three quotes, but make sure every vendor saw the same written scope. Different vendors quoting from different conversations produces three prices for three different projects, and comparing them tells you nothing except who was most optimistic. Write one page describing the process, the systems, the volume, and the exceptions, and send that same page to everyone. This is the highest leverage hour you will spend on the whole purchase.

Then ask each of them two questions: what would make this price go up, and what would make it go down. A vendor who has actually priced the work answers immediately and specifically, because they know which assumptions are load bearing. A vendor who cannot answer has priced the logo, the industry, or their read of your budget rather than the job.

A suspiciously cheap quote has three possible readings and you should find out which. Either they misunderstood the scope, which is the common one, and the difference arrives later as change orders. Or the low number is a setup fee attached to a permanent monthly subscription, where the real price is the next three years and the workflow stops the month you do. Or they have genuinely built this exact thing before and it really is cheap, which is the good case, so ask to see the one they built and ask what happens when an unusual case shows up.

A vague quote is the other failure. If the proposal sells transformation, strategy, or enablement without naming a thing that will be different in 30 days, ask what specifically changes, who does it, and what you still own if you stop paying. And if you handle patient or client data, no quote and no vendor makes you compliant, ours included: ask what data leaves your systems, where it is stored, who can read it, whether they will sign a BAA if you are in healthcare, and what their breach notification window is in writing. A vendor who deflects that question has answered it.

When not to buy, and when the cheaper answer is fixing the process

Automating a broken process makes it break faster and at higher volume. If the reason your team retypes data is that a form asks for the wrong fields, fix the form. If the reason quotes take three days is that one person has to approve them and that person travels, change the approval rule. At 20 people a surprising share of what looks like an AI problem is a settings problem in software you already pay for, and those fixes cost nothing but an afternoon of somebody's attention.

If the volume is small, do not buy anything. A task that takes one person twenty minutes a week is cheaper left alone than automated by anyone, us included, and the maintenance attention a build quietly demands is a real cost that never appears on a quote. Automate what hurts by lunchtime, not what merely annoys you on a Friday.

If your process changes every month, wait. A build encodes a process, so it is only worth what the stability of that process is worth, and a business still figuring out how it works should keep figuring rather than pour concrete around this quarter's version. Wait until the same steps have run the same way for a few months, then automate them.

And if cash is genuinely tight, do not buy the audit either. Do the tally week yourself, take the free thirty minute call, or use our free intake, where an engineer writes back within two business days with a ranked map of the three places AI or automation would pay back fastest for you, and if the honest answer is that nothing pays yet, the map says that. The $4,500 audit is worth buying when you have several candidate projects, no way to rank them, and a decision that is expensive to get wrong. If you already know your one bottleneck, skip the diagnosis and ask for a quote on that single fix.

Common questions

How much does an AI project cost for a 20 person business?: It depends on scope, and any number quoted before someone has seen your process is a guess. What moves it: how many systems have to talk to each other and whether they have usable connections, how clean your existing data is, how many exceptions need a human to approve them, how much of the scope is still undecided, and whether the build lives in accounts you own or accounts the vendor rents you. The one price we publish is the $4,500 AI Audit, four weeks, fixed scope, ending in a ranked plan you keep whether we build from it or not. Builds are quoted to the work before you commit.
Why won't you publish a price range for builds?: Because a range honest enough to cover the real spread would be too wide to help you, and a narrow one would be fiction. Two projects that sound identical in a sales call turn out to be different projects once you know that one system has an API and the other does not, or that the records need reconciling first. Publishing a number we would then walk back on the call is worse than saying plainly that it depends and naming exactly what it depends on, which is what this page does.
Is the $4,500 audit worth it for a company our size?: It is worth it when you have several candidate projects, no defensible way to rank them, and a decision that is expensive to get wrong. It is not worth it when you can already name the one job that bleeds money every week: in that case ask for a quote on that single fix and skip the four weeks. The audit interviews the people doing the work, goes through the tools you already pay for, and returns a written plan specific enough that a different company could build from it, so buying it commits you to nothing afterward.
How do I compare two quotes that are far apart?: First check they were quoting the same thing, which usually means they were not. Send both vendors one written page describing the process, the systems, the volume, and the exceptions, and ask each to requote against it. Then compare what each itemizes rather than the totals: what is out of scope, who owns the accounts at handover, what happens to cases the automation cannot handle, and which running costs sit with you. The gap between two quotes is almost always a gap in scope, and the cheaper one is often cheaper because it left out the part that turns out to matter.
What will I still be paying after the build is finished?: Your own usage, in accounts you hold: model usage, phone minutes if there is a phone line, and any platform subscriptions the build depends on. Those are billed to you directly at cost, with nothing marked up between you and your suppliers. Every project includes one week of post-launch support, and continuing support after that is an optional monthly retainer priced to how much you want covered. Ask any vendor to split the vendor fee from the metered costs in writing, because a single blended monthly figure hides which is which.
Should we just hire someone instead of buying a project?: Sometimes, and it is worth doing the comparison honestly. A hire is a fixed annual cost that keeps producing after the first project, so if you have a year of queued work and a manager who can direct technical work, hiring can beat buying. But at 20 people the usual reality is one or two projects worth doing, no one internally to supervise them, and a hire who would spend most of the year underused. Whichever way you go, do the ranking first: knowing what to build is the part that decides whether either spend pays back.

Want this answered for your business?

Thirty minutes with the engineer who builds these systems. You leave with a first fix and an honest read on whether AI is even the answer.

Book a call

Not ready for a call? Start with the free Opportunity Map.