The problem you may quickly hit is that in order to test a particular piece of code, you should make testable the code surrounding it. Changing the surrounding code requires testing as well, which, in turn, requires even more changes.
Practical example. A year ago, I had to work on a... let's call it legacy system. Millions of lines of C# code. Maintainability index (MI) reaching sometimes zero (hint for those who never used MI in Visual Studio: going below the MI of 50 is quite difficult: you really have to start writing spaghetti code on purpose). Methods containing up to 4 000 LOC of procedural code. And obviously zero tests, because, frankly, everybody knows writing and maintaining tests costs money.
Since adding the most basic feature was causing hours or days of wasted time (plus time wasted resolving bugs discovered later in production, then days fixing the bugs introduced when resolving the previous bugs), I was thinking about adding at least a bit of testing.
When I left a project, there were indeed a few hundred tests. Those tests were covering the parts of the code which I put in separate classes and which were independent enough from the remaining code base. This is easy enough to do, but also not very useful. Yes, those tests covered some business rules, but their scope was very limited.
I was also thinking about adding more substantial testing, but unsuccessfully.
The major problem was that nearly every piece of code was relying on the database. I tried, on paper, to abstract the database in order to be able to replace parts of it by mocks and stubs. On paper, it worked, but it would require a tremendous amount of time to actually implement.
Another problem, obviously, was the spaghetti aspect of the code. How would you unit test a 4 000 LOC method which needs 16 parameters to be passed to, given that those parameters are not documented (and nobody really knows how some of them should they be used), and trying to replace them by stubs causes weird bugs in weird locations?
So yes, you can introduce tests, including test driven development, on the parts which are being changed, but if the code base is a mess, the scope of those tests will be too small for them to be particularly useful.
What I can personally suggest is to start refactoring modules one by one (hopefully they are interacting through interfaces and are independent enough from each other otherwise), and ensuring those modules have tests. Once you have sufficient code coverage, you'll notice that testing new features is much easier.