You send your contractor a task: add a brand filter to the catalog. It looks like half a day of work, the contract with a monthly fee is signed, and it includes hours. Two days later the answer comes back: this is an enhancement, it's estimated separately, forty hours. Now you have to take that estimate to your boss and explain why a website the company already pays for every month needs more money.
This conversation happens on every other project, and almost never because the contractor is playing games. "Support" and "enhancement" are two different jobs that sit next to each other on the invoice, so they look like one.
What the monthly fee pays for
The monthly money is paid to keep the site in the condition it was in when you accepted it. That means updates to the software it runs on; skip them, and within a year or a year and a half holes turn up in it and someone gets in through them. It means backups, including a check that you can restore from them: a backup nobody has ever restored is a hope, and that's all it is. It means watching that the site responds and payments go through, so you hear about a failure before a customer calls. Add to that the small edits: the phone number in the header, a new menu item, the picture on a banner.
Nobody knows the volume of this work in advance. In a quiet month there's almost none, in a bad one it eats everything. That's why it's sold as a block of hours and not billed as it comes. It's also why unused hours usually don't roll over to the next month: you aren't paying for time worked, you're paying for readiness, for the fact that on a Wednesday evening someone will pick up the phone and go digging.
That leads to the first honest fork in the road. If you have a brochure site that changes once a year, you don't need a monthly fee: one-off requests will cost less, even with a rush surcharge. Ongoing support starts to make sense where every hour of downtime costs you orders, as it does for an online store, a dealer portal, or a service that takes payments.
What turns a task into an enhancement
The line isn't drawn by the size of the task or the number of hours. There's one test: does the site behave differently after the change?
Replacing the phone number in the header is support. Changing the rule that gives a wholesale buyer a discount is an enhancement, even if it comes down to ten lines in the program. The difference is that after the first there's nothing to check, and after the second you have to check the cart, the documents, the order export to 1C (Russia's leading ERP and accounting platform), and that orders already placed weren't recalculated retroactively.
A few borderline cases that cause the most arguments:
- "Change the text on a page" is support as long as the text lives in the admin panel. If it's hard-wired into the program, that's a change to the program, and it's priced differently.
- "Add a field to the inquiry form" takes half an hour if only the sales manager needs the field. If it also has to reach the CRM and the email to the customer, that's three places to change and three places to check.
- "Put up a promo banner" is support. "Put up a banner that disappears by itself at midnight and never shows to people who've already bought" is an enhancement.
- "Speed up the catalog" is almost always an enhancement, though it sounds like a repair. A slow catalog didn't break, it was always like that; to make it fast, it has to be rebuilt.
That last one is worth remembering: in an email thread "fix it" and "improve it" mean the same thing, and in an estimate they don't. A fix brings back what worked yesterday. Everything else is new, even when it feels like a trifle.
Why a small enhancement costs as much as a big one
The price of an enhancement doesn't come from the change itself. The change is the tip, and under it are four parts, each of which takes time.
- Figuring out how the existing thing works. If another team wrote the site and there's no documentation, the developer spends several hours just reading someone else's program: where the price is calculated, where the stock level comes from, what happens if this particular line gets touched. On an inherited project this part regularly takes longer than the change.
- Following the connections to other software. An example from a live project: a catalog of 400,000 items, and the client asks to add one new attribute to a product. By itself that's an hour of work. But the attribute comes from 1C, so it has to be carried through the data exchange, which runs on a schedule; delivered to the storefront; added to the files that go out to Wildberries, Ozon and Yandex Market (Russia's largest online marketplaces); and all of that without breaking the exports that already work. The hour turns into a week, and not one step in it is unnecessary.
- Checking that nothing else got hit. Not "we looked, it opens," but a run through everything the change could have reached: checkout, payment, discounts, emails. The bigger the catalog, the more it costs to be sure the other 399,999 product pages haven't shifted.
- Releasing the update to the live site so shoppers don't notice. Where releases are set up and run by themselves, that takes minutes. Where files are copied by hand in the evenings, it's a separate operation that can take the store down.
The real cost, meanwhile, tends to pile up somewhere other than where people look for it. The expensive part is the month of waiting, not the enhancement: while the task sits without an estimate, sales managers edit prices by hand and make mistakes, and the customer sees something on the site that doesn't match what they were promised on the phone.
How to brief a task so the estimate doesn't double
The most expensive briefing mistake is bringing a ready-made solution instead of a task. "Add a 'Price 2' field to the product page": the contractor will add it, and a month later it turns out something else was needed. State the result: "after logging in, a wholesale buyer should see their own price, and a retail shopper the regular one." Let the person who knows the program work out how to get there.
Then come four things that shrink the estimate simply because they remove unknowns. Say who should see the change and where: only a manager in the admin panel, or every visitor. Attach an example, such as a specific product, an order number, or a marked-up screenshot. Give the deadline and the reason for it: "by October 1, a promotion starts" gets estimated differently from "as soon as you can." And ask up front which parts will come out of the monthly hours and which will be billed separately. Ask before the work begins, not at the end of the month when the invoice arrives.
It also pays to review the whole task list once a quarter instead of one item at a time. Five small changes in one section done together cost noticeably less than the same five done one after another a month apart: someone only has to get to know that section once.
When it's time to split the budgets
If enhancements consistently outrun the hours in your package, the argument about where the line is will come back every month, and no contract wording will settle it. Splitting does: maintenance stays on a retainer, and development gets a separate budget with a task list and deadlines of its own. This has a downside, and we see it on our own projects: there's more sign-off, because every task goes through an estimate and an approval. In exchange the surprise invoices go away, and with them the "but we're already paying you" conversations.
The opposite case is just as common. If the hours have gone unused for a third month running, you're paying for readiness and not for work. The package should be cut, and an honest contractor will suggest that first. And if every little thing like a news item or a banner needs a developer, the plan isn't the problem: the admin panel is unusable, and it's worth bringing it, once, to the point where a content manager can handle it. That's a one-time enhancement that pays for itself in a few months of saved hours.
Who should get those hours in the first place, your own developer or an outside team, is a separate question, and we covered it in another article.
What to look at first
The line between support and enhancement isn't in the contract. It's in whether the task changes how the site behaves. Anything that returns things to the way they were is part of the month. Anything that adds something new is estimated separately, and the more tightly the site is tied to 1C, the CRM and the marketplaces, the more you pay for changes that sound like trifles when you say them out loud.
So before signing, ask the contractor three questions and write down the answers.
- What exactly the monthly fee covers, as a list of work and not the word "support."
- How everything outside that list is estimated, and how long the estimate takes to arrive.
- What happens to unused hours, and what counts as going over.
Three answers take up half a page and head off nearly every future argument about invoices.
