This makes sense but I've never been taken to task for hours and many of my clients charge me out to their end clients for hours I submit.
The other advantage is that hourly tracking gives me data to predict better what new features of similar complexity will cost. Certainly not an amateur capability.
You're free to do your own internal projections about the number of hours your features will take. Simply round them up to the nearest whole number of days, and present that to your customer.
Hourly estimating takes too much time and it never gives useful numbers even with various padding schemes when estimating innovative sw development. Cookie cutter web sites or repetitive work that you've done for multiple clients is easy to fix bid but I don't do that sort of work.
I just say this has a complexity of 1,3,5,8 or 'too big to say'. Each feature is a 1-15 minute conversation to get this number. Then they ask well how much time is that? I then answer "We have three months of velocity data, x points per developer per week accepted into production over the last ten weeks so those five new points for that feature will take one developer 4.1 days to complete with a variance of plus or minus 1.8 days. If you need better precision, we can take a day or two to really break down the work and get the uncertainty to at best a ten percent variance.
Didn't feel like a debate, just trying to increase understanding on both sides. If you follow what I'm saying, I don't ever try to estimate hours anymore, I just use past data on complexity and then translate that to hours if ever required. There's very little time and stress, and effort for estimating. It's incredibly accurate over several features too and it is easy for stakeholders to decide cost vs value of each feature.
The other advantage is that hourly tracking gives me data to predict better what new features of similar complexity will cost. Certainly not an amateur capability.