Ask HN: supporting code post-contract for freelance jobs? | Hacker News Reader

Ask HN: supporting code post-contract for freelance jobs?

12 pointsthrowaway_today9 comments

TL;DR: do you charge for ongoing support for completed freelance work?

I'm relatively new to freelancing. I just finished a gig that I did for about $6500. I spent over a month on this thing full-time, so it wasn't the most lucrative job, but I was trying to get my foot in the door. In the end I produced over 10K LoC.

The client had a lot of mid-flight changes, which I tried to handle as gracefully as a I could, but it really ended up extending the timeline.

After code-complete, the client had a 1-week beta period with some testers. I fixed some small issues, the client blessed it, and off it went to production. Now it's in running under a heavy load in prod, and of course issues are starting to crop up. App server running out of PermGen memory, some Hibernate issues, etc.

Tracking these issues down takes a lot of my (unpaid) time. I'm not perfect, so some of them are likely bugs in my code. But many of them are bugs in libraries (GlassFish PermGen space in particular has been a thorn in my side).

When free-lancing, how do you handle the issue of handle ongoing support? I want to be responsible and ship a high-quality product, but there are always issues and bugs when dealing with software. When working for a company, there was always the understanding that there would be ongoing maintenance, and time was budgeted accordingly. How does that work in the contracting world? I just feel like this could drag on forever.

It doesn't help you with this project, but ongoing support should be something addressed in your initial contract -- e.g., "20 hours of post-shipping support are included. Additional support may be purchased at a rate of no less than $XXX per hour, subject to availability, and may be declined for any reason."

Great idea. I like that it includes a reasonable amount of support, but also puts a cap on things. I wish I had thought of that ahead of time. Also encourages the customer to test things out in their environment early, rather than assuming it'll just work fine under any circumstances.

We are trying to find the balance between selling on-going support contracts vs doing as needed support later. It looks like ~90% of our customers don't believe they will need to support the technology later and choose not to pre-purchase (at a lower rate).

And does "support" include bug fixes in your own code? Not asking to be snide; I really want to understand how most people approach this.

Yes, support includes bug fixes.

If you want to put bug fixes into the price of the contract, you need to also put the cost of proper QA, test plans, and defining correct behavior, which often means a spec. How do you know the calculation is wrong if you don't have it on a piece of paper?

This all costs money.

Otherwise, you need to be paid. Now, many times you will make a small change for a good customer that takes a trivial amount of time, but this should be priced into the long term value of the customer.

If there is a problem and they need us to spend time looking into it, there is a charge for that time. If it is a problem with my workmanship than we will waive the charge.

If they insisted on a language/framework/product/etc and that is the root cause of the problem, they will pay for the fix.

This is a good example of why charging by the hour works out better.

If a potential customer wants me to do a fixed priced job that is not very straightforward to estimate, that is both a warning sign that they don't understand the consultant's position and that it might be a good idea to pass on the work.

You simply can't give unlimited post-contract support -- it's unreasonable for them to expect it and it's unreasonable for you to give it.

In a better situation, as zck said, you should have this written into your contract. Lesson learned. The next lesson is the client should not -- and you should not -- have blessed a version without having it experience production loading, as it will shake out different issues than qa.

If I were in your situation, here's what I'd do. First, no more free time. Second, you're going to have to charge for your time fixing these issues at a rate in line with what you originally charged; it's not fair to suddenly jack your rates up now that they're kind of stuck. Still, I think you can have a happy ending here as long as your client is reasonable.

You need to write them a letter and politely say that this went through acceptance testing and you're happy to support ongoing issues at $X/hour. If I were you I'd actually make $X about 2/3 of what you originally charged to make it clear that you aren't making out on this. Just be politely clear that you can't give them unlimited support for free and be very clear where your time goes when you send them billing reports. Also, some permgen errors can simply be fixed by increasing permgen and throwing ram at the problem.

Good luck, and make sure that in future contracts, you break out acceptance testing, qa, load testing, and put in a firm price for ongoing support. I like to make my ongoing support price about 4/3 of my contracted price but with the first 10 hours free. Of course larger blocks can be pre purchased at reduced prices.

Also, once a client accepts code, all changes cost -- bug fixes too. If you want to make a living you simply can't hand people blank checks to your time. Now particularly egregious bugs might get fixed for free, that's a judgement call, but be firm. Good clients will understand.

Even better, say that you will give them 20 hours more for free (at a "value of X$"), and after that support will be charged at X$. Don't discount support, or you'll be working for months/years at that discounted rate. On the opposite side, you should charge more for support than for regular work.

Reply on news.ycombinator.com