

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

TL;DR: do you charge for ongoing support for completed freelance work?<p>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.<p>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.<p>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.<p>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).<p>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 <i>always</i> 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.
======
zck
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."

~~~
throwaway_today
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.

------
mcotton
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).

~~~
throwaway_today
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.

~~~
ebiester
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.

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

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

~~~
petervandijck
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.

