I like the idea of TDD, but I rarely use it. The problem is that TDD works well when you already know what you're going to build and how, that way figuring out

I like the idea of TDD, but I rarely use it. The problem is that TDD works well when you already know what you're going to build and how, that way figuring out how to put new code under test isn't too onerous. If the company is paying you for it, absolutely take the extra time to TDD, and do your best to maintain the test base. That's what they're paying you for. If you're greenfielding a side project, TDD is only going to slow you down. Time spent learning your domain will get redirected to "figuring out how to put X under test", significantly increasing time-to-market. Get your product to market, find product-market fit, and get some resources to re-engineer your product with, and don't do it yourself because you'll have more important things on your plate. If you're early in your career, spend some time to learn TDD. Don't do it on your own projects, let someone else pay you to work it out. Don't actually use it unless someone's paying you to, but learn how it works, what it buys you, and what it costs.