Q: I have worked on large enterprise software systems but am now struggling working at a startup creating a Minimum Viable Product (MVP). I am a big believer in BDD and TDD, so I’ve developed an automated testing suite for the MVP that has high coverage and great specifications describing and asserting its behaviors in HTML with good pictures. My worry is that large chunks of my MVP may never be used again if the customer doesn’t like the demo. Also, I developed the MVP from the bottom up and I worry that I wrote tests for corner cases that may or may not be exercised in the demo.
Q: How Much Effort Should I Invest in Automated Testing For An MVP?
A: Daniel B. Markham (HN: DanielBMarkham ) gave a great answer to “Should you TDD an MVP?” on HN a while back: “The maintainability you’re looking for in a startup is your relationship with the customer.” Here are some excerpts from his full answer (emphasis in original):
The question here is really “what’s the test?” You have to realize 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).
Q: OK, but some customers pay us for demos and expect us to put the demos into production with little or no modification. If we are given more money to operationalize the demo, it is for features missing from the demo.
A: These don’t sound like an MVP if it is only aimed at one customer and they are paying for it to be developed. I think your challenge is to determine the feature content for a contract development software project to be deployed at a single customer. This sounds like a question of getting agreement on needs and a specification, not how to take an MVP to 6 or 12 or 20 prospects and correlate their feedback.
I don’t think MVP is the right term or framing for the situation that you are working in, the demo sounds more like a user acceptance test for a project that they have paid for.
I think your MVP is what you showed them to get them to fund the development of the “demo” that if accepted will be deployed into production.