A client sends a message on a Tuesday afternoon: “Can you change the opening hours on the contact page? Thanks!” You open the project, change two lines, publish, and reply. It takes five minutes. You almost don’t think of it as work.
Now look at the rest of your afternoon. You were halfway through a layout for a different client, with the spacing figured out in your head and a few details you hadn’t written down yet. After the edit, you spend a while getting back to that point. The five minutes were real. The time it took to recover was bigger, and nobody invoiced for either.
This post is about that second cost, why it hides so well, and a simple way to decide which changes should never reach your inbox in the first place.
The cost isn’t the edit
Researchers who study interruptions at work have repeatedly found that getting back into a demanding task after being pulled away takes noticeably longer than the interruption itself. You don’t need a precise number to recognise it. Anyone who has built something complicated knows that the first few minutes after switching back are slow and a little clumsy.
That means a small request has three parts. There is the edit itself. There is the overhead around it: finding the project, logging in, making the change, checking it, publishing, replying. And there is the recovery, which is the part you feel but never measure.
Here is a worked example. The figures are made up, so replace them with your own. Say a client sends six small requests a month. Each takes ten minutes including the overhead. That looks like an hour. Add ten or fifteen minutes of lost focus per request and it is closer to three hours. If you maintain ten sites like this, it is thirty hours a month, nearly a full working week, spent on changes that each felt too small to charge for.
Why you never charge for it
Small requests sit in an awkward spot. They are too small to quote, too frequent to ignore, and too friendly to refuse. Charging for a five-minute change feels petty, so you absorb it. Then there are twelve of them, and the relationship has a pattern: the client messages, you drop everything, and a habit forms on both sides.
The habit is the real problem. The client isn’t being unreasonable. You never gave them another way to get things done, so asking you is the sensible thing to do.
Sort every change into one of three kinds
Most post-launch requests fall into one of three groups, and the right answer is different for each.
Content changes are words, numbers, photos and contact details: opening hours, a price, a team photo, a new testimonial. These are the most common requests, and they are the ones that should never need a developer. The client knows the right answer better than you do, so being the go-between adds delay and nothing else.
Presentation changes are small visual adjustments: a different colour on a button, a heading that is too long on a phone, an image that crops badly. Some of these are fine for a client to make within limits. Others quietly break a design you spent days getting right. These need a boundary, not a blanket yes or no.
Structural changes are new pages, new features, a reworked layout, a booking form, an integration. These are real development work. They should be scoped, quoted and scheduled like any other project, and that is a good thing to do for the client too, because they get a fair price and a clear date.
Once you have these three groups, “can you just change this?” stops being one question. It becomes “which kind of change is this, and who should own it?”
Give content back before launch day
The easiest changes to remove are the content ones, because the client already holds the knowledge. What they lack is a safe place to make the change. If editing feels risky, they will ask you, and they are right to be careful: nobody wants to be the person who broke the homepage.
So the handover needs to do more than send a login. It has to answer three questions the client will otherwise ask you later: what can I change, where do I change it, and what happens if I get it wrong? A good editing setup makes the second answer obvious and the third answer reassuring, with a preview before anything goes live and a way to undo a mistake.
A quick test: ask someone who did not build the site to change a heading and replace one image, without your help. If they get stuck, so will the client, and you will be the one fielding the message.
Write the boundary down in plain words
Clients are comfortable with boundaries when they are stated kindly and early. A short paragraph in your handover note is enough. Something like this:
“After launch you can update text, images and contact details yourself, and the changes go live when you publish. If you would like a new page, a new feature or a change to the layout, send me a short description and I will quote it. Fixes for anything I built that is not working properly are included for the first thirty days.”
That paragraph does three jobs. It tells the client what is theirs. It tells them what counts as new work. And it separates a bug, which is your responsibility, from a request, which is a conversation. Most disputes about maintenance come from those two being blurred.
What this does for the relationship
It is easy to assume that fewer messages means a more distant client. In practice it tends to go the other way. When your name appears in their inbox only for things that matter, such as a proposal for a new feature, a real problem, or a sensible suggestion, each message carries more weight. You become the person who builds things, rather than the person who types opening hours.
The client benefits as well. They no longer wait a day to fix a typo, and they stop feeling guilty about “bothering” you. Their site stays accurate because updating it takes them two minutes.
A short checklist to use this week
Look back through your last month of client messages. Mark each request as content, presentation or structural. Count how many fell into the first group. That number is the amount of interruption you could have handed back before launch.
Then, for your next project, plan the handover before the build ends: decide what the client will own, set up a way for them to edit it safely, test it with someone who did not build the site, and write the boundary in two or three plain sentences.
Where Baton fits
This is the problem Baton is built for. It lets a client edit the text, images and selected visual properties of a site you built, with a preview before publishing and a way to roll back, while you keep control of everything structural. It works with sites built in different frameworks, and its CMS suits lighter websites best, so check it against your project before you rely on it. Whatever tool you use, the principle stands: the cheapest edit is the one that never has to come to you.