

Ask HN: Do you think its fair to charge for fixing bugs? - jaredbo

Putting myself in the client&#x27;s position, why should I have to pay for some stupid mistake the developer made..? Not only do I have to pay for it, I also have to waste my time logging a ticket with a whole lot of detailed information. And THEN, I have to prioritize it over some other functionality that was already planned for the sprint..
======
svennek
Sure, the client is always paying for it anyways...

If he doesn't wanna pay for defect correction, you are just going to spend a
lot more time on that before you deliver (i.e. your estimates goes up)....

Finding subtle bugs is increasingly difficult as the code quality goes up, so
each bug is getting increasingly costlier to find before it hits the real
world.

Even well-tested code will not be defect free unless an incredible amount of
effort is spent. (We are talking orders of magnitude more than regular clients
are willing to pay for). Look for the NASA study on code quality and look at
their productivity to achieve that (granted, brilliant) code quality.

Personally (as an freelancer), I comp the really, really stupid oversights
(and their diagnosing time)... That shit happens once in a while (and that
comping buys you a lot of credibility)... but the "normal" (i.e. somewhat
trickly) bugs, they client pays for them.

For new customers, I usually have a "facts of software development" talk, so
that they know how and why I do stuff... (most customers appreciate the
frankness and have no problem paying for bugfixes afterwards - if they do, I
simply add margin to their estimate that gives me room for expected later
bugfixes).

If they balk, when you say that you cannot write defect free code... ask them
if they ever find typos in documents or wrong calculations in spreadsheets
even after they spend "a lot" of time to make sure they were correct...

~~~
jaredbo
I usually use the "car warranty" analogy. That "free" 3 year service plan is
not free. It's just built into the price. We're just more transparent, that's
all. I like you're "typo" example as well.

The "facts of software development" is really important, especially if the
client hasn't got a lot of experience in developing products. I've always
found the more experienced a client is, the easier they understand the
concept.

~~~
svennek
Yeah, I try to only take clients that have been in the game for a few years -
or really go heavy on the "facts" speak...

Most clients are reasonable, but the newb ones simply don't know the realities
and mechanics.

And it's when you have a different view on reality, that you get unhappy with
each other...

I also tell my "newb" clients, that the first project is perhaps 50% of the
total, even if it delivered on time and on spec (for bigger projects)... But
the spec is always incomplete and wrong, so fixup is going to be needed,
because we learn while we do the first version and the first "real
deployment"...

------
cat9
This is a good reference implementation.

[https://news.ycombinator.com/item?id=7850335](https://news.ycombinator.com/item?id=7850335)

In general, I would avoid selling software without a service agreement.

Bugs are a thing that happens. You will endeavor to make them happen less,
because you're a competent professional. But because you're a competent
professional, you know that some will happen anyway. So structure your
business deals such that both you and your customer have a good answer to the
problem. You shouldn't take a wash for being available, and they shouldn't be
left hanging with nobody to get help from.

This gives you a tidy source of recurring revenue and an easy way to nudge up
your average deal value. It gives your customers a reliable source for fixes
and changes. It's good business all around.

------
jonkiddy
If you are doing freelance work, you could roll maintenance development/fixes
into an ongoing support contract which includes a SLA and monthly fees.

