I am not so sure. This is a handwavy advise I always hear from contemporary business wizbangs, but I don't think it is objectively or universally true. Pedantic, careful and attention to detail, perfectionist products that just work without things breaking all the time are a pleasure to use from the standpoint of the customer. Figure out the implementation details, funding, motivation, etc. as an entrepreneur - shipping broken products to paying customers is something that I only see in the software industry. You don't buy a vacuum cleaner and expect to send half of the missing screws to the customer 6 months later. Hell, just 20 years ago when you bought your SEGA game cassette, it shipped as a final product. Not to be patched ever. Once its out to the factory, if you found a bug, tough luck. Yes, this analogy has its limits, but silicon valley mentality of this startup hustle is questionable.
It isn't about having functionality served half-baked but about having minimalistic functionality (only serve what brings the most value for the users to their table) and go from there.
It is irrational to think that you know exactly what people want/is going to provide them with enough value to keep coming back to your service/product...
So why not start small by building the basics, releasing them, getting feedback and use that to move your product in sync with what the users want/need.
I loved the sega games as much as the next person, and I truly admire how they got so much shipped with such limitations.
But this indicates one big problem of makers nowadays: building functionality has become easier and easier with all the frameworks/tools/no-coding/... stuff that it has become too easy to ship too much (or lose yourself in keeping working on adding just a little feature here and there), thus straying away from shipping and getting that golden feedback from actual (paying) users.
I'll be checking out the video later, thanks for sharing and your feedback!
Think more abstractly. A business is delivering piece of IP to the customer in exchange for monetary value. The medium of this IP can be physical or intangible. It is the delivery latency that's different. If those screws that I talked about arrived in about 45ms latency from the warehouse to the customer, and fitted themselves in another 2mins, you could patch things instantly. Just because this latency is different, doesn't mean you ship MVPs, broken pieces of software that require constant patching. Take time, carefully think about the architecture of the software, think about extensibility and modularity. Avoid feature creep, instead work on just works aspect of the product. This is why I love software from companies like Sublime HQ. They make fast, efficient, well architected software that's a pleasure to use. Similarly, there is something beautiful about unix utilities, little pieces of software that just work :) Continuous delivery is great for huge software, Arch Linux, for example.
I totally agree that setting up a product that is extensible, stable, scalable, etc. is something that needs to be done.
As I see it, and how I'm currently executing, is that the focus on extensibility and modularity increases over time. I look at making that extensible software as something that starts in an MVP with a focus on 1K users max, and grows and becomes more important from that point on. So it is something you can do a while after the initial launch.
> Just because this latency is different, doesn't mean you ship MVPs, broken pieces of software that require constant patching.
I agree that the MVP should be working properly. No doubt there. But it should also focus on testing if it provides value (and see if it actually is viable?). By capping it at 1K users to start with you can focus on the value part instead of spending your time on tech implementation at first.
Especially for bootstrapping solo founders, I strongly believe that the focus should be on the value of the product in the beginning, not in the setup of the technical solution.
I'm going to use my own case as an example:
As a single developer I'm working on a product idea (sharing your videos via enhanced QR codes that enable Augmented video watching without the viewer having to install an app).
I could set up the infra, cloud services, build extensible pretty code and do the works in getting this ready to shine and go for 10K users.
But I chose not to. Right now, I'm focussing on the proof of concept (which is for showing ME that the idea is feasible and usable in the ways that I want it to work).
The PoC will only have the concept of working roughly and the code will be a lot of hacked-together code that makes sense to me.
This isn't an MVP as I won't have user accounts, authentication, security, payments, .. implemented. Just the core functionality.
I'm going to share the product with a bunch of people in my network to get initial feedback about it and I'm going to use it myself.
I probably will use footage of using it, along with an explanation of the idea for a landing page.
I'll know within a week or two if the idea is good enough to keep using it myself and I'll have my network feedback along with things I didn't consider that need to be in check.
When the lights are green, I'll start a new solution with clean code and the core functionality from the PoC implemented so its clean, expandable, maintainable, secure, tested, etc.
I'll have the minimum feature set around it (security, accounts, support channel, payments, ...) to make it a whole experience.
For the MVP my focus lies on reaching 10, 100, and then hopefully 1K users.
And I will have a tonne of work laying ahead of fixing stuff, giving support and helping out.
I'll also have metrics about bandwidth usage, unforeseen scenarios, people who are working my product and stretching its limits in ways I didn't even consider.
And _that right there_, that moment after I hopefully have a bunch of users, is where I would make sure the amount of users is capped, and where I start to invest time on making this more scalable, improving the app experience, see If there need to be changes of the services used I'll use in the background (behind the API), etc.
There will be a lot I've learned by this point. And if the product has proven to be viable (I gain enough revenue from it to justify working on it), I'll be working hard to make it even more secure, stable, scalable, and future proof.
While writing this, I feel like we aren't that different in how we look at things. Perhaps its semantics, perhaps I just need an extra cup of coffee.
I think that the focus on CI/CD, scalability, modularity starts with the MVP and increases from there.
I know there are quite some products that ran a nice MVP and reworked their backend from scratch on after some time to make things more flexible and elastic to take on more users.
I think it isn't quality that should be sacrificed in order to ship but scope.
This is the idea at play with MVPs. Don't try to produce something with all the bells and whistles, reduce scope as much as possible, polish that, ship.
Good working software, which works and provides value for its users is what it's about. Evaluating if it provides value for others is done best by letting them use it.
I recommend watching this incredible talk (it's about software) : https://www.youtube.com/watch?v=pW-SOdj4Kkk