The point of TDD from a business perspective is really not so much reducing bug-fixing time. You do reduce the maintenance effort, but you spend more time fixing defects while you write the code in the first place, because you never get things entirely correct on the first try (if you could, you wouldn't testing at all). Sometimes one effect predominates, sometimes the other.
However, TDD is still worthwhile because shifting effort upfront makes your process cheaper. The earlier you catch an error, the cheaper it is to fix. It you catch it while it's in your head, you haven't wasted time writing it. If you catch it before you check in, you don't waste time reverting the commit. If you catch it before QA gets their hands on it, you haven't wasted their time. (If you don't catch it until it's live with a customer, fixing it becomes horrifically expensive because you've wasted their time, the time of the support staff, and your own time that could have been used for improving the code base.)
In my opinion, test-driven workflows don't so much reduce errors as shift the occurrence of errors from more expensive to less expensive places in the development process. And that has enough business value to justify turning your way of doing things around.