It's 9:47 on a Tuesday. You're putting the kids to bed, or you're at your kid's game, or you're thirty seconds into a glass of wine with your spouse. The Slack ping comes in: "Hey, the portal isn't loading for the Riverside team. They're trying to close out timecards before the cutoff."
You sigh. You know what's wrong before you even open the laptop. The Stripe payments aren't going through. Or the database is jammed up. Or the small change you pushed yesterday from your phone in an Uber introduced something subtle. You log in, you poke around, you ship a fix at 10:30. The kids' game is over. The wine is warm.
That's the third Tuesday in a row.
I want to be careful here, because I'm not going to tell you that you shouldn't have built it. You should have. You absolutely should have. Six months ago you watched your team burn forty hours a week on a workflow, you went into Lovable on a Saturday, and by Sunday night you had something that handled it. It works. It's running real revenue through it. That's an extraordinary thing to have done — twenty-five years ago you would've hired a $400,000-a-year engineer to take a stab at it.
The trap isn't that you built it. It's what happens after, which is that once a tool runs the business, somebody has to operate it. Monitor it. Patch it. Roll back the bad changes. Restore the backup when the database does something weird. Write the runbook so when you're on the beach, the person on call has any idea what to do. That work doesn't go away just because the tool was easy to build. If anything, the cheaper it was to build, the more the operating side gets underestimated. The velocity of building is the part you saw, and the slow grind of operating is the part nobody warned you about.
Here's what nobody talks about. When you, the owner, are the person doing the operating, the cost isn't the late Tuesday nights. The cost is everything you didn't get to. The customer call you cut short. The strategic conversation that went forty-five minutes instead of two hours because you had to context-switch out for a bug fix. The hire you didn't make this quarter because you spent the time sorting through error logs at midnight. Your attention is the most expensive resource in your business, and you've quietly traded a chunk of it to babysit a tool that was supposed to give you leverage.
The tool meant to free you up is now the thing keeping you tethered.
I see this every week. The shape is always the same — a CEO or a partner who built something brilliant, who is genuinely proud of it, who is also a little embarrassed about the duct tape, and who is starting to resent the very thing they made. They didn't sign up to be the person on call when the system breaks. They signed up to run a business. The software was supposed to be the multiplier, not the second job.
The right answer isn't "shouldn't have built it." The right answer also isn't "hire a developer." Hiring a single engineer to operate one custom system is one of the worst trades in operating history — overpriced for the work that actually needs doing, mismatched to the variety of disciplines that operating real software requires, and now you're a software employer too. Not what you wanted.
What you actually want is for that 9:47pm Slack ping to go to somebody else. Somebody who is contractually responsible for it. Somebody who watches the system before you do, who has restored your backups in a drill last month so they know they actually work, who has the runbook open on their second monitor before you even refresh the page.
You wrote it. Beautiful. That was the hard part — and increasingly, that's the part the leaders of small businesses are going to do themselves, and we should all be cheering for that. Operating it is a different job, with a different shape, and one you shouldn't be doing on Tuesday nights at ten o'clock. The next part of the story is where you hand it off and get your evenings back.