What to charge when the client asks for just a small tweak
The problem with “just a small tweak”
The project is done. The site is live, the client is happy, you received payment. Two weeks later the message arrives: “Hey, all good? I need a small tweak on the site, nothing major.”
That “small tweak” could be swapping a photo (5 minutes), redoing the entire services section (5 hours), or “adding a full blog with search functionality” (5 weeks). The client has no sense of the difference because to them it’s all “changing something on the site.”
If you don’t have clear criteria for pricing these requests, one of two things happens: you do it for free and accumulate resentment, or you charge randomly and lose the client. Both are bad.
After 8 years working in web development, I landed on a model that works for me and my clients. It’s not complex. It’s transparent.
Define what’s included before delivery
The best time to solve the “small tweak” problem is before it exists. In the contract or proposal, make clear what’s included in the project price.
What I include in the project price:
- One round of post-delivery adjustments (7 days after final delivery)
- Bug fixes (something that doesn’t work as specified)
- Responsiveness adjustments that were missed
What’s not included:
- New content (pages, sections, text that didn’t exist in the scope)
- Design changes after approval
- New functionality
- Ongoing maintenance
When this is written in the proposal, the conversation changes. The client knows the adjustment round is free. And knows that out-of-scope requests have a cost. No surprise, no conflict. Just agreement.
With AutoPars, the scope was detailed in a specification document. Every feature listed, every integration described. When the client asked for something outside the spec, the conversation was simple: “That’s not in scope. I can include it for R$X, or we leave it for the next cycle.” Zero friction.
The 30-minute rule
My personal rule: if the adjustment takes less than 30 minutes and the client has a recent project with me (last 3 months), I do it without charging. Swapping a photo, fixing a text, adjusting spacing. These are things that maintain a good relationship and cost me almost nothing.
Above 30 minutes, charge. Not because 31 minutes is expensive, but because above that threshold the work stops being an adjustment and becomes a demand. And demand needs a price.
The rule is flexible. A client who referred 3 new projects gets more goodwill than a client who never referred anyone. This isn’t favoritism. It’s commercial reciprocity. But the 30-minute rule as a baseline prevents me from working for free out of habit.
How to price maintenance
For recurring demands (monthly content updates, seasonal adjustments, occasional optimizations), I work with two approaches:
Per demand (one-off). The client asks, I quote, they approve, I deliver. Works for clients who need adjustments 2-3 times per year. The price depends on complexity, but I maintain an internal reference table:
| Type of demand | Estimated time | Price range |
|---|---|---|
| Swap text and images | 30 min - 1h | R$100 - R$250 |
| Add new section | 2-4h | R$300 - R$600 |
| Create new page | 4-8h | R$500 - R$1,200 |
| Simple integration (form, analytics) | 2-4h | R$300 - R$600 |
| Redesign existing section | 4-8h | R$500 - R$1,200 |
| Performance optimization | 2-4h | R$300 - R$600 |
These values are reference points, not a fixed table. They vary with complexity and context. But having an internal reference prevents me from inventing prices on the spot and charging inconsistently.
Monthly package. For clients who need ongoing attention: R$500-1,500/month depending on volume. Includes X hours of work with limited rollover. Works for clinics that update content every month, or businesses with seasonal campaigns that need a new LP each quarter.
In my experience, most institutional site clients don’t need a monthly package. They need 2-3 adjustments per year, which are solved per demand. Monthly packages make sense when demand is predictable and frequent.
Scope changes during the project
Different from post-delivery adjustments, scope changes happen during development. The client approved 5 sections and now wants 8. Or approved a clean design and now wants animations everywhere. Or remembered an “essential” feature that wasn’t in the brief.
My approach: I don’t say “no.” I say “yes, and it costs X more.” Or “yes, and it goes in the next cycle.”
The conversation works like this: “I understand you want to add this section. It wasn’t in the original scope, so it adds R$[amount] to the project and [timeline] days to the schedule. Do you want to include it now or leave it for post-launch?”
Giving options is important. The client decides if it’s worth it now or can wait. Often they realize it’s not that urgent and agree to leave it for later. Other times it’s genuinely important and they accept the extra cost. In both cases, the decision is theirs and there’s no friction.
In the post about MVPs, I talk about the post-MVP backlog. Every idea that comes up during development goes to a separate list. This works for scope changes too: the idea doesn’t die, it just goes to the right place.
Bug fix isn’t an adjustment
There’s confusion between bugs and adjustments. A bug is something that doesn’t work as specified. The WhatsApp button doesn’t open on mobile. The form doesn’t send. The image is distorted on Safari. This is a defect in my work and I fix it at no cost, at any time.
An adjustment is something that works, but the client wants it different. “The button is blue but I wanted green.” “The font is the size we agreed on but I want it bigger.” “I want to swap the banner photo.” It works as delivered, the client wants to change it. This is an adjustment and follows pricing rules.
The distinction seems obvious, but in daily practice it becomes a gray area. The client says “there’s a problem” when they actually mean “I didn’t like it.” Having the scope documented resolves this: if it’s different from what was approved, it’s a bug. If it matches but they want to change it, it’s an adjustment.
How to communicate the price without losing the client
The hardest part isn’t defining the price. It’s saying the price. Many devs work for free because they’re afraid of losing the client if they charge. The irony is that working for free is what causes burnout and makes you lose the client anyway, just through exhaustion.
What works for me:
Respond quickly. The client sends “I need an adjustment,” I respond the same day with a time and cost estimate. Taking long to respond creates anxiety and the feeling that it’ll be expensive.
Show what’s included. “For this change, I’ll need to adjust component X, test on 3 browsers, and deploy. I estimate 3 hours of work, that comes to R$450.” The client understands what they’re paying for.
Offer alternatives when possible. “The full change would be R$800. But if we only do [essential part], it’s R$350. Which do you prefer?” The client feels they have control over the investment.
Don’t apologize for charging. “Sorry I have to charge, but…” devalues your work. “The investment for this change is R$X” is professional and direct.
With Soline and Tok Final, post-delivery adjustments follow this model. The relationship with the client stays good because the rules are clear from the start.
What not to charge for
Not everything needs a price. Some things make sense to give for free as strategy, not generosity:
- Bug fixes at any time (it’s your responsibility)
- Small adjustments within the free post-delivery round
- Quick consultations via message (2-3 minutes of response)
- Recommending a tool or service that solves without you needing to work
These actions build reputation and generate referrals. The client who receives attention without being charged for every breath refers more. And referrals are the cheapest acquisition channel that exists.
The boundary is clear: if you’re opening the code editor, it’s work. If you’re answering a question on WhatsApp, it’s relationship.
- Does your proposal define what’s included in the price?
- Do you have an internal price reference by demand type?
- Do you distinguish bugs (defects) from adjustments (changes)?
- Do you respond with estimates the same day?
- Do you offer alternatives when the price is high?
- Can you say “it costs X” without apologizing?
Communicating value clearly keeps the client. Working for free out of fear loses them through exhaustion. A fair and transparent price strengthens the relationship.