Operating Software Is Not the Same as Supporting It
When we rewrote the services page last week, we made a deliberate word choice. The retainer is described as operation, not support.
The line reads: "Not a support queue. We run the system: monitor it, fix what breaks, keep it current as the business changes."
That distinction matters more than it looks.
What Support Implies
Support implies a ticket. Something goes wrong, you write it up, someone looks at it. The queue is the mechanic: requests come in, responses go out. The system exists somewhere else, maintained by someone else, and support is the layer you interact with when it breaks.
Most dev shops sell support. They build the thing, hand you the keys, and offer a retainer for when you need changes or something breaks. The system is yours. The retainer is a phone number.
That model works if the software is simple and stable. Internal business software is neither.
What Operation Actually Is
An internal application runs on data that changes. Business logic shifts as the business grows or pivots. A third-party API changes its response format. A workflow that worked perfectly for eight months stops making sense because the team doubled. An AI agent that was producing useful output starts producing stale output because the underlying prompt didn't account for something that changed in the catalog.
None of those are bugs. None of them generate a ticket. They're the ordinary entropy of running software inside a real business.
If your developer isn't watching the system, nobody catches them. You notice something feels off, you can't articulate why, and by the time you write up a support request the problem has been compounding for two weeks.
Operation means watching before things break. It means knowing the system well enough to see when output quality is drifting, not waiting for a user to file a complaint. It means being close enough to the business that when a process changes, the system changes with it instead of lagging three months behind.
What the Retainer Floor Reflects
We set the retainer at $3,000 per month. That's not a maintenance fee. It's the cost of someone staying inside your system continuously, not just responding when called.
We keep tabs on the applications we operate. We know what the daily job scheduler is supposed to produce and we notice when it doesn't. We know which integrations have flaky upstream APIs and we watch them. When a client tells us they're adding a new product line, we don't wait for them to file a change request. We start the conversation about what the system needs to handle it.
That's what the floor buys. Continuous attention instead of reactive response.
Why Most Businesses Don't Think of It This Way
The reason "support" is the default framing is that most software isn't operated by the people who built it. A business buys a SaaS product and the vendor operates it. The business's relationship to the software is as a user, and support is the interface between users and the people running the system.
When we build a custom internal application, we built it. We know exactly what it does and why it does it. The retainer keeps us operating it, not translating tickets to a team that built something they handed off. There's no handoff.
That's the difference. Support assumes someone else is running the system and you need access to them. Operation means we're running it alongside you.
We describe it accurately because the word shapes what clients expect. A client who expects a support queue will file tickets and wait. A client who understands they have an operator will tell us when the business changes and we'll update the system before the gap shows up.
One keeps things from breaking. The other keeps things from drifting.