October 28, 2024

Support Contract vs Bug-Fix Guarantee

Let’s say Alice does a $10k custom website build for Bob.

Once the site launches and everyone is happy, Alice offers Bob a $300/mo month support contract under which she’ll fix any bugs.

Think about this.

Alice now benefits if there are bugs in her code.

If there aren’t any bugs, Bob’s not going to want to keep paying her $300 per month.

Perversely, Alice might have even subconsciously lowered her QA standards during the project, knowing that she’d be paid to fix things later.

Let’s say bugs start cropping up, and Alice fixes them under the terms of the support contract.

Bob will perhaps be satisfied that Alice is keeping up her end of the bargain regarding support. But what’s he going to think about Alice’s level of quality for the initial build?

If bugs keep cropping up, it’s good for Alice (because it decreases the chance of Bob canceling the support contract), but Bob could easily start to feel like he’s being nickel and dimed.

You can imagine a thought like this crossing his mind:

“We have a brand new website - why is it so buggy?!”

Now, imagine a different scenario...

Instead of Alice charging $10,000 for the build and then $3,600 (paid monthly) for 12 months of support, she charged $13,600 for the build and included a 12-month unconditional bug-fix guarantee.

With the guarantee approach, Alice is incentivized to have zero bugs.

The perverse incentive of the support contract disappears.

Bob is happier because he doesn’t have to make an economic decision every month (and, of course, because there are fewer bugs annoying the prospects and customers on his website).

In all likelihood, Alice could charge a premium for the project (say, $25,000) because, unlike any of her competitors, she stands behind her work with an unconditional guarantee.

This would mean that she would be charging more for doing less AND making her client happier in the process.

Sounds like a no-brainer to me.

Yours,

—J