You need to choose a working methodology that compliments how the work is done and also helps address pain points. Unless you're showing your clients how you work and using that work process as a selling point to build confidence, you probably don't want to be picking trendy styles of working over what's most appropriate.
All this isn't to say don't use TDD, it sounds like perhaps it's not beneficial to your team. How confident are you in that decision? Perhaps you don't have many defects, but will your product roadmap lead you to complexity that will have them in the future, necessitating better processes later? Processes take time to mature, so maybe now is the time to prepare? Maybe you have very few defects now, but are they expensive or cheap to resolve? I would be considering these questions and looking at TDDs strengths and considering whether it's able to help me.
Additionally, you mention end-to-end testing. So are you validating work by manual tests rather than code tests? How much time are these manual tests taking? How much can you offload to unit tests? Will unit tests offer certainty that manual testing does not? One other thing I can say from experience is that manual testing doesn't scale. Will that be a problem for you?