Month one is not metered

Go-live is not the end of a build. It is the first time the system meets the people who did not attend any of the meetings, and they find things in a fortnight that testing did not find in four months. Somebody in a branch office has always entered the reference number with a space in it. A report that looked complete needs one more column before finance will accept it. A role that seemed obvious turns out to cover two jobs that should not see each other's records.

None of that is a defect in the usual sense. It is the system arriving in the real world. And it all happens in the first few weeks.

Metering the first month makes people ration their questions

If the client is buying support by the hour from the day they go live, they start doing arithmetic before they email me. The small things go unreported: the spacing in the reference number, the column finance wants, the person quietly keeping a parallel spreadsheet because the new screen does not quite fit how they work.

Small things compound. The parallel spreadsheet becomes the real record within a month, and then the system I was paid to build is a data-entry chore sitting next to the thing people actually use. I would rather hear about it on day nine, for free, while it is still one person and one habit.

So the first month after go-live is uncapped and included in the price. No hours counted, no approval needed to ask. Answered within one business day.

After that it is capped, and the cap is the point

Months two to six are ₱25,000 a month for up to eight hours, agreed in writing before handover. It is the cheapest hour I sell, and that is deliberate, because the number being bought is not the rate. It is the cap.

An uncapped support promise from one person is a promise that breaks. It breaks quietly and late: two engagements in, a Friday afternoon, when both clients need something and one of them does not get it. A capped commitment is one I can actually hold against a full working week, and a client would rather have eight hours that arrive than unlimited hours that turn out to be conditional on nothing else going wrong.

The tail is five months rather than open-ended for the same reason. By month six a system has been through a quarter end, a staff change and at least one thing nobody anticipated. If it still needs me every month after that, the problem is not support, it is that something was built wrong and should be fixed rather than nursed.

What the client is really buying is the absence of a cliff

The question a board asks before awarding a build to one person is never about patching. It is: what happens to us if he disappears. A support window does not answer that on its own, and I am not going to pretend it does.

What answers it is the boring inventory. The accounts are in the client's name, not mine. The code is in their repository. There is written documentation and a recorded walkthrough made while the reasons were still fresh, not reconstructed afterwards. Any competent developer can pick it up, and the support months exist so that the handover is a transition rather than a drop.

Why I publish this rather than negotiate it

Support is the part of a software contract most often left deliberately vague, because vague is easier to sell and easier to walk away from. It is also the part clients get hurt by most, usually six months after everyone stopped paying attention.

Writing it down before handover costs me the flexibility to be generous when I feel like it and stingy when I am busy. That is the trade. A number on a page can be taken into a budget meeting; goodwill cannot.