Autopsy Lesson #1: Don't Serve Nasty Left-Overs

There exist a variety of ways to handle this. Declining maintenance work is a strategy. If that works for you and your clients, bully for you. Maintenance work sold properly can both have fat margins and be a powerful sales tool, though, so many consultancies offer it.

I think you're correct that slicing off 30 minutes here and 2 hours there is nearly useless for clients because of the switching costs involved in intellectual work. You need to reach flow state to do well by them. So don't sell them anything which structurally inhibits flow state.

Let's say, for the sake of argument, that we're mutually skilled, that our core offering is charged by the hour (cough though it would be better for everyone if you switched to daily or weekly rates cough), and that the core offering costs $200 an hour.

Here's the maintenance contract you sold: "We'll do maintenance work on an as-available basis, up to your budget of 20 hours a month. I'm not going to carve out preferential scheduling for it, though, so it will be dribs and drabs when the team has downtime. Maintenance work costs $200 an hour times the number of hours consumed."

Here's the maintenance contract I'd sell: "Thanks for investing $200,000 in getting your project completed with us. You and I both know that, after we deploy this project, you're going to discover through your customers' use of it that we didn't anticipate 100% of the stuff you'll want. That's totally natural in software. Tell you what: we'll sell you a maintenance contract on the project for $5,000 a month. We agree to maintain internal expertise about your project and the staffing flexibility to promise you development services in a timely fashion responding to any fixes or feature requests you have, up to 2 days worth per month. If you need more than that, or if you do not buy the maintenance contract but need help anyhow, we're more than willing to listen to a proposal for a new MSA and SOW, subject to our then-prevailing rates and availability."

After I've sold four clients on maintenance contracts, one of my developers is essentially full-time paid for by maintenance, so I will always schedule engagements with one developer hidden behind my back. (One dev means one full-time equivalent, not necessarily "Hey Bob, you're our maintenance engineer, who suffers so all the rest of us can do the fun, intellectually engaging work.") They're paid for but, crucially, not 100% utilized, which allows me to have a slack-time reserve for e.g. unplanned employee absences, internal projects, or one-off sprints for maintenance customers which are technically in excess of what we've sold them but justified by our desire to delight long-term good customers who probably haven't been diligent about using their entire allotment every month. (Note for people who haven't run consultancies: What does a $5,000 a month maintenance contract cost if you don't require any work in a given month? $5,000. It's like health insurance: just because you don't have your appendix burst doesn't mean we give you a rebate.)

This seems to be a pretty common problem -- I've inherited a couple of projects suffering from this, and I've been guilty of it plenty too.

When a project goes to maintenance, it really becomes a completely different project. The skills that launched the project aren't the skills that are needed to keep it alive forever.

There are people who really prefer doing maintenance. They hate looking at a blank page, but they're happy to chew through bug reports and feature requests and make small changes to code or design all day long. Try to hire one or two of those people (and, honestly, they rarely command the kind of pay rate that a creative team does).

Client's happy, team's happy, you get residual income.

...I might be talking out of my ass though, I haven't gotten to this step yet.

We're a 28-person consultancy, and run into this a lot. One approach that we've found to work is to help the client bring on at least one in-house employee (contract or full-time) with enough technical expertise to conduct updates and improvements. We then shift into a "leadership" role, maintaining overall responsibility for the product's continued success, but guiding most of the low-leverage day-to-day work to their in-house guys. Management, by necessity, is much more amenable to "task-switching" than is hands-on technical work, and represents a harder-to-find skillset for many clients, so it's typically not too difficult to sell this kind of continued engagement.

Who else read the title of this post and expected something vastly different?

His Creo is some other Creo, not the Kodak's daughter company.