
Ask HN: client reporting bugs that don't exist, causing me hours of unpaid work - logn
I do freelance work and offer my clients bug fixes for free (for defects in the software I wrote, that they already paid for). I have a client who for several weeks has been sending me long lists of bugs they find in my software. But for every single issue so far it&#x27;s because other components of their system (written by other developers) are failing. And in some cases it&#x27;s just user error (entering wrong username&#x2F;password). Should I just accept that I spend hours at no charge addressing their concerns? I would feel bad sending back an answer that it&#x27;s not my bug, and then saying they owe me a few hundred dollars.
======
wpietri
Personally, I wouldn't offer free fixes on anything I didn't write entirely by
myself. And I would only do it if there were sufficient scope and flexibility
for me to include all my quality-oriented practices (unit testing, pair
programming, good logging, incremental deployment, etc). So in the future, I
think my answer is, "Don't do that."

But that's the future. For now, you made an offer. I'd honor it for the
current list, and then send them a note saying, in fancier language, "Hey,
I've spent 8 hours running down issues that turned out to not be my bugs. I am
happy to stand behind my work, but I can't afford to do that for other
people's code. If you folks would like a support contract for your system, I'm
glad to do that at $XXX per hour with a monthly retainer of $YYYY. I'm still
glad to fix any bugs in my code for free, but in the future, time spent on
issues that aren't caused by a bug in my code will be billed at my normal
rate, $ZZZ per hour with a 1-hour minimum per incident."

Most clients are great, but few think through the economics of freelance
software development. And some people are just greedy. The best thing I even
learned about client pricing was to structure deals so that no matter what
happened, I was ok with the outcome.

------
ashearer
You could clarify "bug fixes are free" by saying:

1\. You offer support (problem analysis) for $X per hour.

2\. If analysis reveals a bug in your software, you will fully refund the
support cost and offer the fix for free.

~~~
film42
This is an interesting idea, as it weeds out clients who are banking on you
doing some free work.

Still, the "free bug support" idea is a really powerful selling point, as it
show confidence. Perhaps offer 2 or 3-months of "free bug fixes" with a
flexible ending date so you can't ride out the clock. After which, @ashearer's
suggestion could kick in.

------
duncan_bayne
Stop offering bug fixes for free. Software development entails bugs; it's
unreasonable to expect that bug fixing will be free of charge. If you're
selling pre-packaged software with a warranty that may not be true, but if
you're billing by the hour you're crazy not to bill for _all_ your time.

Start tracking bug reports carefully. Log all the details of the report,
investigation, and resolution. Make these available to your client where
possible.

Also, consider that inadvertent misuse of software may constitute a UX defect
:-)

~~~
logn
It's not pre-packaged (100% custom).

I don't know, I feel like if you build something, and it's defective, that you
should fix it free. I would expect the same from a car mechanic. I get that
software is a hard thing and bugs are inevitable. I'm curious what other
people do.

~~~
drewcrawford
There are a variety of better deal structures available to you.

One is to cap your hours/cost. Just build in 40 hours (or whatever) of bug
fixing for the first month into the price. Line item it, so the customer knows
what he's getting and what it costs. Often customers will complain about this
cost, and say they'd rather pay a la carte. Bingo. But if they don't, you have
now set clear expectations about what is being provided.

Another is to make bug reports consumable. For reference, Apple has a bug fix
consumable called a DTS Incident where you pay in advance to have N bugs
investigated. Something you may want to consider if the bugs are all invalid
is requiring somebody to pay to file a report, and if it turns out valid you
refund their money. This may lead to more disputes though it's unclear if
disputes are a problem in your situation. In that case you may want 2 hours of
your time no refundable for every report.

The third thing is technical, and it works even if you don't have a good
contract in place. Become omniscient. Log really detailed, invasive things and
phone them home. Every user action, all the user's data, etc. Then when the
bug comes in you cross-check against the logs and can verify quickly. "No you
pressed the delete button, that's why you don't have any data. Not because a
bug in the app destroyed it." Make it clear that you are doing this and make
it clear that you will disable it, but disabling it voids the warranty.

~~~
greenyoda
_" Log really detailed, invasive things and phone them home. Every user
action, all the user's data, etc."_

Having all their business data logged doesn't sound like a condition that any
reasonable customer should agree to. In some cases, such as healthcare related
data covered under HIPAA, it would be outright illegal. Asking for this kind
of arrangement tells your customer that you don't understand the importance of
confidentiality and security, and also tells them that you think they're so
stupid that they don't know the difference between a bug and a user error. If
a contractor suggested this condition to me, I'd show them the door
immediately.

You'd also be taking on a serious risk. Even if it was legal for you to have
the data, it could open you to legal liability if through some error of yours
the data was compromised, costing the client money. And if you had possession
of the data, you might get blamed even if the data leak wasn't your fault.

