What's absolutely necessary to get anything done in a large mature project with many developers and a sprawling code base may be cumbersome in a small single-developer project.
In a small project where bugs are easy to identify and tend to be an easy 10 minutes fix, foregoing the correctness tax and fixing bugs as they become apparent is the more economic choice.
So I do think the "always test" mentality is a reasonable default for the non-prototype type of work. There's a tipping point where going on without testing can get the project out of control and it's hard to tell when that is, so in contexts where you care to avoid that risk it makes sense to be strict about it. I didn't care for that risk in this case, so it made sense not to bother and focus on building momentum. I'd probably add some integration tests now if I wanted to try a significant new feature or refactor, or if I had to consider contributions from other developers.
For example, testing access permissions. Your UI isn't gonna display data or operations you don't have access to.
But that doesn't mean your back end is honoring permissions.
The other thing to take into account is how noticable the bug is. You should inch more towards writing tests for bugs that are less likely to be noticed by someone.