- When the bridge collapses I'll be managing someone else.
- When they find out this airplane has critical design flaws I'll be managing someone else.
- When this software I'm working on is hacked I'll be managing someone else.
I personally interview a lot of people and if they start proposing microservices or k8s or anything trendy like that (before having context), I consider it a negative point.
When hiring, I want someone to take a look at a busines problem, break it down into a smaller pieces. Most of the times, the most important engineering work is coming up with the right data models/data structures.
So yeah, maybe the architecture I have now wont scale up. But at least it'll get the business going. Years later when there are more resources, the software could be rewritten or whatever.
Also, you'r example mentioned "software being hacked". I never said undermine security. Security should always be taken seriously. Security is not a premature optimization. Scalability is.
There are plenty of situations where decent security is a premature optimization too. For example prototypes or proofs-of-concept that are only intended to demonstrate or benchmark a capability. The sort of thing where, even if you did insist on making it 'secure' the username/password would be admin/admin.
What you said all sounds reasonable. Sure, don't build something scalable if you've figured out you want something quick to prove your market and you're ok with tossing it all away or if you'll never need the scale. These are not the same thing. But this will be somebody else's problem? I don't want that guy on my team... Something someone told me a long time ago, write code like the guy that takes it over from you is a psychopath and has your address.
"Doesn't scale" doesn't imply "inadequate."
Overbuilding is waste.
When a bridge fails it'll just fail. When software runs into a scaling limit it'll degrade and fall on its arse constantly and be absolutely terrible as long as it takes for the software team to completely rework their entire architecture often having to learn completely new technologies.
The real risk you're incurring by deploying a prototype to production until traction is demonstrated and scaling becomes an issue is that deferring the design of the 'real' system risks succumbing to second-system syndrome and prematurely trying to make it a 'platform'.
Roughly, the first version just has to work, the second has to scale, and the third (assuming you get there that soon) is the one that starts needing to be refactored/generalized into various reusable subsystems.
It has to handle the projected load, with some safety margin.
"projected until when?" you ask?
Well, your projections will be wrong. And, your needs will change, which means that you're going to be changing the system anyway.
That's where judgment comes in.
Suppose that each customer is worth $10/month and that the "not scalable" version can handle 1M customers. That's at least $5M MRR when the system is at 50%.
If the scalable version takes significantly longer to develop, you might choose to put it off until you have more money/resources, especially since there will probably be other changes. (And, you don't know where the actual bottlenecks are.)
