If he doesn't wanna pay for defect correction, you are just going to spend a lot more time on that before you deliver (i.e. your estimates goes up)....

Finding subtle bugs is increasingly difficult as the code quality goes up, so each bug is getting increasingly costlier to find before it hits the real world.

Even well-tested code will not be defect free unless an incredible amount of effort is spent. (We are talking orders of magnitude more than regular clients are willing to pay for). Look for the NASA study on code quality and look at their productivity to achieve that (granted, brilliant) code quality.

Personally (as an freelancer), I comp the really, really stupid oversights (and their diagnosing time)... That shit happens once in a while (and that comping buys you a lot of credibility)... but the "normal" (i.e. somewhat trickly) bugs, they client pays for them.

For new customers, I usually have a "facts of software development" talk, so that they know how and why I do stuff... (most customers appreciate the frankness and have no problem paying for bugfixes afterwards - if they do, I simply add margin to their estimate that gives me room for expected later bugfixes).

If they balk, when you say that you cannot write defect free code... ask them if they ever find typos in documents or wrong calculations in spreadsheets even after they spend "a lot" of time to make sure they were correct...

The "facts of software development" is really important, especially if the client hasn't got a lot of experience in developing products. I've always found the more experienced a client is, the easier they understand the concept.

Most clients are reasonable, but the newb ones simply don't know the realities and mechanics.

And it's when you have a different view on reality, that you get unhappy with each other...

I also tell my "newb" clients, that the first project is perhaps 50% of the total, even if it delivered on time and on spec (for bigger projects)... But the spec is always incomplete and wrong, so fixup is going to be needed, because we learn while we do the first version and the first "real deployment"...

https://hackernews.hn/item?id=7850335

In general, I would avoid selling software without a service agreement.

Bugs are a thing that happens. You will endeavor to make them happen less, because you're a competent professional. But because you're a competent professional, you know that some will happen anyway. So structure your business deals such that both you and your customer have a good answer to the problem. You shouldn't take a wash for being available, and they shouldn't be left hanging with nobody to get help from.

This gives you a tidy source of recurring revenue and an easy way to nudge up your average deal value. It gives your customers a reliable source for fixes and changes. It's good business all around.