I am a freelance web developer. I have built many different websites for all sorts of people. Once my client signs off on a project as complete I am still willing to offer little updates and things. I always have that one client though who abuses this offer. At what point do I say enough is enough and begin to charge for these changes? Enough of these little changes could add up to a whole new site.

7 Answers 7


Here's my insight.

Working as a freelancer makes you control your time more thoroughly and prioritize the projects and tasks you are currently involved in.

So, for me, "marking" the project as complete means that me and my customer should sit and discuss our future plans: are we going to make updates (software updates, bug fixes, other improvements), what if the customer needs my technical support etc. And, of course, it's your time and should be billed.


There are several categories of post-changes. They should be treated in different manner, unless your agreement with the project owner states otherwise.

So, you have completed a project and, trying to satisfy your client, you offered...

Little Updates and Things

  • Bugs. As your software product is running and users are using it, they will inevitably find bugs. They should be eliminated at your cost, since you have already been paid for it.
  • Changes due to external factors changed. Say, local laws may require a different format of a certain report. Or the users' community has asked the product owner for a change. Or a dependency software has changed its API. Since that was not in original scope, such improvement is clearly billable;

The rest of changes are most difficult to deal with. What I do often when being asked for such change, I analyze the thing and make two offers:

Free way: I do some minor change that does not take more than, say, several hours.
I make sure the project owner was aware that I will do it on my personal time so it did not interact with my billed activities, e.g. on weekend.
I also inform the project owner that any side activity should be done by their teams. I'm a Web developer, so I can't do free QA, Art, HTML/CSS mockups, team collaboration, and other things. This is a powerful argument by itself! :-)

Billable way: A full-power work that ensures best possible scope and quality.


Also, as others have mentioned in their answers, a good practice is conduction a post-mortem meeting. At this meeting, you will define how your project will be improved over time.
As an important note specific to a freelancer, on this meeting you will almost guarantee yourself some future income:

  • You guarantee to continue your business relations with the project owner;
  • You define status of forthcoming changes, possible scope, and rates;
  • You ensure that the product you have developed will be at top quality. Think again, you will refer that product as your past work. Say, you show it to another prospective customer. Do you need excuses why the product looks buggy or outdated? No.
  • You secure for yourself the future projects with the same partner;

There's an article by Jeff Atwood, The project Postmortem addressing more issues.

Finally, a story that illustrates the ideas above:

A freelancer and a client are talking after project completion.
Client: "But aren't you someone who just makes and forgets? If we need an update, would you do it for free?"
Freelancer: "Sure, but it depends on how much work to do."
Client: "Don't worry! Of course we wouldn't ask to redo everything from scratch."
Freelancer: "Agreed. I also have a request. Aren't you someone who just pays me and forgets? If I run out of money, can I come up and ask you to pay me some extra?
Client: "???"
Freelancer: "Don't worry! Of course I wouldn't ask you to pay me the whole amount again!"

  • 7
    I disagree about bugs being your responsibility to fix. As you said, there will inevitably be bugs, and if you commit to fixing them for free there's no end to it. The client should test and approve the code, and any modifications to it later (including bug fixes) are billable work.
    – JJJ
    Commented May 22, 2013 at 9:01
  • @Juhana (sarcasm mode on) You buy a car in my shop. You, the client, should test and approve the product prior to purchase. If you commit with a purchase, and the car falls apart just behind the doors of my shop, it's no longer my problem. Is that correct? :-) Commented May 22, 2013 at 10:17
  • You're comparing apples to oranges here. You don't pay to the car manufacturer by the hour based on how long it took to build the car, do you? (Or perhaps we're just talking about different things; if you're paid a lump sum to build X, there should be a limited guarantee.)
    – JJJ
    Commented May 22, 2013 at 10:23
  • @Juhana The definition of a bug: an inconsistency between documented and actual behaviors. Even for Time-and-Materials projects, I have been paid not for "spending time", but for specific tasks to make a software that behaves in a certain manner. That manner is defined in a task specs, and the docs are based on specs, not on actual behavior. Hence, if my software does not behave like described (and initially required), and I have been already paid for it, who should fix it? Commented May 22, 2013 at 10:30
  • 1
    that is like a snake biting in it's tail: As all software has bugs, the customer can never order bug-free software. Or if it orders bug-free it can not expect to get it unless there is a maintenance plan.
    – hakre
    Commented Jun 6, 2013 at 8:37

I think you need to define out what a "free change" really means. Less than 15 minutes within 30-60 days of project end date? Sure, especially if its a quick and easy change. I don't see an issue with that.

More than that, 1 hour minimum at an hourly rate. This will encourage them to either stop abusing the "free change" or start gathering up a minimum amount of changes... which will more than likely exceed an hour.

You also have to actually explain this to them. They may not realize they are abusing it!


Something like this would have to be defined in your contract with the client, including with what constitutes a minor change (as opposed to a major change). You may also want to base it off of the original deliverable; after X minor changes or after at least Y% of the code base changes, there would have to be a charge for further changes.

  • 3
    I think you've highlighted a possible cause there. Very few freelancers - in my experience being one, and working with others - HAVE contracts with their clients. We should... but many don't. Commented May 22, 2013 at 0:31
  • 1
    Another option is: after X hours.
    – Rog182
    Commented Jul 14, 2014 at 23:43

This is always a business decision. As a general rule I fix bugs and the like free of charge. I offer a one year warranty on bugs and so forth.

I will also throw in small changes free of charge (without promising customers this upfront) when it seems like a good idea given the general relationship with the customer. Maybe the customer badly misunderstood some requirements but the change isn't invasive, and I like working with this customer. I may throw it in free of charge just as a nice gesture.

The thing though is that in general you should make your free change promises as limited as you can. When you decide to go beyond that, you should be the one to look generous, going beyond what you promised. It's always easier to say "you know what? I will even do that free of charge!" than it is to say, "well, this is getting annoying, so more help will be paid."


Setting boundaries early is essential as most clients quickly get used to you doing things for free and then they don't appreciate the free hours you put in.

Establish agreed terms and conditions in advance that include a project sign-off date and warranty period.

My clients have two weeks to test and report bugs and I will happily fix these for free.

Beyond the two weeks, I don't charge for minor issues that only take me a minute or two to fix. Sometimes I don't charge for longer tasks but that's at my discretion. I'm more likely to do things for free if it's my mistake rather than something that looks more like a feature enhancement, something outside the original scope, or something that wasn't clearly defined to start with.

Track your un-billed hours so you can tell clients with unreasonable expectations the ratio of un-billed hours to billed hours. 10% might be reasonable but 20% is probably stretching the friendship. If possible, show the un-billed hours on your invoices so clients are aware of the extra time you have put in for them.

Don't be afraid to sack clients who fail to appreciate excessive un-billed hours. Remember that losing a client is not the end of the world and is likely to open your schedule to a better client.


I offer actual bug fixes for 30 days after launch, but everything else is billable (either my hourly rate in half-hour increments or a minimum five-hour-per-month retainer for clients with whom I have an ongoing relationship). My contract is also explicit about what, if any, responsibilities I have post-launch. During our final project meeting (post-launch), I go over that with clients and remind them which bits of their sites need regular updates (e.g., WordPress, plugins) and their responsibilities with regard to backups of files and databases.

I do this not to nickle-and-dime the client, but to protect my time. I can always choose/opt to offer to do a fix or update for free, but I want to have that choice. It's also important, I feel, to be tracking your time pretty diligently, including these sort of unbilled hours so you can identify where your time is going and make your business more efficient.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.