Even if you logged the data on the customer's own machines, bad things might
still happen, like a bug in your logging code logging confidential data in
plain text when it was supposed to be encrypted. It could then fall into the
hands of an employee who wasn't authorized to see it.

~~~
drewcrawford
> Having all their business data logged doesn't sound like a condition that
> any reasonable customer should agree to.

Any business that uses SaaS or externally-hosted software agrees to this. The
question is whether your vendor has a reasonable access policy for that data,
and what "reasonable" means hinges a lot on your vertical and the kind of data
you're storing. PCI is a completely different ballgame than button clicks for
example.

Increasingly, plenty of non-SaaS products work this way (e.g. Tesla cars,
OnStar, your iPhone, apps in the Windows Store, etc.) Again the question isn't
so much about "whether" to collect usage and bug reporting data, it's about
getting the defaults right and educating concerned users to tweak them to a
level where they are more comfortable.

> also tells them that you think they're so stupid that they don't know the
> difference between a bug and a user error

This is literally the case that OP came to us to solve

------
jorgeleo
I have been doing consulting for years now, and this is my policy.

Invoices unpaid for more than 30 days, get a 10% late fee. Late for more than
60 days, no more work of any kind untill all invoices are paid.i work to make
a living and expecting prompt payment is reasonable, not a favor

After last invoice paid, 30 days of free bug fixes. After that, the client had
enoug time to report any problems, so anything else is goes into maintenaince
fee.

If a potential client does not agree with this terms, then it will be a client
that is more expensive than what i can afford, so i reject the work and move
on. Specially the manipulative ones that try to guilt trip into fixing for
free whatever they want, i don't need those.

So te question is, are you into freelancing to make money or to do favors?

~~~
curiousbiped
Back when I did IT consulting, I got better returns by bumping up the base
rate and offering them 20% discount if they paid on the day the work was done,
15% if within 7 days, and and 10% if within 14 days.

Some customers will whine and moan about late fees and try to weasel out even
if they're in the contract, but if you offer discounts for quicker payment,
suddenly they're running after you to pay right away. At least in my
experience.

~~~
jorgeleo
Didn't think on that, thank you

------
gkoberger
This should be built into your hourly rate. An hourly rate needs to not just
cover billable hours (aka time programming), but also bug fixes, customer
support, etc.

This is the reason (among others, such as lack of benefits) that hourly rates
as a consultant/freelancer are so much higher than that of an employee.

That being said, if you do fixes like this for free, they'll bug you (hey,
it's free -- why not?) rather than spending half a second figuring it out
themselves.

------
meshko
I agree that promising any bug fix for free is silly and not necessary. If you
want to demonstrate good will, you can at your own discretion not charge them
for your moronic bugs, the ones where you go "oh fuck this is embarrassing"
when you figure it out. So their expectation will be set at paying for your
work hourly, but once in a while you will waive the fee. I think people will
appreciate it more.

------
neltnerb
This is probably not the answer you'll like, but if you're really only talking
about literally (only) hours of unpaid work, I'd suggest you just do it and
chalk it up to "customer service" and hope that you're commitment to helping
them even when it's not your problem will get you a good reputation for future
work.

I've seen this sort of thing too, and while it's frustrating when my code is
blamed for user error or other people not reading the API I give them, I feel
like it's more trouble than it's worth to stress out about it. Just give it a
low priority, and do it when you have some down time in the interest of
keeping future potential customers happy.

Granted, I'm not some pro freelancer, but doing this has let me cultivate many
long term positive relationships, learn new skills on someone else's dime, and
get new work with (potentially better) clients based on the recommendation.

~~~
jonnyscholes
^^Solid advice. The only thing I might add is to record these hours somewhere
and then in your future quotes include a portion of time called maintenance,
bug fixes, testing or something similar that accounts for these unforeseeable
problems. Some clients will use more than the allotted time, some less. Over
time it will average out.

You may have to explain to them why code \might\ need bug fixes etc but that
generally leads to the client having a better overall understanding of the
work required which never hurts :)

------
sekasi
Very common solution to this is following:

Offer a 90 day code warranty period. Over those 90 days you'll fix (For free)
defects in your application.

However, wild goose-chases like you're mentioning above will result in an
invoice. Only problems originating from YOUR code will be covered.

IE: You spend 2 hours finding the issue they mentioned.

1) Problem exists in your code. a) You fix it, and you don't invoice them.

2) Problem is in another part of the system a) You invoice for the time spent.

This is by far the most far and reasonable way to look at this problem I
reckon..

------
facorreia
Well, bug fixes may be covered by your warranty, but the work you described is
not bug fixing. I believe you should send them an invoice detailing the work
you've done, the assessment for each instance, and charge them for the hours
you worked on that.

------
kevinpet
A friend sold some custom highly specialized software back in the day. He said
his secret was whenever a client reported a bug, make them do some work before
addressing it. Something as simple as including a log file will weed out the
ones who are simply looking for the easiest people to fob something off onto.

