Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
So I just started freelancing both in desktop/web development and this client who already accepted my work, and payed me keeps coming back at me each time he finds a bug etc. And I have found myself spending more time than I thought fixing them for free. Is this alright, or should I start charging a support fee?
Which is the best way to deal with fixes on a supposedly accepted and completed work?
Part of your contract should describe acceptance tests i.e. tests that the client will do and your application needs to pass them for the contract to be fulfilled. Anything not covered by these tests is client's responsibility. Anything covered by them is yours.
Because it is not possible (especially for a non-technical client) to forsee all possible issues, you should add into your contact a clause specifying a period, when you will fix any new issues as part of a contract. After that, you should offer only paid support.
It depends.
In the first instance you should pay as it can be argued that the work isn't complete.
Later on the customer should be paying for continued support.
However, the problem is in deciding where the boundary is and what constitutes a bug and what's a new feature. Having requirements and/or acceptance tests goes a long way to defining this.
You really need to get these things in place before you deliver the work, but if you haven't then perhaps now is the time so say - "I'll support this for free for the next N days/weeks, but after that we need to discuss a support contract" (note my emphasis on "we").
Having said all that though, there are times when you will need to fix a bug for free and take the hit. If nothing else it builds up good will.
All of the answers given above are good. However, I'd add a few bullet points to consider:
Is the client valuable to you? Sometimes it is worth going the extra few yards to keep a client happy if you feel they are valuable to you and will bring you more work in future. You need to find a balance between being strict and flexible and this may differ for each client. No point losing future work just because you are adamant that an easy-to-fix bug falls out of scope. On the other-hand, you don't want to let the client walk all over you. It's a delicate balance!
Is the bug something that could easily have been missed in user testing? For instance, take a date-related bug that only comes into play when a certain year is entered (think Millennium bug etc). A client couldn't reasonably be expected to spot this during testing therefore the onus is on you to fix it.
When I was freelancing, my basic customer agreement defined a condition called "acceptance", which was required before I put the project live to the public. At the moment of acceptance, there began a 30-day period I called "up and running support". After that 30 day period, ongoing work on the project was billable hourly.
If you have a good relationship with this client, have a heart to heart with them about how unworkable the current situation is for you, and propose a fair hourly rate for ongoing maintenance and support. People sometimes think that buying custom software is like buying a sandwich or something, like once it's built it's done. It's just not like that.
Generally you can go for a free support for fixed number of days after you deliver the application. Certainly a life time free support is not possible/unacceptable.
Make sure the bug raised is a BUG and not a change to existing feature. For any feature change you should charge.
If he tested it and signed it off, you could argue that he should pay.
If you pride and value your work, you could argue that you would fix the code. Learn from the experiences and build better code next time, more efficiently. Or factor in more profit to cover bug-fixing.
If the program does something undesirable or unexpected given the inputs, then it's a bug, and should be fixed.
You could have quoted for the support fee up front as an extra to the initial development work.
In your contract, specify a per-hour rate and keep track of your time. When you give your client the price, specify that this is an estimate and the actual result may be less or more.
Keep the client up to date on the progress, and when he inevitably makes suggestions, you can simply tell him the time it will take you (if change is outside original specifications) and he can decide whether the change is worth the money. Therefore only changes important to him will be added.
I would personally cover acceptable vs unacceptable (paid support vs free support) bugs in the contract, and that way you at least have something in writing from the get go. He will undoubtedly wonder why you should need that clause, so be upfront and explain that if a new OS update comes out that breaks something, that isn't free support. However, bugs in your code according to the original specification on the specified platforms would be covered.
However, I should mention I have only done freelance IT work rather than programming. This could possibly scare off clients, but just make sure your work sells itself, be more professional, outgoing, and helpful than the rest, and be forthcoming with your reasons for having a more strict contract.
Besides, a client who won't accept that clause is most likely a bad client.
