March 13, 2017
“How do you define what’s a bug?”
A couple days ago, I shared 4 types of guarantees that you could offer to your clients.
In terms of generating follow-up questions, #4 was head-and-shoulders above the rest.
Here it is again for reference:
#4. For a software project, you might offer a “bug-free” guarantee, like: “If at any point in the future a bug is discovered in the code, just let us know and we will fix it free of charge.”
This one freaked all y’all out 😀
I got many questions that essentially all boiled down to:
“But how would you define what is and what isn’t a bug?!”
Or maybe more to the point:
“But what if a bug is not my fault?!”
In most cases, I wouldn’t try to distinguish between bugs that were my fault vs not my fault.
I’d just fix all bugs regardless of cause.
Now I hear you wondering:
Q: How do you not go out of business?
A: Because I charge far more than the going rate. (You could fix a lot of bugs for free if you were charging double your normal rate for a project, right?)
Q: How can you charge far more the going rate?
A: Because I offer an amazing amount of peace of mind which dramatically differentiates me from my competitors.
Additional bonuses that come with fixing bugs that weren’t your fault:
- It keeps the client relationship robust in the valley between projects.
- It deepens your expertise, which means fewer bugs in future projects.
- It encourages you to write more modular, debuggable code.
Things you can do to make sure the client doesn’t abuse the guarantee:
- Only offer unconditional bug fix guarantees to reasonable clients who you love working with.
- Put a time limit on the guarantee, like “unlimited bug fixes for six months after launch”
- Don’t fix everything immediately. Batch the fixes into convenient areas of downtime in your schedule.
Please reply with more follow-up questions if you have them. I’d like to refine this line of thinking to the point where it doesn’t scare the bejeebus out of people anymore 😀
Thanks!
—J