Yes, this is a clickbait title. Now that I’ve got your attention, I’m going to tell you a story about how I’ve written tests in startups.

TL;DR: when you’re a startup, you have pressing deadlines to deliver features to make all kinds of stakeholders happy, incl. investors, users, etc. you’re basically fighting for your life. You have no time, no people, and no money to implement everything you ever want or even need to keep yourself afloat. So skip the tests at first until you have to touch this feature again, and do the tests before you build on top of it.

Writing tests, whether it’s unit, integration, e2e or visual, takes a LOT of time, especially if you have no processes set up.

At my current job, oftentimes, I spend about 70% time writing tests and only up to 30% doing features. But that's because we have a quite “established” code base, really complicated business logic, and since new features go on top of already existing ones, we need to be careful not to mess up the existing functionality.

And that leads me to my main point.

If you have a really new codebase, e.g. you're doing MVP, and you’re only building features for the first time - DON'T WRITE TESTS. Once you build the feature - release. Show it to your users. Maybe the feature you’ve built is useless, no one needs it, and you need to scrap it. You just saved yourself time on writing tests right there.

Once you release, the feature, users like it and you need to start improving it (read "just change a bit") - don’t write tests. Still. Improve it, make it better, release it again, and verify.

Once it’s done, and you need to move on and build something else ON TOP of that feature, then do the tests first for that already released feature, and only then build a new feature. And you guessed it - WITHOUT tests for the new one as well.

This way you’re always releasing, you look alive, and you’re being a startup, not an inflexible bureaucratic, over-engineering and try-to-predict-it-all enterprise with tons of processes.

Obviously, this is just a) my opinion and how I personally approach new features in startups, and b) a generalisation.

For example, if one of the things you’re implementing is a CORE feature that everyone definitely needs (like a certain API or something), and it’s essentially the founding reason for your startup, then do the tests right away, and only then do the rest of the new features. Because in this case, YOU KNOW that you'd rarely need to change it and you need it to be reliable and always functioning correctly.