"Why does it cost $200 to change a button?" is a fair question that deserves a real answer. Post-launch changes cost what they cost for reasons that are invisible from outside, so let me make them visible.
What a "small change" actually involves
Take a real example: "change the contact form to ask for a phone number."
- Re-enter the project: reload the code, the deploy setup, the form handling into working memory
- Make the edit in the form and anywhere form data is processed or stored
- Check every place the form's data goes: email notifications, spam filtering, database, admin view
- Test on desktop and phones, because forms are where mobile layouts break
- Deploy carefully to a live site that real customers are using mid-day
- Verify the live site, because staging lies sometimes
That is 1 to 3 hours for a change that "is just adding a field." The math is not gouging; the change is simply bigger than it looks, and a live site makes every change slower and more careful.
Why post-launch hours bill differently from build hours
During a build, the developer lives inside your project. Context is loaded, the whole codebase is fresh in mind, and testing happens continuously. After launch, each request pays the re-entry cost again. That is why 5 hours of scattered post-launch edits can cost more than 5 build hours, and why batching changes into one request is the single best way to cut this bill.
How change requests work (the fair version)
A change request is one short paragraph: what changes, what it costs, when it lands. You approve it, then the work happens. This protects both sides:
- You never get a surprise invoice for work you did not ask to be started
- The developer never does unbounded free work while quietly resenting it
- There is a record, which matters when you later wonder "when did this change and why"
If your developer absorbs every request silently, one of two things is happening: you are being billed generously today and padded next quote, or resentment is accumulating. Neither is a healthy arrangement.
Typical post-launch prices, so nothing surprises you
| Change type | Typical range |
|---|---|
| Text/image swaps, small layout tweaks | $50 to $150 |
| Form or field changes | $100 to $300 |
| New section on an existing page | $200 to $600 |
| New page matching the existing design | $300 to $800 |
| New feature (booking, payments, filtering) | $1,000+ |
These vary by developer and region, but if your quotes sit far outside these bands, ask why.
What should be free
Small fixes to things that were in scope and are broken: that is warranty work, not a change. My projects include 14 days of free tweaks after launch for exactly this. If your developer charges to fix their own bug from last week, that is a relationship problem in a billing costume.
The habit that keeps costs down
Keep a running list. When changes accumulate, send them as one monthly batch with clear priorities. A single batched request of five edits costs noticeably less than five separate requests, because the re-entry cost is paid once. Owners who do this typically cut their post-launch spend by a third without changing anything else.
If you are staring at a change quote that feels inflated, send it over with what you asked for. I will tell you whether the price matches the work or the padding.