Why doesn't everybody?
Great question!
We asked ourselves the same thing. Obviously, people are going to call BS on us. How can we prove it? Or at least, how can we instill trust?
Don't get fancy. Just put real skin in the game.
If we're so confident that the code and software we deliver is of exceptional quality, then it's low risk to us to guarantee free bug fixes on the code and systems we deliver. And on the other side, if we make such a guarantee, it provides an additional strong incentive to us to deliver exceptionally high quality code.
We like aligning our incentives with our goals and with our clients' goals.
"You can't just offer free bug fixes forever! We absolutely must nail down, in no uncertain terms, what 'bug' means and set realistic boundaries around 'forever'—technology changes faster than you can blink! I can't stress this enough: clarify these details with your clients like our business depends on it...because, frankly, it does."
Our totally real lawyer quote makes some good points...
But we're not too worried about it.
What constitutes a bug is defined in our contracts as best we can, but we aren't legalistic about it, either. Integrity is one of our core values, which calls for simply "doing the right thing". If something is clearly a bug, we want to fix it for free. If it's probably a bug and our client thinks it's clearly a bug, we want to fix it for free. If it's clearly not a bug, but rather a gap in requirements that other dev shops wouldn't say "yeah, probably a bug", we'll work with our clients to figure out what needs done next.
Additionally, not all of our clients nor all projects with each client fit under this umbrella, contractually, though this practice still bleeds into what we do generally to a large extent. Some clients and projects, though, prefer to prioritize other areas than free bug fixes, so we don't force this on everyone.
But honestly, our clients spend a lot of money on custom software. Their software should just work. If it doesn't, and it's something that we should have caught, our integrity calls us to fix it.
It's a risk on our side. A big risk. But if we're trusted to build the software the right way, then it's our responsibility to build it the right way.
Which brings up a good final point...
This only works with honest partners and bi-directional trust.
Sometimes it's impossible to list all requirements explicitly, so we then fall back on integrity to determine if a particular functionality is indeed a bug (something that we should have caught, being the careful professional craftsmen that we are), or if it's a new requirement that we need to discuss.