There may be sampling bias at play here. For every start-up struggling to scale I’ve seen twenty who architected a solution for a billion users before shipping (or getting paid for) anything. They are the ones who hit the “we ran out of money” fan.
Waiting until your code is broken is bad. I’d argue it’s worse to waste two weeks architecting a feature for 10,000 users before you even have 100.
It’s a tough lesson every entrepreneur must learn.
And lest a non-technical type think they’re safe, it also manifests in perfectionism around document formatting, logos, product names, incorporation documents, strategic orthodoxy, et cetera.
To the extent there is a single mindset, it’s in execution orientation more than the various deficiencies that interrupt it.
That said, the most common forms are procrastination and perfectionism. The former results in mis-prioritization, e.g. fucking with the font in your incorporation docs instead of making sales calls. The latter in task obsession, e.g. fucking with the wording in a sales message.
My demon was the former, so I can speak to it directly: pick up hobbies that force you to prioritize on the fly. For me, that’s been backcountry skiing, diving and flying. Except, of course, those are hobbies I picked up after my startup. The real answer is to find a co-founder (and/or team) who balances your patience setting.
Quick and flexible often has a more favourable vector.
There's no such thing as perfectly engineered code. It has a shelf life and operating capacity just like one category of vehicle for another.
It’s rare that a startup acquires users so fast that their codebase becomes the bottleneck
Even if this does happen, it unlocks an easy path to investor money and you can spend your way into expensive engineers who will unlock the problem quickly for you.
Mis-labelling growing pains as failure would be one of them.
But that’s fine. They demonstrated product-market fit. They’re now positioned to be able to afford experience.
Hiring an experienced scaling engineer before you have a hundred users might be about as dumb as spending two weeks architecting an MVP.
That’s also fine. They’re talking about “a team of 4.” You don’t need an engineering culture for four people.
The perfect is the enemy of the good. There’s a balance between shipping code and cleaning house. As a startup that balance is weighted more towards slinging features.
But at least index your dbs.
Build a monolith.
Break it up later once you have a proper engineering team.
That hasn't been my experience at all. Your "1000x" claim is so far off the mark. In my experience it's maybe 1.001x more difficult, if not less difficult in so many ways.
I built my startup's tech stack on serverless functions and serverless database, and serverless storage, and it's been really very easy. I don't have any server that can go down, I don't have to worry about server maintenance, but I do have to worry about AWS removing older Lambda runtimes and needing to update my code to run on the new ones when necessary, which isn't all that often. But that's about it. It just runs, 24/7/365, and costs me practically nothing while building out the company. My total AWS bill for the last 2 years is about $0.40/month (less than $10 total for 2 years), and the product is mature and launching soon.
And the great thing is, this is built to scale from day 1. I don't have to worry about load balancers or bursts of traffic or anything that would bring a company down right as it's getting traction.
In the first few months your product will change direction so fast any semblance of a sensible design you had will be long gone by the end of the first year.
Instead, whilst the team is small (ie. 3 devs or fewer), just kludge together everything. No good coding standards, no tests, just demo-day quality.
Then, when you get above 4 developers and the product direction is clear, rebuild everything from scratch.
Sounds like a waste, but rebuilding is far faster than doing it the first time, and you'll be able to have a sensible design rather than something that has already changed direction countless times. Now is also a good time to change programming languages away from something good for prototypes into something production ready and easy to hire developers for.
"Step 1: Don't listen to anything OP said.
OP lies about going to Harvard. He thinks he can put it on his linkedin just because he did an 8 hour online course from HarvardX on basics of leadership.
So assuming OP didn't lie about his experiences in start-ups (he 100% did lie), his diagnosis of the issues make no sense.
Unindexed db is just pure incompetence so if this is your problem then you have many more things to worry about, like learning the basics of programming.
Automatic testing is not required in start-ups and often comes at much later stages.
Auth vulnerabilities by themselves would never fail a start-up. Only data leakages caused by them would. So it's a very weird point.
There is rarely such a thing as bad code, all the code written by other people is bad while all the code written by me is either perfect or I have an excuse. It's always like that. Saying you should "improve" your code so that the devs spend less time wrestling with it is an insane statement, beyond basic quality controls. Bad code is almost always code that does something in a way that unexpected new reqs were not accounted for. And you can't expect the unexpected.
Autoscaling servers is hard. It's always better to just get what you need and then some. Within reason of course. And then leave the actual deployment optimization to dev ops engineers that you can hire later.
The post is really nonsensical. If there is one thing you should learn, it's to recognize obvious slop and outright lies.
EDIT: Also OP most likely bought upvotes. Weekend numbers like this make no sense. Especially on such a low quality post. And his linkedin is a trove of obvious lies and misrepresentations, even sneakily claiming he founded a company with 80k customers, while in reality he worked for an already established company with 80k customers as a low level employee, and then wording his claim in such a way where he has plausible deniability.
"
Perhaps this post was a way to gain customers?
His account is 4 years old but hardly any comments. Definitely doesn't use reddit regularly.
It doesn't automatically devalue the message.
When you hire senior people, expect them to tell you what you need to do. Not the other way around. Hire people who are smarter than you.
sema4hacker•2h ago
But none of those systems were ready to support users on the Web, and suddenly lots of new client-server technology (and security) had to be implemented, often by programmers who never created those kinds of systems before. I think the result is often the kind of low quality software and projects the reddit article describes.
I'm somewhat surprised that "turnkey" packages for manufacturers/distributors/retailers haven't become more prevalent and dominating, like they seemed to be in the old days.