The question here is really "what's the test?" You have to reailze the MVP _is_ the test.
For a startup, customers are how you pass the test. Anything else is a red light. So in the most important way possible, as long as you have no customers, you have a test which is failing.
This is important because the maintainability you're looking for in a startup is your relationship with the customer. Manage that and the rest takes care of itself. If you are already in a business, yes, "maintainability" means writing code that will last. But if you've just got an idea or a dream, you've got nothing worth maintaining. Nor will you ever.
Put differently, your technical debt can never exceed the economic value of your code, which in a startup is extremely likely to be zero. (Different scenario entirely for project-based work for ongoing businesses, which is why TDD makes so much sense in that scenario)
Not quite, you are committing yourself to throwing away your MVP and rewriting once/if you find the fit. That might be a very good idea if your MVP is extremely simple and you expect it to either fail or succeed with minimal iterations.
> Put differently, your technical debt can never exceed the economic value of your code, which in a startup is extremely likely to be zero
Excellent point, but you probably want to factor in opportunity costs as well. You do not want to take on so much debt that it becomes impossible to succeed.
As soon as you start to iterate on the idea then the maintainability of your codebase starts to matter because that determines how quickly you can iterate on new ideas.
You do not want to get stuck doing even a partial rewrite while your competitors keep iterating their original higher quality codebase.
The overhead that testing or even full TDD add is very minimal if you have experience, so that's a tradeoff that must be made carefully. If you are thinking about learning TDD or testing while doing your MVP then that's a different story.
This is the same question as "should I use version control for my MVP" isn't it? The level of complexity for an MVP where this becomes a bad idea is different but it's the same question.
I agree, the assertion that you shouldn't test is absurd. For example, TDD can save you time by catching bugs for you. When Iv'e worked on apps without tests, I have to test manually each time I make a build, which gets annoying. That's time I could spend coding. I think the solution is something in the middle ground. TDD can sometimes veer off into a time wasting effort for the sake of TDD. Just TDD the complex parts, or the ones that are likely to break. Also write the tests that are easy, or quick to write.
For a startup, customers are how you pass the test. Anything else is a red light. So in the most important way possible, as long as you have no customers, you have a test which is failing.
This is important because the maintainability you're looking for in a startup is your relationship with the customer. Manage that and the rest takes care of itself. If you are already in a business, yes, "maintainability" means writing code that will last. But if you've just got an idea or a dream, you've got nothing worth maintaining. Nor will you ever.
Put differently, your technical debt can never exceed the economic value of your code, which in a startup is extremely likely to be zero. (Different scenario entirely for project-based work for ongoing businesses, which is why TDD makes so much sense in that scenario)