At what point is it no longer a "Free Change"

Question

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.

Answer 1

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.

Answer 2

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.

---

Post-mortem

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!"

Answer 3

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!

Answer 4

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.

Answer 5

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."

Answer 6

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.

Answer 7

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.