The size of a project should make no difference whatsoever when doing test driven development. The point of unit testing is that you are testing isolated units of functionality completely independently of other areas of the code.
This is achieved by using mocks to fake out the expected behavior of other parts of the program. This can be most easily achieved by always coding against interfaces instead of concrete types.
For example, say you have two classes ClassA and ClassB. ClassA calls ClassB, but you want to test ClassA independently as it is a separate unit from ClassB. Instead of directly referencing ClassB from within ClassA, you instead make ClassB implement interface IClassB. Then when writing unit tests for ClassA, you simply mock the behavior of methods on IClassB. You may then proceed to write isolated unit tests for ClassB.
This process can be facilitated with the use of dependency injection which allows the intended concrete type to be decided at application runtime.
Taking this approach, you are only ever testing each individual part of the system in isolation, so it makes no difference whatsoever where you begin. This is pretty much the definition of unit testing.
What is probably more important at the start of the project is to pick a mocking framework and a dependency injection framework to allow you to work this way. There will be a variety available for whichever language you are working in.
The act of testing multiple tiers of the software at the same time is called Integration Testing. These tests cannot reasonably be expected to be fully written before all the parts of the system are at least in place (if not fully).