I had a conversation last month with a sharp operator who'd been burned by an MSP arrangement, and what stuck with me was how nice the original deal had sounded. Flat fee. All-inclusive. "Don't worry — if you need a tweak, just let us know, we've got you." A handshake, a one-page agreement, a comfortable monthly number, the kind of arrangement that feels great on the way in.
Six months in, he'd asked for a "small change" that turned out to take two weeks, and the relationship started cooling on both sides simultaneously. He felt like the response time on small things was getting worse. They felt like he was abusing the arrangement. Twelve months in, the partnership was over, both parties were a little bitter, and he was telling me about it on a discovery call as the cautionary tale for whatever came next.
The thing is, neither side was wrong. The deal was wrong.
"Unlimited changes" is the phrase every prospect wants to hear and every honest operator knows can't be priced. There's no fixed monthly number that survives unlimited scope. Either the vendor starts slow-walking the requests to protect their margin (which feels like declining service quality from the buyer's side), or the vendor honors every request and quietly runs their own business into the ground, or — most commonly — the vendor and the buyer spend the entire relationship litigating what counts as "a quick change" versus "a real project," with neither side feeling good about it. The arrangement that survives year three is the one that draws the line clearly upfront, writes it down, and lets both sides feel good about staying inside it.
The line, for what it's worth, isn't subtle once you draw it. Support keeps the system healthy. Enhancement moves the system forward. Two different jobs. They look superficially similar — they both involve someone changing the software — but they have different shapes, different cadences, different decision-making processes, and very different cost structures.
Support is monitoring, incident response, bug fixes, dependency updates, backups, runbooks, the small things that keep the system in operable condition. The work is reactive and bounded. It's also bounded in a specific way — most of it can be handled by a software agent in minutes, the kind of thing where if the request is "the address field needs to accept apostrophes," it's done before lunch, no ticket, no approval, no charge above the standing fee. That kind of trivial change should obviously be inside support, and we don't even pretend to bill it separately.
Enhancement is a new module, a new integration, a new role in the system, a new report that requires changes to how data is stored, a workflow that didn't exist before. Those are projects. They have scope, dependencies, design tradeoffs, and a real risk of breaking things if rushed. Trying to fold them into a flat support fee is how the relationship gets poisoned, because either we say no to things you legitimately need, or we say yes and silently absorb cost that we're not getting paid for, and one of those is going to break the arrangement eventually.
So we treat them separately. Enhancement work happens through capacity blocks — a small block for the steady stream of bounded changes a healthy business produces, a larger block for quarterly cadences, or a defined sprint for a specific feature with a written scope and a fixed price. Sometimes a fractional embedded engineer if the volume justifies it. Each one is its own deal, written down, with a known cost and a known shape.
What this gives the buyer is — for the first time in a lot of buyers' experience — a partnership that doesn't degrade. Year one of a flat-everything contract is honeymoon. Year two is when the model starts showing its strain. Year three is when the partnership either ends or transitions into a pattern that's mutually grudging. The bounded model dodges that whole arc. We're not losing money on you. You're not feeling slow-walked. The line between "support" and "enhancement" is something you can see on every quarterly report, and you can decide for yourself whether you want more or less of either, with a clear sense of what each one costs.
I'd rather lose the deal than sell unlimited changes. We say so on the website. We say so in the first call. The buyers who don't like it self-select out, which is a feature, not a bug — they're going to buy the unlimited promise from someone else, and we'll be having a different conversation in eighteen months when the relationship has soured. The buyers who do like it tend to be the ones who've been burned before, who recognize what they're looking at, and who genuinely want a partner that's still going to be functional in year three.
Scope is the product. Bounded, written, fixed. That isn't a constraint we're embarrassed about. It's the thing that makes the partnership work.