The question underneath the question you are asking.
The framing most owners bring to AI is a yes-or-no about the technology, and it is the wrong shape for the decision in front of them. "Should we do AI" has no useful answer, because doing AI is not a thing you do; it is a category that contains a cheap monthly subscription and a six-figure custom build and a hundred options in between. The decision that moves money is not whether to engage the category at all. It is whether the specific problem you have in mind justifies commissioning something custom that becomes your asset, or whether you should rent an off-the-shelf tool for now and revisit the build later, when you have a clearer target.
That reframe matters because the two paths land in completely different places on your balance sheet. A custom build is a capital decision. You pay once to stop a leak, you own the code and the logic, and the thing keeps working and compounding after the vendor leaves. Off-the-shelf is an operating decision. You pay monthly for access to somebody else's product, it is adequate and revocable and gone the day you stop paying, and it never becomes something you own. Neither is wrong. Renting a commodity tool for a commodity process is smart; commissioning a custom build for a workflow that is genuinely your edge is smart. Confusing the two, and building custom for a problem a product would have solved, is how mid-market companies spend real money and end up with a demo nobody uses.
So the useful question is a readiness question, and readiness is specific. You are not asking whether AI is real or whether your industry is being disrupted; those are settled and unhelpful. You are asking whether you have a named, measured, stable target that would pay back a build, and whether you are prepared to own the result. The rest of this memo is the signs that tell you which side of that line you are on. The signs of readiness come first, then the signs you should wait, and the distinction between commissioning a build and buying a subscription is the same one drawn in more detail in build versus buy AI for a mid-market company.
Sign one: a workflow that is both frequent and expensive.
The first and most important sign of readiness is that you can point at one specific workflow, by name, that is costing you real money right now. Not a department, not a theme, not "operations." A workflow: the intake process that turns an inbound lead into a booked job, the document assembly that a paralegal grinds through every week, the quoting cycle that stalls between sales and engineering, the claims triage that eats your team's mornings. Readiness starts with your ability to say the sentence "the thing that is bleeding us is X" and have X be small enough to draw on a whiteboard.
Two properties have to be true of that workflow together, and the word together is doing the work. It has to be frequent, running many times a day or week, because a build earns its keep on volume and a rare process rarely justifies custom software. And it has to be expensive, consuming meaningful staff hours or generating meaningful rework or introducing delay that costs you revenue. Frequent but cheap is not worth a build; you will spend more encoding it than it leaks. Expensive but rare is usually a job for a person or a periodic service, not a system. The workflows that justify custom AI sit in the overlap: high frequency multiplied by real cost per run, which is where the payroll leak actually lives.
The tell that you have found a genuine target is that hiring is currently your only lever on it. When a process gets slow or backed up and the reflex answer is "we need another person on this," you are looking at a workflow that scales by adding headcount, which means its cost grows linearly with your business and shows up as payroll forever. That is exactly the kind of leak a custom build is meant to convert from a growing salary line into a fixed, owned cost. If you cannot identify a process where you keep reaching for the hiring button, that absence is itself a signal, and it is worth sitting with before you commission anything.
Sign two: a baseline number you could defend to a CFO.
The second sign is that you can put a dollar figure on what that workflow costs you today, and defend the figure. This is the baseline, and it is the single most important artifact in the whole decision, because it is both the test of whether to build and the only way to prove the build worked afterward. A baseline is not a guess or a feeling that a process is painful. It is a number: this workflow consumes roughly this many staff hours a week at this loaded cost, it generates this much rework, the delay it causes maps to this much deferred or lost revenue. Add those up and you have the leak, expressed in the only unit that decides capital allocation.
The baseline does two jobs at once. Before the build, it tells you whether the project is even worth doing, because the once-off cost of a build has to divide sensibly into the monthly cost of the leak. A workflow quietly costing a few hundred dollars a month does not justify a serious build no matter how annoying it is; one costing tens of thousands a month in hours and rework justifies one quickly. After the build, the same number becomes your proof, because return on investment is nothing more than the movement in that figure once the system runs. If you never established the baseline, you can never demonstrate the gain, and a result you cannot demonstrate is one you cannot defend to your board or trust yourself. The full method for sizing it and its payback is laid out in how to measure ROI on a mid-market AI engagement.
Here is the honest part. The most valuable thing about the baseline exercise is that it can tell you no. Sit down and try to price your candidate workflow, and one of two things happens. Either the number comes out large and specific, and you have just confirmed both that you are ready and what you should build, or the number refuses to come together, and that difficulty is a finding worth more than the build would have been. A workflow you cannot price is one that is either not as expensive as it felt or not understood well enough to encode, and in both cases you have learned, cheaply, that you are not ready to commission against it yet. That is a good outcome, not a failure, and it costs a spreadsheet instead of a budget.
Sign three: a stable process and an owner who will own it.
The third sign has two halves, and both are about whether the target will hold still long enough to be worth encoding. The first half is process stability. A custom build captures a workflow as it exists and runs it with less human handling, which is enormously valuable when the workflow is settled and actively harmful when it is not. If your intake or quoting or triage process is genuinely stable, running the same way month after month because you have found the way that works, it is ready to be encoded. If you are still changing it every few weeks, still arguing about the steps, still in the middle of figuring out how it should work, then encoding it now just freezes a version you are about to abandon. Stabilize first, build second. The order is not negotiable, and getting it backward is a common way that promising projects stall a few months in, a pattern traced in why most mid-market AI rollouts stall in month four.
Stability also implies something practical about your data, though less than most owners fear. The workflow does not need pristine data; it needs a home. The real test is whether the process already lives inside a system of record your team actually maintains, a CRM, an ERP, a claims platform, a project system, rather than scattered across inboxes, personal spreadsheets, and institutional memory. A build can handle messy inputs and the endless edge cases, because handling exceptions is most of the work; what it cannot handle is a process with no consistent place to read from and write to. Clean enough, not perfect, is the bar, and "clean enough" almost always means "lives in a real system." If your target workflow only exists in people's heads and ad-hoc files, the readier first move is to get it into a system of record before you commission anything against it.
The second half is ownership of the result, and it is the half owners skip. Custom AI changes how a real process runs, which means someone with authority has to decide the new way is the way, stand behind it when the team pushes back, and own the number it is supposed to move. This is a business commitment, not a technical one, and it cannot be delegated to a vendor or to IT. The engagements that succeed have a leader who treats the workflow as theirs to fix and the result as theirs to defend. The ones that fail have a sponsor who wanted the software to quietly absorb a problem they did not want to own. Before you commission anything, be honest about whether that owner exists in your building. If they do not, no build will supply them. The full picture of what a real engagement demands from your side is in how a structured diagnosis works.
The signs you are not ready yet, and why that is fine.
Just as useful as the readiness signs are their opposites, because catching them saves you the most expensive mistake in this market, which is building custom for a problem that was never shaped like a build. The first not-ready sign is the absence of a single bottleneck. If you look across your operation and nothing stands out as both frequent and expensive, if the pain is spread thin and general rather than concentrated in one bleeding workflow, there is simply nothing specific to point a build at. That is not a failing; plenty of well-run companies do not have a single dominant leak. It just means off-the-shelf tools for the diffuse annoyances make more sense than a custom build with no obvious target.
The second not-ready sign is the inability to name a baseline. If you cannot put a defensible dollar figure on any of your workflows, you are not ready to commission against them, for the reasons the baseline section already made plain: no number means no test of whether it is worth it and no way to prove it worked. The third is a process that changes weekly. A workflow still in flux is a workflow you would be encoding at the wrong moment, and the fix is to let it settle, not to freeze the current draft in software. The fourth, and the most dangerous because it hides so well, is hoping AI will fix a problem that is really about strategy, people, or incentives. If your sales are soft because the offer is wrong, or a process is broken because two teams are fighting, or work is not getting done because the right person was never hired, a custom build will automate the confusion faithfully and change nothing underneath it. Software runs a process; it does not decide whether the process should exist.
None of these is a verdict of never. Every one of them is a not-yet, and the honest response to a not-yet is to buy off-the-shelf for the immediate need, stabilize the underlying process, and revisit the custom build when a real target has emerged and you can price it. That is the disciplined path, and it is genuinely the cheaper one, because the alternative, forcing a build onto an unready problem, is the version that costs six figures and ships a demo. If part of what you are weighing is whether to solve this with an outside partner or an internal hire at all, the tradeoffs are laid out in an AI consultant versus an in-house hire.
Turning the signs into a decision you can act on.
Run yourself through the four readiness signs honestly and you land in one of three places, each with a clear next move. If all four are true, you can name the workflow, you can price it, the process is stable and lives in a system, and an owner exists, then you are ready to commission a build, and the work now is scoping it tightly enough to quote fixed-fee against that baseline. What that scoping looks like, and what such an engagement runs, is covered in what a mid-market AI engagement actually costs. The important thing at this stage is that you walk into any partner conversation already holding your own number, which is the single best protection against being sold a platform you do not need.
If most of the signs are true but one is soft, you are close, and the move is to fix the soft one before you spend, not to talk yourself past it. A workflow you can name but not yet price needs a baseline exercise, which is a spreadsheet and an afternoon, not a build. A process you love but keeps shifting needs a quarter of stability before it is worth encoding. An owner who does not yet exist needs to be named and to accept the mandate. Each of these is cheap to resolve and ruinous to ignore, and the discipline of closing the gap before committing capital is exactly what separates the engagements that pay back from the ones that stall. Which workflow deserves that attention first often depends on your sector, and the shape of the highest-value targets by industry is mapped in the industries we build for.
And if the signs mostly point the other way, the honest and profitable answer is to wait, buy off-the-shelf for now, and stop treating "we should be doing AI" as a deadline. There is no prize for commissioning a custom build before you have a target for it, and there is a real penalty. The companies that win with custom AI are not the earliest movers; they are the ones who moved on a named, measured, stable workflow with an owner behind it, and who bought the cheap packaged tools for everything else. Knowing which one you are is worth more than any build, and it is a ten-minute exercise rather than a six-figure one.