Every technology firm in West Michigan says it does AI right now. The claim costs nothing to make, so it tells you nothing. What tells you something is whether a firm can describe where AI sits inside its own operations, what it replaced, what it broke, and what it costs every month.
So here is ours, in detail, with the parts that did not go well included.
We are a 25-year-old consultancy in Grand Rapids. We run Sitefinity websites, managed IT, and custom development for mid-market companies. Since roughly the start of 2026, AI has moved from something we evaluated into something four of our operational functions depend on daily. Not a pilot. Not an innovation team. The regular work.
What "AI in business operations" means here
The phrase gets used loosely enough to be meaningless, so let me define it the way we use it internally. AI is in operations when removing it would slow down real work that clients are paying for. By that test, four areas qualify.
1. Development delivery
Our engineers use Claude Code, GitHub Copilot, and Codex in daily delivery work. Anton wrote up what that actually looks like after the tools crossed from novelty into habit: scaffolding, test generation, unfamiliar-codebase reconnaissance, and the boring migration work that used to eat afternoons.
The part worth stealing is Albert's rule about not handing one model every job. He wrote a whole post on it, Stop Giving One AI All the Jobs, and the short version is that separate tools get separate lanes based on what they are actually good at. One model for long-context reasoning, another for fast in-editor completion, another for one-off scripting. Give a single tool everything and you get worse output and a token bill you cannot explain.
That workflow is not reserved for internal projects. It runs on the custom software we build for clients too, and it has changed what a custom application costs to build and maintain. More on why that matters below.
2. Helpdesk and managed IT
This is the one with a number attached. Our triage hours dropped about 20% after we put an AI layer in front of ticket intake. Mark documented the whole thing, including the parts that were not glamorous, in The Hidden Work Behind a 20% AI Triage Win.
Read that post if you read only one. The 20% is the headline, but the real content is everything underneath it: a multi-vendor routing layer so we were not hostage to one provider's uptime or pricing, dependency review on every package that touched the pipeline, and a fallback path for when a model returns nonsense. The pilot took a few weeks. Making the pilot production-worthy took considerably longer.
3. The CMS
This is the area nobody else in our market is working in, so it gets the most attention from us.
We are a Progress Sitefinity Premium Partner, which means AI inside the DXP is not a side interest. We have deployments of AI-powered search running on live client sites, and we published our evaluation framework for choosing between the options in How to Choose AI Search for Sitefinity. We also put Progress's built-in RAG through real content and wrote up where it holds and where it does not.
Internally, we built a Sitefinity MCP server so Claude can operate against a Sitefinity instance directly: content audits, translation sync checks, bulk field updates, editorial review passes. Kevin's team uses it on client work. That is what AI in Sitefinity in production looks like when it stops being a demo.
4. Back office
Less interesting to write about, more interesting to our margins. Monthly invoicing reconciliation, time-entry auditing, project status reporting, competitive research, and first drafts of documents like this one all run through agent workflows now. A human reviews and signs off on everything before it leaves the building. The pattern is consistent: AI compresses the assembly, a person still owns the judgment.
What we build for clients out of all this
Everything above is our own house. The reason it matters commercially is that internal tooling keeps turning into client work, usually within a few months.
Custom MCPs
MCP stands for Model Context Protocol. Skip the acronym and think of it as a controlled doorway between an AI assistant and one of your systems. Instead of a person copying data out of an application and pasting it into a chat window, the assistant connects to the application directly, with defined permissions and a defined set of actions it is allowed to take.
Our Sitefinity MCP was the first one we built, for ourselves. Since then we have been building them for clients against their own systems: line-of-business applications, internal databases, document repositories, and operational tools that were never going to get an AI feature from their vendor. The client's own team then works with their own data through an assistant, without a migration and without waiting for a roadmap.
This is where the security discipline in the next section came from, and it is why the registration and least-privilege rules are not optional. A doorway into your ERP is exactly as sensitive as it sounds.
AI agents inside the applications we build
Adding a chat window to an application is the easy version and largely a novelty. The useful version is an agent operating inside the application on the work the application exists to do: reading an inbound document and populating the right records, watching a queue and escalating what does not fit the pattern, reconciling two systems that disagree, drafting the output a person then approves.
We build these as part of the application rather than beside it. The agent uses the same permissions model, the same audit log, and the same data validation as every other part of the system. That is the difference between an AI feature and an application that happens to think.
Replacing SaaS with custom applications
This is the shift we did not expect to be having conversations about this year, and now we have them most weeks.
For twenty years the default advice was to buy rather than build. Licensed software was cheaper than a custom application, so companies bought a CRM, bought a project tool, bought a quoting system, and absorbed the fact that each one fit their process about 70%. The gap got filled with spreadsheets, manual steps, and a per-seat bill that grew every year.
AI-assisted development moved that math. When the build and the ongoing maintenance both cost meaningfully less than they did three years ago, the comparison changes: a per-seat subscription forever, against an application you own that fits your process exactly and has agents doing work inside it that no SaaS vendor will build for a company your size.
We are building those applications now, and CRM is the most common starting point. Not because CRM software is bad, but because it is where mid-market companies most often pay for a large product to use a small part of it.
Two honest caveats. This is not the right answer everywhere. If a platform genuinely fits your process and you use most of what you pay for, keep it. And custom means you own it: there is no vendor to call, so the support and maintenance arrangement has to be real before you sign anything. We would rather talk you out of a build than deliver one you regret in year two.
The day it set off an alarm
Here is the part most vendor AI stories leave out.
On a Monday morning, our security operations partner flagged what looked like an OAuth attack against our Microsoft 365 tenant. Suspicious consent grant, unfamiliar app identity, textbook illicit consent pattern. The team worked it as an incident.
It was one of our own MCP servers connecting to Microsoft 365.
Josh wrote the full account in The Day an MCP Server Tripped Our EDR, and I would rather have that post on our site than another maturity-model diagram. Two things came out of it. First, the detection worked, which is the good news. Second, we had connected an AI tool to a production tenant without telling the people who watch that tenant, which is the bad news and entirely our fault.
The attack surface it exposed is real and underexamined. An illicit consent grant does not need a password. Someone approves an OAuth prompt, an app gets a token, and the token keeps working. AI assistants request exactly these kinds of grants, and most mid-market tenants have consent wide open by default because nobody has had a reason to look.
We changed our process. Every AI integration touching a client or internal tenant now gets registered before it connects, reviewed by our security side, and scoped to least privilege.
The rules we actually operate by
Five, learned the expensive way.
One person owns every output. No AI-generated work product reaches a client without a named human who reviewed it and is accountable for it. This is not a compliance gesture. It is how we catch the confidently wrong answers, which are the dangerous ones.
No single-vendor dependency in production. Model quality, pricing, and availability all move around. Anything load-bearing runs through a routing layer with a fallback.
Register the integration before you connect it. See above.
Measure the boring metric. Not "is AI amazing." Hours on a task before and after. Error rate before and after. If we cannot state it, we are guessing.
Publish the failures. The EDR incident post gets read by prospects. It builds more trust than any capability claim we could write, because a firm willing to publish its own false-positive incident is a firm that is actually in production.
What this costs
Honestly: less than people assume in tooling and more than people assume in operational attention.
The seats and API spend are not the interesting line. The interesting line is the ongoing management. Token budgets drift. A model version changes and a prompt that worked stops working. Someone finds a new tool and connects it to something they should not. Every one of these is a small ops task that did not exist two years ago, and collectively they need an owner. If you are budgeting for AI and you have only budgeted for licenses, you have budgeted for maybe half of it.
Why we are telling you this
Two reasons.
The first is that we think it is the only honest way to evaluate an AI partner. Ask any firm you are considering where AI runs inside their own company, what it broke, and what the failure modes were. A firm running it will have specifics and at least one embarrassing story. A firm selling frameworks will have a diagram.
The second is that this is the whole basis of how we work with clients. We do not roll out anything to a client environment that we have not run in our own first. The triage layer, the CMS tooling, the MCP pattern, the tenant governance rules, all of it went through us before it went through anyone else. That is a slower way to build a practice. It also means when we say a thing works, we have the incident tickets to prove it.
We publish this kind of write-up twice a week. Some of it will be wins with numbers, some will be things we killed. If you want the pattern rather than the highlight reel, the Insights archive is all of it.
And if you want to talk about where AI belongs in your operations, whether that is an MCP into a system you already run, agents inside an application we build you, or a hard look at which SaaS subscriptions have outlived their value, that is a conversation we have most weeks.
Talk to us about AI in your operations.
An MCP into a system you already run, agents inside an application we build for you, or a hard look at which SaaS subscriptions have outlived their value. We'll bring the specifics from our own house.
Explore AI Services arrow_forwardEric Spencer is at Springthrough, a digital strategy and technology consulting firm based in Grand Rapids, Michigan.