A medical clinic in Burlington called me last week with a problem I’ve been waiting to hear about for a while.
Eight months ago they paid a different firm $22,000 to build an intake automation. It read new patient referrals from a fax-to-email service, pulled the relevant fields, cross-referenced their EMR for duplicates, and dropped a clean record into the front desk’s queue. It worked beautifully. The two intake coordinators got about ten hours a week back. The owner was thrilled and left a glowing review on the firm’s website.
Then in February, the fax service changed how it formatted email attachments. Subtle change. Nothing you’d notice as a user. But the automation broke. Not loudly. It just started missing about one referral in five.
Nobody noticed for six weeks, because the front desk had stopped checking the old fax inbox. They trusted the system. By the time a patient called asking why nobody had followed up on a specialist referral, fourteen people had fallen through the cracks. Two had moved to a different clinic. One was a serious diagnosis that needed a faster turnaround than the clinic ended up giving it.
The owner called the firm that built the automation. They quoted her $4,500 to investigate and patch it. She paid. Six weeks later the email format changed again on a different field, and they did the whole dance over.
She called me to ask if there was a better way. The honest answer is yes, but it would have meant asking different questions before she signed the original engagement.
This is the post-delivery problem, and almost nobody is talking about it.
What every AI engagement actually produces
When a consulting firm delivers an AI automation to a small business, what they are handing over is not a product. It is a small custom piece of software that depends on at least three things continuing to behave the way they did when the project shipped. The data source has to keep formatting itself the same way. The AI model the automation calls has to stay available at the version that was tested. And the downstream system the automation writes into has to keep accepting the same shape of input.
None of those three things are stable. Vendors change their APIs. Email providers change attachment formats. AI providers deprecate models on a roughly annual cadence now. Your CRM rolls out a new field requirement. Each change is small. Each can quietly break the automation in a way that does not throw an error, just produces silently worse output.
A traditional piece of software has the same problem, but it has vendors and update cycles built around the assumption that maintenance is part of the deal. Small businesses are used to that. They pay Microsoft a subscription, Microsoft pushes updates, things mostly keep working.
A custom AI automation does not have that infrastructure around it by default. If the firm that built it walked away on delivery day, maintenance falls on whoever inherits it. In a 12-person clinic, that’s nobody. So it falls on luck.
Why this gets skipped in the sales conversation
The reason most engagements don’t address this honestly is that it is very hard to sell. The sales pitch for a build is concrete. Here is what we will deliver. Here is what it will save you. Here is the fixed price. The owner can decide in twenty minutes.
The maintenance conversation is the opposite. The honest answer is that the automation will probably need somewhere between two and twenty hours of attention per year, and you cannot know in advance which year is the two-hour year. Nobody wants to sign a recurring contract for that. The firm doesn’t want to commit to a fixed retainer because the variance is too wide. The owner doesn’t want to write a blank check.
So both sides quietly agree to deal with it later. That works fine until the day it doesn’t, and on that day the owner is in the position the Burlington clinic was in. Something is broken, the people who built it want $4,500 to investigate, and there is no one else in town who can pick up someone else’s custom code.
The other unspoken thing is that maintenance work is much less profitable than new builds. A firm with its bench full of original engagements does not particularly want a queue of small fix-it tickets. So they price the fix-it work high enough that they don’t really want to do it, but will if you insist. That’s the dynamic the clinic walked into.
What changes if you ask the question up front
Three things make the post-delivery picture honest.
The first is that the engagement specifies, in writing, what counts as a structural change versus a covered fix. If the AI model gets deprecated, the engagement should say who pays for the migration and when. If the data source changes its format, that’s a covered fix for some defined window. None of this needs to be a long contract. One paragraph, agreed up front, before the work starts.
The second is that the firm hands over the actual code, not just access to a black box they host. If the firm goes out of business, gets acquired, or just loses interest in your account, you should be able to hand the code to someone else and have them pick it up. A surprising number of small business AI engagements I see are running on infrastructure the firm controls entirely, with no transferable artifact at all. That is a hostage situation waiting to happen.
The third, and the one I find hardest to make people care about until they’ve been burned, is that the automation should fail loudly. The clinic’s automation failed quietly for six weeks because nobody had built a check that asks “are we processing the same volume of referrals we used to?” That check should have been part of the original delivery. It would have caught the format change in three days instead of six weeks.
What I tell owners considering an engagement now
Three questions, before you sign anything.
Who owns the code, and can a different firm pick it up if I want them to? If the answer is anything other than “you do, and yes,” think about what that means.
How will I know if this stops working the way it’s supposed to? If the answer is “we’ll set up monitoring,” ask what gets monitored, who gets the alert, and what the response time looks like. If the answer is vague, the monitoring isn’t real.
What’s the maintenance window covered, and what’s the rate after? You want a number even if it’s small. Open-ended is worse than a fair fixed rate.
A firm that answers all three clearly has thought about what the system looks like a year from now. That’s the firm you want.
Where this lands for us
GRC’s productized engagements bake this in by default, because we got tired of having a version of the Burlington conversation. Every build ships with the source code in your repository, a documented monitoring layer that emails the owner if volume drops below a threshold, and a flat post-delivery rate published before the engagement starts. None of that makes the work itself better. It makes the year after the work better, which is where most of the actual value either accrues or evaporates.
I’d rather have a slightly more boring sales conversation about month thirteen than have the call I had last week. The clinic has mostly recovered. The patients who slipped through have been chased down and rebooked. But the trust the owner had in the technology took a hit that’s going to take a while to come back, and that’s the part the original firm didn’t price into what they sold her.
The maintenance question is unglamorous and does not photograph well. It is also where the difference between a project that pays for itself for five years and one that creates new problems six months in actually lives.
Ask the question.