Ask HN: client reporting bugs that don't exist, causing me hours of unpaid work
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's because other components of their system (written by other developers) are failing. And in some cases it's just user error (entering wrong username/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's not my bug, and then saying they owe me a few hundred dollars.
22 comments
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.
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.
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.
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.
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.
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.
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 :-)
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 :-)
At work when we've contracted with firms, a lot of times the agreements include a few months of paid maintenance (two or three hours per month at a reasonable rate) to cover this stuff. That way they don't disappear and leave us with bugs nor will they feel shafted by our requests to fix issues. Everyone is happy :).
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.
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.
Long-term contracts. $X a month for bug fixes. If they drop the contract, they're billed by the hour.
Recurring revenue and the client is happy: they are now able to budget their costs.
Recurring revenue and the client is happy: they are now able to budget their costs.
I feel like this is not an applicable comparison in regards to workmanship. However, if this truly is the way you want to operate, then I really see no way around simply accepting the situation the way it is now.
I can understand why you feel this way, but I don't think it applies to software as much as it would tangible goods or service.
I can understand why you feel this way, but I don't think it applies to software as much as it would tangible goods or service.
it's a nice sentiment, but it's unsustainable and it's setting bad expectations with the client. You should not be guaranteeing bug-free software, because that is impossible. The client should understand that the software will have bugs, and that your ability to continue fixing those bugs is contingent on you having a continuing source of revenue. I'm sure they'd rather pay than have you close up shop and have nobody to fix the bugs.
Also, i've noticed in my own work that people are always eager to blame problems on whatever component is the cheapest/easiest to solve. If you charge $50/hr for application support and the guy they contract to do virus scans and run disk defragger costs $40/hr, their first call will always be to him, not you, no matter where the actual problem lies. Somebody at their office has figured out that whenever a user has a problem, it's cheaper to pawn the problem off to you and let you do the triage than it is to triage it themselves before calling you. Even if you don't start charging for bug fixes, you need to start charging for wasted time.
Also, i've noticed in my own work that people are always eager to blame problems on whatever component is the cheapest/easiest to solve. If you charge $50/hr for application support and the guy they contract to do virus scans and run disk defragger costs $40/hr, their first call will always be to him, not you, no matter where the actual problem lies. Somebody at their office has figured out that whenever a user has a problem, it's cheaper to pawn the problem off to you and let you do the triage than it is to triage it themselves before calling you. Even if you don't start charging for bug fixes, you need to start charging for wasted time.
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.
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.
"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.
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.
> 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
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
i charge for phone calls, travel, bugs that are my fault, bugs that are not and everything else. Basically, if i can't bill another client for the time then i am occupied and must bill. i do not have contracts or recurring revenue to lean on and it sounds like you don't either. look at it this way, its unethical to your boss to not bill for time. Your boss may be you in this instance but you need to act like it isn't and the answers to these questions will be a lot easier to answer.
That's insanity. Everyone expects bugs. Saying you'll fix bugs for free is saying your time isn't valuable.
Something to consider: if you're billing by the hour, your clients aren't paying for a product, they're paying for you. Would you expect a company that hired you for a salary to dock your wages for time spent bug-fixing?
Make it entirely clear and transparent what you're working on, including time spent bugfixing, and if they're unhappy they can take their business elsewhere.
This of course puts great incentive on you to write high-quality code, because your failings in that area will be visible as bugs to the client.
Make it entirely clear and transparent what you're working on, including time spent bugfixing, and if they're unhappy they can take their business elsewhere.
This of course puts great incentive on you to write high-quality code, because your failings in that area will be visible as bugs to the client.
This is how I consider it and try to phrase it to my clients. They buy my time. If they waste a lot of it with meetings and false starts, at the end of the day it's their responsibility to use my time wisely. That being said, it's my responsibility to make sure my time is of great value to them and produce quality work.
I have a question: if bug fixes shouldn't be free, then why are clients able to take freelancers to court under lost revenue due to "errors and omissions"? I used to think that bugs could/should be billed until I had to deal with a horrible client that threatened litigation under E&O and breach of contract. Going to court would put me into debt, so I really felt screwed into working for free.
Super bitter about it and thinking about giving up on self-employment altogether because of that guy.
Super bitter about it and thinking about giving up on self-employment altogether because of that guy.
My first ever client did that to me, many years ago. Fun aspects of that engagement included:
- I ignored a great big warning sign up-front ("our previous developer abandoned the project, refusing to work with us again")
- I offered fixed-price (a horrible mistake for a variety of reasons, including that it was explicitly a 'learning project' for all of us)
- I didn't mitigate scope creep ("I know we said we'd hire a designer, but can you style the UI as well?")
- when we ran into obvious deadline and quality issues, I should have fixed it by re-evaluating things with the client; instead, I tried to "work harder"
- finally, when everything went south and the client refused to pay (and in fact demanded their deposit back!) I didn't take them to court for the money they owed me
All in all it was a horrible engagement for everyone involved, but a great learning experience for me at least. I hope the clients (quite reasonable people I think, just as domain-clueless as I was at the time) learned from it too.
Don't give up though. I continued contracting, and used those experiences to build a simple set of practices that made future engagements a lot more pleasant and productive for everyone involved. One of these is to be super-explicit up-front about how bugs are tracked, resolved and billed.
Something to consider: as a software professional, part of your job is to help your clients learn how to engage software professionals. Many clients are either new to the field, try to bring odd expectations from other fields into it, or have been burned by bad engagements in the past and are 100% in CYA mode. Help them get past that :)
- I ignored a great big warning sign up-front ("our previous developer abandoned the project, refusing to work with us again")
- I offered fixed-price (a horrible mistake for a variety of reasons, including that it was explicitly a 'learning project' for all of us)
- I didn't mitigate scope creep ("I know we said we'd hire a designer, but can you style the UI as well?")
- when we ran into obvious deadline and quality issues, I should have fixed it by re-evaluating things with the client; instead, I tried to "work harder"
- finally, when everything went south and the client refused to pay (and in fact demanded their deposit back!) I didn't take them to court for the money they owed me
All in all it was a horrible engagement for everyone involved, but a great learning experience for me at least. I hope the clients (quite reasonable people I think, just as domain-clueless as I was at the time) learned from it too.
Don't give up though. I continued contracting, and used those experiences to build a simple set of practices that made future engagements a lot more pleasant and productive for everyone involved. One of these is to be super-explicit up-front about how bugs are tracked, resolved and billed.
Something to consider: as a software professional, part of your job is to help your clients learn how to engage software professionals. Many clients are either new to the field, try to bring odd expectations from other fields into it, or have been burned by bad engagements in the past and are 100% in CYA mode. Help them get past that :)
WOW. This is word for word exactly what happened to me. The worst part is that I KNEW better than to accept this guy as a client, but I was so excited to get a client and get a deposit check that I convinced myself that I could blast through the project.
Well, if it's any consolation, if you use that as a conscious learning experience, you'll come out of it a far more effective contractor than you went in. I didn't let it discourage me, and I benefited from it in the long run.
Another suggestion: do a thorough post-mortem with each client. Go over what you did, what you learned, what you'd improve and so forth. I.e. not a retrospective of the work you did (which is also important and worth doing), but a retrospective of your business relationship with your client.
Another suggestion: do a thorough post-mortem with each client. Go over what you did, what you learned, what you'd improve and so forth. I.e. not a retrospective of the work you did (which is also important and worth doing), but a retrospective of your business relationship with your client.
I think it's happened to everyone in this business.
Yep. Me too. It's funny how common this story is...
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?
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?
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.
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.
Didn't think on that, thank you
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.
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.
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.
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.
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.
^^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 :)
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 :)
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..
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..
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.
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.
"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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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
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
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).
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.
Nothing free at that point.