Bootstraping and TDD

I think the IH way is just do what is more productive for you.
If manual testing and clicking around after a tiny change is not a problem for you - ignore tests.

My approach would be

1. Cover the most important usecases with high-level integration tests.
2. Have a proper error tracking tool to be notified about production bugs and react fast (goes without saying :) )

As a backend dev, I noticed that I am very slow without tests. Unit tests give me the assurance that what I built works well as expected and doesn't break existing features. I would not want to go about manually testing other features when I add a new feature.

I recently build an MVP to validate an idea and it had good tests. My partner thought it was a waste of time but to me it was a good time investment. I wouldn't want to open Graphiql or postman every time and keep meddling with those headers just to test that my new endpoint works, that's a lot of context switching and if I swipe to the right instead of the left and land on Twitter, now I have another battle in my head to fight, check that DHH tweet or continue coding.

There is no such thing as "throw-away code". That implies that the POC/MVP/basic working example you build will be discarded as soon as you validate the idea. Are you planning on completely rewriting the codebase once you validate the idea?

It's like brushing your teeth or exercising. Build the habit from the beginning then there is no extra cost (mental or time) because you already do it.

TDD is the only development methodology I've found with actual, documented proof of improving your ROI. The hard part is building the habit of doing it from the start.

I do have to ask, why, as a single dev is it iffy?

For me, testing is a matter of return on investment, or how the cost (in hours, dollars, or whatever) of validating the code compares to the potential loss from a failure.
The rule I've generally used (on my own/as a contractor/as an employee) is that code expected to bring in money (literally or indirectly) needs some sort of validation, with more attention/rigor warranted for more money. Anything else, I judge by how inconvenient it would be (for me, specifically) if the code fails. If it doesn't meet either of those criteria, it'll get tested in its normal usage.

Are you scaling your product? If not, no. You should be focusing on validating the product and getting to product market fit. Investing time into testing is a waste if that code is throwaway. If the software is complex find a way to simplify the concept and do things manually until you know for a fact customers want that thing enough to pay for it.

I'd still do it. TDD isn't just about investing in tests, it's about investing in good design. But there's an art to it. Testing the right things is productive. Testing the wrong things can seize up a codebase and slash productivity.

I wouldn't get bogged down worrying about coverage percentages or following a strict tests-first approach. I do think that having some tests (and error reporting!) improves my "ship it" confidence: can I write some code, release it, and move on to something else really quickly without worrying about whether I just broke something important in a flow I can't easily test manually? I don't want to hesitate to do a release several times a day because I need to manually test things.