------
Mc_Big_G
_" offer my clients bug fixes for free"_

You should stop doing this. The way to fix it is to use a project manager like
pivotal tracker that allows the client to "accept" a feature. Then, in your
contract, it states that the client must test features and that you are not
responsible for bugs after acceptance.

Bugs in software happen. If you write tests, they happen less. All projects
should expect some amount of bugs and these should be paid for as any other
normal development work.

Theoretically, an immoral dev could take advantage of this and create a lot of
bugs but they wouldn't be in business long, so they disappear. A bad dev who
honestly creates too many bugs suffers the same fate.

Get paid for your work. Period.

------
zephyrfalcon
The problem is that it's free. Whenever the client has a problem of any kind
with their software, this allows them to toss it at you immediately, at no
cost to them whatsoever. Charging a fee, even if it isn't a very high fee,
would probably make them think twice about doing this... it would encourage
them to look at their problem for a few minutes at least, to see if they can't
solve it themselves, before they decide it to hand it over to you and incur
costs.

------
jws
Been there. At one point we made a pretty spiffy network appliance that
included free support. (On the theory that it was also rock solid, so there
wouldn't be any.) Cisco would charge you out the nose for support. We got a
lot of experience helping a multibillion dollar customer out with their Cisco
routers once they figured out that if part of their network was so broken even
our devices wouldn't perform well, we would come in and support them.

------
wikwocket
_> I would feel bad sending back an answer that it's not my bug, and then
saying they owe me a few hundred dollars._

Why? If I take my laptop into the shop, and after 2 hours of work they
determine it's because I spilled coffee into the USB ports, don't you think
they're going to charge me for the evaluation, let alone the repair?

There are types of business that can offer free support, even of problems not
related to their product. A 1-person freelancer is not that type of business.

There's lots of great suggestions in this thread for getting your time paid
for. These have the dual advantages of earning you more money, and ensuring
you get better, more savvy customers. This is because the ones who understand
the value of support and care about long-term success instead of penny-
pinching will self-select themselves as part of your contract negotiation
process.

------
ianstallings
Don't feel bad, they owe you. They can always try to negotiate. In fact I
would say they _always_ try to negotiate on charges like this, but stick to
your guns. If they won't pay for a few hours of work then it's going to be a
red flag for all other work anyway. Just my experience.

------
josephlord
Have you spoken to them rather than just sending emails with bug lists
backwards and forwards? I find it can sometimes resolve issues and
misunderstandings much quicker.

I would speak to them and explain that the issues investigated so far are out
of scope, why and how they can identify for future issues. Let them know that
you will need to bill for time on out of scope work but that you will waive
the fees to this point as a goodwill gesture (let them know the time/cost of
time spent so far). Send them the list of bugs with you findings so far with
an invoice totalling zero after discount and ask them to let you know which
issues they still want you to investigate.

Is there further business that you could offer them in fixing or replacing the
other (broken) components.

------
woah
Hahaha I hate to laugh, but the only reason these are sent to you is that you
are probably the only developer in the chain who offers to work for free. This
is software, stuff breaks all the time for millions of reasons. Never work
without being paid.

------
zhte415
Define a clear service level agreement. List all the errors they have pointed
out so far, do not seem like you are shirking responsibility, and in this
(likely spreadsheet format) list the corrective action needed.

Meet them, too. For a coffee, tea, beer, whatever. I say this because by
accepting and taking responsibility for what you have created, it is likely
the developers of other components have included no support / feedback
channel. This is both a risk and opportunity: the opportunity is an on-going
chance to bill for services or future development; the risk is being seen as
blaming others for your mistakes.

------
ebbv
This is why you don't offer unlimited free support. You should have a limited
time frame for them to find bugs for you to fix for free, say 30, 60 or 90
days after delivery. Beyond that they need to pay for support.

------
tritium
If you decide to spend 12 hours a day, 5 days a week, parked in the parking
lot of a gas station, revving your car's engine to redline, is the gas station
going to feel guilty about charging you for all that gas?

------
gdewilde
Scotty from startrek explains that if it is 1 hour work you have to say it is
2 hours or else they will never see you as a miracle worker.

------
pm24601
Your software is buggy. It is choking on bad input.

Modify your software so that issues caused by outside systems or user input
errors are loudly and clearly announced as being externally caused.

Until this if your software fails, its your bug even if it is caused by bad
input.

Even though the

~~~
logn
It's not that problem. It's problems like them re-designing their database
with new schemas, new constraints on fields, and new column names, and them
wondering why their webapp forms report errors upon submission. And after my
explanation, they have the DBA work around it (rather than pay me to update
the forms). Or, they enter the wrong username/password (and get an error
message saying wrong/unknown username/password).

~~~
pm24601
You didn't indicate that they were changing the environment like that. You
just said "bad user input". But for them to mess with the db constraints and
database in general - my response would be: this is a whole new project.

Nothing free at that point.

