"I became more and more “aggressive” about reducing the scope and focusing on the essentials; still, I didn’t want to forget about code quality."
After reading all of it, it seems to me that the problem is right there.
Security, maintainability, offline-first, horizontal scaling etc. Should have just thrown these out the door and put every client on their own VM, with local database and automate backups and updates.
You'd get something out the door and could make sales, then re-factor for the next iteration of the app.
You'd be hard-pressed to find any client that wouldn't be sufficiently sustained on their dedicated hardware (or VM).
Absolutely, highly scalable VMs are available for less than 2€/mo from providers like Hetzner and OVH (less at scale), with an included "global" redundant network.
Does it make sense if your business idea is having thousands of customers on a single VM by using containers?
No, of course not! But it does make sense if each customer is worth more than 2€ per month.
I think this is what's wrong with today's SaaS and web environment. People thing that by going with AWS, creating a complicated auto-scaling infrastructure that supports billions of user is the way to go and the most cost-effective way, but while doing so many forget that using the simpler solution that costs a bit more can actually save time and money.
What's the point of trying to save $1/month per user if you have no users yet and achieving this cost reduction takes one or two more years of development time.
The team i worked with hosted simple solutions on VMs at first. But after a few years, the client requirements and features grew until our biggest problem became maintenance and upgrades.
The sysop costs became higher than our earnings, so we weighted our options of re-building or partner with a larger API-first solution.
Eventually we choose to partner up and in the end, we cut costs to a fraction, while still keeping the customer base and increasing performance.
Which is another point I see constantly, founders desperately want to keep control by not outsourcing when it _should_ be, and by doing that, the costs continue to increase and the already over-worked team can no longer push features, competition gain even more ground, margins fall even more and eventually layoffs and inevitable shut-down.
Good points. It should still be mentioned that moving away from VMs to API-first solution or outsourcing maintenance only happened after the company grew and was successful, not before the MVP was ready.
I thought one of the main selling points was the on-demand computing power and per second billing. So instead of having a $5/mo VPS you only pay 30c or whatever your usage was for that month.
I do know that billing can get confusing and in some unfortunate cases people ended up paying 10x or 100x more than they expected.
Maybe my example was bad, but my point was that sometimes it's ok to not go on the most-efficient route and that for an MVP "good enough" is actually the best way to go.
The main reason people choose AWS is orchestration ability and scaling, the cost is usually hidden in "free" tiers until you start to scale and it becomes visible.
Bandwidth being one of the largest issues...
The second is cost complexity..
AWS pricing is also so complex that Amazon provides cost calculators to get an estimate, however, since most services intertwine, it's so easy to miss obvious cost points that business provide cost-savings service for AWS specifically.
The costs have become so complex, that AWS customers even use AWS own ML service to log and do cost analysis.
After reading all of it, it seems to me that the problem is right there.
Security, maintainability, offline-first, horizontal scaling etc. Should have just thrown these out the door and put every client on their own VM, with local database and automate backups and updates.
You'd get something out the door and could make sales, then re-factor for the next iteration of the app.
You'd be hard-pressed to find any client that wouldn't be sufficiently sustained on their dedicated hardware (or VM).