Nobody needs AI
They need a decision made faster, a document read that nobody has time to read, a queue triaged before it ages, or a number produced without three people reconciling spreadsheets. AI is one way to do some of those things and a bad way to do others. The question that can actually be answered is narrower and more useful: is there a specific, repeated, measurable task in this company where a machine doing it badly is still better than the situation today? Sometimes yes. Often no. The difference is arithmetic, and most organizations never do it.
We are asked the title question several times a month, usually by someone who already suspects the answer is yes and wants confirmation, or by someone who suspects the answer is no and wants permission. Both are asking about the company. The answer only exists at the level of a task.
So the shape of a useful conversation is: name a task, count how often it happens, price what it costs now, and state what a wrong answer would cost. Four facts. If a company cannot produce them, that is not a reason to hire an engineering firm. It is the first thing to go fix, and it is free.
You are probably here because
- The board asked what the company is doing about AI, and the honest answer is nothing in particular
- A competitor announced something and nobody can tell whether it is real
- Two vendors have quoted the same problem and the quotes differ by a factor of five
- Somebody built something impressive in a weekend and now it is supposed to become a system
Those are four different problems. Only the third and fourth are engineering questions. The first two are answered by picking a task and running the numbers below.
The four reasons the question shows up
Board or investor pressure. Someone senior has been asked what the company is doing and does not have an answer. This produces the worst projects, because the goal is a slide rather than an outcome, and the success criterion is that the slide exists. If this is the real driver, say so internally. A small, honest, genuinely useful project makes a better slide than a large speculative one, and it costs less.
A competitor announcement. Worth two hours of research and rarely more. Most announcements describe an intention. Some describe a feature that exists and is barely used. A few describe something that actually changed the economics of their business, and those are recognizable because a number moved: headcount in a function, price, cycle time, gross margin. Look for the number before reacting to the press release.
A real operational bottleneck. Somebody in the company is doing something repetitive, slowly, at volume, and everyone knows it. This is the best reason and it produces the projects that work. It is also the reason least likely to be phrased as "we need AI"; it is usually phrased as "we can't hire fast enough for claims intake."
A pile of unstructured material nobody can read. Contracts, inspection reports, service tickets, email, scanned PDFs from three acquisitions ago. This is the single most reliable place where current technology earns its cost, because the alternative is a person reading it and there is more of it than people.
Three conditions, and the task needs all three
A task is a candidate when it repeats often enough for the fixed cost to amortize, when a wrong answer is survivable or catchable, and when somebody already measures the outcome. Miss one and the project usually stalls after the demo.
Repetition. Something done ten times a year cannot pay back an engineering project no matter how painful each instance is. Something done two hundred times a day can pay back a large one. The threshold is not a universal number, but if a task consumes less than roughly twenty hours of somebody's month, be skeptical.
Tolerable, catchable error. Current systems are wrong sometimes, and they are most dangerous when they are wrong fluently. A task where a mistake is caught downstream by an existing control is a good candidate. A task where a mistake is invisible until a regulator or a customer finds it is a bad one, unless you are willing to fund the review process that catches it, which is a real and recurring cost.
An existing measurement. If nobody knows the current error rate, cycle time or cost per unit, there is no way to prove the new thing is better, which means there is no way to justify keeping it. This is the condition companies most often fail, and it is the cheapest one to fix.
What decides whether a first project pays for itself
Our ranking of what determines the outcome, not a measured statistic. The last row is where most of the discussion goes.
The arithmetic, done honestly
Take the task. Multiply the volume by the time per instance to get hours per month. Multiply by a fully loaded labor rate, which for most roles is salary plus twenty-five to forty percent, divided by about 1,800 working hours a year. That is the annual cost of doing it the way you do it now.
Then apply two discounts most business cases skip. First, a system will not take the whole task; it will take the routine portion, and the routine portion is usually sixty to eighty percent by volume but a smaller share by time, because the hard cases are the slow ones. Second, saved hours are not saved money unless somebody either leaves, stops being hired, or does something else that has value. Time returned to a salaried person who then does more of the same job is real, but it is not a line in the budget, and finance will notice.
On the other side, a first production feature built properly is rarely under about $60,000 of engineering and rarely over about $400,000 unless it is really several features wearing one name. Then add running cost: infrastructure, model usage, monitoring and someone's attention. A reasonable planning figure for the first year of operation is fifteen to twenty-five percent of the build cost, and it does not go to zero in year two.
Put the two together and the pattern is stark. A task consuming forty hours a month at a fully loaded $45 an hour costs about $21,600 a year. A $150,000 build against that never pays back on that task alone, no matter how well it is executed. The same build against a task consuming four hundred hours a month is obviously worth doing. Most proposed projects sit closer to the first than anyone wants to admit, which is why the volume question comes first.
Where it usually does pay
The pattern across the work that survives contact with production is consistent: high volume, unstructured or semi-structured input, an existing human process that is a bottleneck rather than a craft, and an error that somebody downstream already catches.
| Task shape | Why it works | What has to be true |
|---|---|---|
| Reading documents into fields invoices, contracts, reports, forms | The alternative is a person reading, and there is more paper than people | A way to check a sample, and a defined behavior when a field is absent |
| Triage and routing tickets, claims, leads, inbound mail | Wrong routing is visible fast and cheap to correct | Enough history to learn from, and a fallback queue |
| Search over your own material policies, specifications, past work | People currently ask a colleague or give up | Permissions that are respected, and answers that cite the source |
| First-draft generation summaries, responses, descriptions | Editing is faster than writing, and a human stays in the loop | Someone who will actually edit it, not forward it |
| Forecasting on structured data demand, staffing, maintenance | Ordinary statistics, decades proven, often no language model needed | Clean history and a decision that changes with the forecast |
Note what is missing from that table. Nothing on it requires a new product category, a data platform migration, or a strategy. Each is a specific task with a countable volume.
Where it usually does not
Low-volume, high-stakes judgment. Anything whose output is a legally binding number and where being right ninety-eight percent of the time is worse than useless. Tasks where the real difficulty is that three departments disagree about a definition, because a model will simply automate the disagreement. Anything whose success depends on data the company cannot legally or practically obtain, which is the most common quiet killer.
And arithmetic. Language models are poor at reliable computation and always will be relative to a spreadsheet formula. If the deliverable is a total that has to reconcile, the model should locate and label the inputs, and ordinary code should do the sum.
Three cheaper things that beat an AI project
A report that already exists somewhere. A striking share of requests for a predictive system turn out to be requests for a number nobody currently produces on a schedule. Producing it weekly costs almost nothing and often ends the conversation.
A form instead of an inbox. Much document-reading work exists because the information arrived as free text when it could have arrived as fields. Where you control the sender, changing the intake is a hundred times cheaper than reading the output, and it is permanent.
A rule. If eighty percent of cases are handled by four conditions everyone already knows, write the four conditions. Rules are auditable, cheap, and easy to change. Then, if the remaining twenty percent still hurts, that is a well-defined problem worth a model, and now you have a baseline to beat.
The most expensive week of an AI project usually happens before any code is written
It is the week spent finding out that the data lives in a system whose vendor charges for API access, or that the export nobody has run since 2021 does not include the field the whole design depends on. Ask for a real sample of the actual data in the first conversation. Not a schema, not a description — a file. Whether that file can be produced within a week is the single most predictive early signal of whether the project will ship.
Describe the task and we will tell you whether the numbers work.
Send the task, roughly how often it happens, and who does it today to contact@precisionfederal.com. You get back a short written note saying whether we think it pays back, what we would need to see to be sure, and what the cheaper alternative would be if there is one. One business day. No charge, no meeting, no deck.
contact@precisionfederal.com"Not yet" is a real answer, and it is common
Three conditions put a company in "not yet" rather than "no." None is a permanent state and all are fixable in weeks, not quarters.
Nobody can get to the data. Not because it does not exist, but because the owner is in another division, the extract requires a change request, or the contract with the system vendor is silent on exports. This is an organizational problem wearing a technical costume, and it is best solved before an engineering firm is billing hourly.
Nobody owns the outcome. A project sponsored by a technology function with no operational owner produces a system that is demonstrated and never adopted. The owner is the person whose numbers change if it works. If that person is not asking for it, the project has a problem no amount of engineering fixes.
Nothing is measured. Spend a month counting: how many, how long, how often wrong, caught by whom. That month is not a delay. It is the baseline that later determines whether anything was gained, and it frequently changes which task gets picked.
What a straight answer from a vendor sounds like
The useful signal in a first conversation is whether the firm across the table tries to narrow the problem or widen it. Narrowing sounds like questions about volume, current cost, who does it now, what happens when it is wrong, and whether a file can be produced. Widening sounds like a platform, a roadmap, a maturity model, and a discovery phase priced as a percentage of a build nobody has scoped.
A firm that says "this task is too small to pay back, here is the one next to it that is not" is doing the job. So is one that says the answer is a report, not a model. Neither is a sales tactic; it is what the arithmetic says most of the time, and a firm that never says it is not doing the arithmetic.
The mistakes we are called in to fix
- A platform bought before a task was named, now looking for a use case to justify the renewal
- A pilot that succeeded on twenty hand-chosen examples and was never run on the messy back catalogue
- A system with no owner, demonstrated to the executive team twice and used by nobody
- Savings claimed in hours that never appeared in any budget, followed by a hard renewal conversation
- A model doing arithmetic that a spreadsheet formula would do exactly right, every time, for free
- A build started before the data export was tested, discovering in week five that the key field is not in the extract
- A vendor scored on demo quality rather than on performance against the buyer's own worst examples
Four weeks to a decision you can defend
Decision Sprint
Step three is the one that carries the most information and the one most often skipped. A company where a real sample of production data arrives in two days is a company where the project will move. A company where it takes six weeks and a legal review has just learned something more valuable than any vendor evaluation would have told it.
Before you fund anything
- The task is named in one sentence a new employee would understand
- Volume is counted, not estimated from memory
- The current cost is written down with a labor rate attached
- Someone whose numbers change owns the outcome and wants it
- A real data sample has been produced and looked at
- The cost of a wrong answer is stated, along with who catches it
- A baseline exists: what the process does today, measured
- The cheaper alternatives were considered on paper and rejected for a reason
- Year-two running cost is in the business case, not just the build
- There is a written condition under which the project stops
Bottom line
The question is not whether your business needs AI. It is whether there is a task here that is repetitive enough, measurable enough, and forgiving enough that a machine doing it imperfectly beats the current arrangement, and whether the value of that beats the cost of building and running it. That is a week of counting, not a strategy engagement. Most companies that do the counting find one or two tasks that clearly qualify and a longer list that clearly does not, which is a much better position than either enthusiasm or refusal. If nothing qualifies today, the honest answer is not yet, and the work to make it qualify is cheap, ordinary and worth doing regardless of what any model can do next year.
Frequently asked questions
A first production feature is rarely under about $60,000 of engineering and rarely over about $400,000 unless several features are being described as one. Add first-year running costs of roughly fifteen to twenty-five percent of the build for infrastructure, model usage, monitoring and someone's attention. If a quote is far outside that range in either direction, ask what is included; the low ones usually stop at a demonstration and the high ones usually contain a platform.
No. Most companies that successfully deploy their first AI feature do not have one. What matters is that somebody can get a real extract out of the systems that hold the data, and that somebody operational owns the outcome. A data team helps with the second and third project more than the first.
Buy when the task is common across your industry and a product already does it, because the vendor amortizes the work across every customer. Build when the task is specific to how your company operates, when the data cannot leave, or when the output feeds a system only you have. The expensive mistake in both directions is deciding before anyone has looked at your actual data, because that is what determines how much of a product's promise applies to you.
Give them your own examples, including the ugly ones, and watch it run live rather than reviewing a recording. Then ask what happens when the system does not know, and check that it does something other than produce a confident answer. A demo on curated data tells you the software runs. It tells you almost nothing about the fifteen percent of your cases that will determine whether anyone keeps using it.
For most mid-market companies that is a defensible position, and the cost of waiting is falling rather than rising, because tooling gets cheaper and more capable each year while your data problems stay the same size. The exception is when a competitor has changed a number you compete on, such as price, cycle time or headcount in a customer-facing function. That is worth reacting to. An announcement without a number is not.