I'd say add them in after you have enough to pay one person full-time.
We wrote tests for PlaytestCloud only after we acquired the first paying customers.
The tests only ensured that customer-facing routes would not crash. It was a good balance to ensure that we could move quickly while ensuring that we didn't introduce catastrophic bugs.
A lot of thought leaders have been promoting testing like crazy the last couple of years, with the result that some people treat it like it's essential, when it rarely is.
If the person in charge is the stereotypical "business type", then it can be difficult/impossible to convince him/her to allow engineers to spend time doing a refactor and/or writing tests for code which was written months ago and is "working fine" because you now are showing some traction. This can easily lead to never actually getting around to writing that robust and practical test suite that is really necessary in the long term. Note that I also say the test suite should be practical (for some definition of practical which may vary from engineer to engineer). For example, 100% test coverage may not be useful, determine which parts of the code MUST be tested and which parts are just diminishing returns, etc, etc.
What I've done on a couple of occasions was to tell the nontechnical stakeholders that automated tests must be added before the web app framework (or whatever significant dependency) could be upgraded. In the context of such an upgrade, they could understand the benefit of a test suite, and they signed off on it.
- mission critical code
- before refactoring
- people working on a codebase they don't understand completely (changing X might break Y)
- implementing complicated algorithms