> not the "we ran out of money" fan, the "our product literally cannot scale and we have no idea why" fan
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.
There is either some sampling bias or some creative reinterpretation of history.
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.
In similar vein: a lot of startups fail because they raise too much money too early, have unrealistic expectations, while instead they should have raised less against a lower valuation but have investors with realistic expectations.
I fell into this trap often enough even though i knew this anti-pattern. Doing a startup, you have to resist writing code like you would as a proud engineer. If the code is quick and dirty, you're doing it right.
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.
Yes I really need someone to say “you’re still saving that yak? What the hell are you doing, I’ve lined up x customers already”. Like a non-technical partner who is good at sales and promotion. Absolutely no idea how to meet someone like that though.
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.
I feel like there's a decent middle-ground there, though. You don't have to sit down for two weeks and architect everything, but I feel like you should have indexes on your database columns.
Yeah, I personally like to think code quality doesn’t matter too much because you can refactor / rewrite fairly easily later. The same is not true for your data model: bad data will live with you forever and it’s much, much harder to refactor.
Eh, you can migrate bad data to a better model, too - and you can write code in such a way that you paint yourself into a corner that makes rewrites, especially incremental rewrites, very difficult.
I just mostly think that all these issues are just people being bad at writing software, and that if you're bad enough at it, you can crater your business. If it's only a little bad, the business can limp along until you can rewrite it.
In practice when people do this, 99.9% of the time it leads to data continuity issues which makes the old data essentially unusable for most important things.
It's pretty easy to run an alter table ... add index ...
If a team running a database can't or doesn't do that, when it's relevant, they don't know how to operate a database, or how to learn how to operate things. And they probably have no friends who know either.
That doesn't sound like a team where 'be sure to have an index on your DB' is going to be helpful.
Otoh, maybe they never bothered to add an index because they had no users, and unindexed queries were good enough while they developed their product that nobody wanted anyway. Table scans on 100,000 row tables aren't that slow when the whole table is in memory.
Adding indexes late isn't a huge deal. You add the index and things get faster and you go on with life. Worst case, you have to rebuild your table(s) so that indexes can apply... That could be a little rough, but probably not that rough until you have a lot of users; and if you have a lot of users, great!
Seconding this. I would have a plan by month 6 for how to get past month 24 though and be iteratively laying the groundwork for it. You don’t need a scalable architecture from day 1, you just need to avoid painting yourself into corners.
Add the basic invocations for formatting, linting, testing, etc. can be boilerplate copied into a repo - maybe with a Makefile or similar that is somewhat language agnostic and can wrap anything.
Run these locally before commit, and have CI do it too. You'll get a baseline level of "not total garbage" in terms of automated checks, and even if there are no real tests, at least there's an obvious place to add them later.
Whatever language you’re most comfortable with to ship the fastest with. Never ever learn a new language to start a startup. Learn a new language for the sake of learning it, but they’re two independent things.
Did you read the article? The customers hired an outsider because they were unable to conceive of what to do. Not having indexes? Are you kidding me? Thats not a flex of "we're strategic long term thinks keeping our eye on the real problems." It's stupid. The article is right: bad engineers defer what they think is noise too long until it becomes a major problem, and an outsider had to set them straight.
I once worked at a startup where I was employee #1 doing full-stack. The CTO who hired me and 5 other developers wanted 100% test coverage from the start, and none of the details about his demands were discussed ahead of time. The rest of the tech workflow was so mired in bureaucracy and process that it was like swimming through mud. It was a disaster, we couldn't ship anything fast enough or at all, then the company pivoted, and then finally failed after about 8 months.
I don't know about his conclusion of "spend 2 weeks on architecture". If these people don't realize they need to index a database table, 2 weeks of talking about what they're going to do isn't going to help. This is 100% lack-of-experience, and it's why startups should hire more experienced people (and ideally, listen to them).
> If you're hitting that point and you haven't fixed your engineering culture
That’s also fine. They’re talking about “a team of 4.” Your priority with a four-person team should not be engineering culture other than getting shit shipped.
If you want to get stuff shipped though, you need a good engineering culture. If you want to move fast you need experienced people. This feels like the argument against automated tests. "It'll slow us down!" So will debugging the slop your coworker thoughtlessly tossed in without bothering to see if it will work!
(I harp on the "experienced people" thing because I see a lot of startups that seem to be 23 year olds vibe coding. That hits a brick wall fast.)
> I see a lot of startups that seem to be 23 year olds vibe coding. That hits a brick wall fast
But they’re going fast. That unlocks resources. The whole point is experience is expensive. Moving fast lets you afford that expense. And collision measures velocity.
Messiness is bad. Premature optimization fatal. Young companies tend to be messy because that’s the bias that survives.
I do appreciate what’s being said here and I think there is a balance to strike. Is it a good idea to plan and design before jumping into code? Absolutely. Is it worth spending a month thinking of the perfect system when you don’t have customers actively using it or how they will use it? Probably not.
I also think it’s important to not get stuck in the sunk cost fallacy to avoid a rewrite. Take your lessons learned and bite the bullet.
I am in a position right now watching 3 years of tech debt get refactored into the same spaghetti garbage because leadership waited too long before calling a rewrite, and now they are under immense pressure to get it done but picked a warm body to rewrite it because everyone else is busy on other important things.
In another life, I was able to see the writing on the walls after initial implementation and spent two weeks rewriting the MVP to then be able to add new scalable features at a much higher velocity.
Needs analysis is crucial here, but I don’t disagree with OP.
Can I add also doing micro services or loads of small serverless functions way too early. It will make your project 1000x more difficult to maintain and extend in the short term for no significant gain.
Build a monolith.
Break it up later once you have a proper engineering team.
>doing micro services or loads of small serverless functions way too early
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.
That's a nonsense reply, and kind of an ad hominem attack. The claim was:
>"It will make your project 1000x more difficult to maintain and extend in the short term for no significant gain."
Nowhere was "launching" anything mentioned. Nice of you to move the goalposts wherever you want to. My project is doing just fine, thank you. Sorry I didn't rush out a piece of crap that nobody wants to use?
This really emphasises the Just Use Django (or Rails) advice.
Database indexing by default, check. Working, good, auth systems, check. Test framework, check.
> honestly just spend 2 weeks on architecture before writing code
This is true, or just import an existing architecture and stick to it. My previous company was all Django from day 1, and we mostly didn't have these issues. It's not a full replacement for thinking about architecture, but if you always think "where would Django put this" and do that (should it be in the form, the view, the model, etc), it'll get you a long way. Past the 24 months.
Does this work for all software? No obviously not. But even though most SaaS businesses will have a complicated non-web app sort of component, you can build that bit separately and keep it simple, while having the bulk of your accounts, billing, CRUD, etc, in a basic web app.
Importantly, there are very few frameworks that actually do this. Django, Rails, maybe Spring (I have no experience in that) do it, but composing a bunch of Node packages together is not a replacement, it never works that well. Flask, etc in the Python ecosystem are the same, every Flask app that gets big becomes a custom mess.
One of the top comments, which was echoed by others: "I'm guessing here, but it would not surprise me if you would find the same patterns in succesfull startups as well.. Only they had the money coming in to rebuild sooner and hire more experienced engineers.."
I remember how in the days way before the Web, it seemed that companies of various sizes that wanted to "computerize" their operations either built their own homebrew systems from scratch with in-house programmers or consultants, or they bought packaged software systems (MRP for manufacturers, or a distribution package for wholesalers, retail package for brick and mortar, etc.), usually with options to customize.
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.
I would argue that it depends quite a bit on the circumstances.
If the founder(s) or CTO hired a team of web developers to be full stack developers without actually figuring out whether they have the skills to do that or not, then the ones doing the hiring should be on the chopping block especially if they then took no action to properly train their employees and/or review their output.
It's a much more likely situation that whoever actually created the application without database indexes had no idea how to operate a database and were asked to do so anyway. That's not their fault in almost all cases.
What strikes me as the actual root cause is a lack of proper oversight.
Did any of these companies have a CTO who actually knows something? Did the founder hire all of his friends to work ((or ask them to help for free) ) with him regardless of their skills? Did anyone even identify what skills would be appropriate for building what was being built (having some sort of idea about the architecture would help here)?
Nobody knows everything. Don't have people working on things they have no clue about, or make sure you watch closely if you do.
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.
Yeah you have to be very skeptical of anything on Reddit anymore. It's beyond ripe for shill accounts and shill advertising. My first thought was he's low-key prompting people to DM him and hire him to save their crappy startup.
His account is 4 years old but hardly any comments. Definitely doesn't use reddit regularly.
This is very glib. Hindsight is always 20/20 vision. No corpse appreciates the coroner explaining why they died. A patient prefers a doctor who prevents them moving from a patient to a corpse. A lot of startups have 3-6 months before they're dead. Stone dead! Architectural review sounds great, and it is, but the requirements change every day - they know what those requirements are right now; but later, even a day later, who knows? Can any company do a review before they know the "shape" of what they're trying to achieve? They have 3-6 months, and they need to ship. No startup has a reasonable chance of getting the architecture right unless the requirements for the product (a product that should generate income, and should pay the bills) are at least close. Testing? Test what? The product hasn't gelled. What are they testing? They're fumbling though. That reddit fella should cut them some slack at the funeral, and not dance on the grave. Ex post facto bs.
Oh c'mon. This is circa 202x not 1960. Hind sight of what? If you can't understand 13% utilization of servers for the bills you're paying or indexing queries ... what did you expect? To be taken seriously? Please ... they had to hire an outsider to point out the stunningly obvious.
"91% had no automated tests at all". I call bullshit. The rest is all plausible, but startups love test coverage. It doesn't help them scale, it just helps with maintainability which is a different problem.
This shocked me when I worked in a corp. Large team of quite good Java programmers and the database was severely lacking indexes. When I (hired as a frontend dev) pestered them about it and they finally added indexes they were pretty much glowing because suddenly everything took no time at all.
Indexes are the reason why databases exist. If you don't use them you might just as well use files directly.
Meh. I’d like to see the codebase of the ones that survived. It may not be much different stats.
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.
> not the "we ran out of money" fan, the "our product literally cannot scale and we have no idea why" fan
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.
There is either some sampling bias or some creative reinterpretation of history.
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.
> creative reinterpretation of history
Mis-labelling growing pains as failure would be one of them.
In similar vein: a lot of startups fail because they raise too much money too early, have unrealistic expectations, while instead they should have raised less against a lower valuation but have investors with realistic expectations.
> a lot of startups fail because they raise too much money too early
Source? The eager overfundraisers tend to be either remarkable successful or remarkably not. The only constant being remarkability.
3NF and microservices FTW.
I fell into this trap often enough even though i knew this anti-pattern. Doing a startup, you have to resist writing code like you would as a proud engineer. If the code is quick and dirty, you're doing it right.
> this trap
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.
How do I break out of this mindset????
> How do I break out of this mindset?
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.
Yes I really need someone to say “you’re still saving that yak? What the hell are you doing, I’ve lined up x customers already”. Like a non-technical partner who is good at sales and promotion. Absolutely no idea how to meet someone like that though.
Dirty is technical debt.
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.
I disagree with this approach.
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.
I feel like there's a decent middle-ground there, though. You don't have to sit down for two weeks and architect everything, but I feel like you should have indexes on your database columns.
Yeah, I personally like to think code quality doesn’t matter too much because you can refactor / rewrite fairly easily later. The same is not true for your data model: bad data will live with you forever and it’s much, much harder to refactor.
Eh, you can migrate bad data to a better model, too - and you can write code in such a way that you paint yourself into a corner that makes rewrites, especially incremental rewrites, very difficult.
I just mostly think that all these issues are just people being bad at writing software, and that if you're bad enough at it, you can crater your business. If it's only a little bad, the business can limp along until you can rewrite it.
In practice when people do this, 99.9% of the time it leads to data continuity issues which makes the old data essentially unusable for most important things.
Indexing your DB is a pretty basic thing to do, and one of the biggest offenders listed.
It's pretty easy to run an alter table ... add index ...
If a team running a database can't or doesn't do that, when it's relevant, they don't know how to operate a database, or how to learn how to operate things. And they probably have no friends who know either.
That doesn't sound like a team where 'be sure to have an index on your DB' is going to be helpful.
Otoh, maybe they never bothered to add an index because they had no users, and unindexed queries were good enough while they developed their product that nobody wanted anyway. Table scans on 100,000 row tables aren't that slow when the whole table is in memory.
Adding indexes late isn't a huge deal. You add the index and things get faster and you go on with life. Worst case, you have to rebuild your table(s) so that indexes can apply... That could be a little rough, but probably not that rough until you have a lot of users; and if you have a lot of users, great!
100% agreed. Database indexing is no where near premature optimization. Failing to do it is more like going for a run without tying your shoes.
Seconding this. I would have a plan by month 6 for how to get past month 24 though and be iteratively laying the groundwork for it. You don’t need a scalable architecture from day 1, you just need to avoid painting yourself into corners.
I disagree with this hot take.
Add the basic invocations for formatting, linting, testing, etc. can be boilerplate copied into a repo - maybe with a Makefile or similar that is somewhat language agnostic and can wrap anything.
Run these locally before commit, and have CI do it too. You'll get a baseline level of "not total garbage" in terms of automated checks, and even if there are no real tests, at least there's an obvious place to add them later.
What languages would you start with, and what languages would you change to?
Whatever language you’re most comfortable with to ship the fastest with. Never ever learn a new language to start a startup. Learn a new language for the sake of learning it, but they’re two independent things.
I’d agree before AI but it’s so easy to add tests with AI, you might as well. Same with types. You can have AI fix your type checker errors
Did you read the article? The customers hired an outsider because they were unable to conceive of what to do. Not having indexes? Are you kidding me? Thats not a flex of "we're strategic long term thinks keeping our eye on the real problems." It's stupid. The article is right: bad engineers defer what they think is noise too long until it becomes a major problem, and an outsider had to set them straight.
I once worked at a startup where I was employee #1 doing full-stack. The CTO who hired me and 5 other developers wanted 100% test coverage from the start, and none of the details about his demands were discussed ahead of time. The rest of the tech workflow was so mired in bureaucracy and process that it was like swimming through mud. It was a disaster, we couldn't ship anything fast enough or at all, then the company pivoted, and then finally failed after about 8 months.
I don't know about his conclusion of "spend 2 weeks on architecture". If these people don't realize they need to index a database table, 2 weeks of talking about what they're going to do isn't going to help. This is 100% lack-of-experience, and it's why startups should hire more experienced people (and ideally, listen to them).
> This is 100% lack-of-experience, and it's why startups should hire more experienced people
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.
The article is talking about timescales around 2 years out though. If you're hitting that point and you haven't fixed your engineering culture..
> If you're hitting that point and you haven't fixed your engineering culture
That’s also fine. They’re talking about “a team of 4.” Your priority with a four-person team should not be engineering culture other than getting shit shipped.
If you want to get stuff shipped though, you need a good engineering culture. If you want to move fast you need experienced people. This feels like the argument against automated tests. "It'll slow us down!" So will debugging the slop your coworker thoughtlessly tossed in without bothering to see if it will work!
(I harp on the "experienced people" thing because I see a lot of startups that seem to be 23 year olds vibe coding. That hits a brick wall fast.)
> I see a lot of startups that seem to be 23 year olds vibe coding. That hits a brick wall fast
But they’re going fast. That unlocks resources. The whole point is experience is expensive. Moving fast lets you afford that expense. And collision measures velocity.
Messiness is bad. Premature optimization fatal. Young companies tend to be messy because that’s the bias that survives.
I do appreciate what’s being said here and I think there is a balance to strike. Is it a good idea to plan and design before jumping into code? Absolutely. Is it worth spending a month thinking of the perfect system when you don’t have customers actively using it or how they will use it? Probably not.
I also think it’s important to not get stuck in the sunk cost fallacy to avoid a rewrite. Take your lessons learned and bite the bullet.
I am in a position right now watching 3 years of tech debt get refactored into the same spaghetti garbage because leadership waited too long before calling a rewrite, and now they are under immense pressure to get it done but picked a warm body to rewrite it because everyone else is busy on other important things.
In another life, I was able to see the writing on the walls after initial implementation and spent two weeks rewriting the MVP to then be able to add new scalable features at a much higher velocity.
Needs analysis is crucial here, but I don’t disagree with OP.
Can I add also doing micro services or loads of small serverless functions way too early. It will make your project 1000x more difficult to maintain and extend in the short term for no significant gain.
Build a monolith.
Break it up later once you have a proper engineering team.
>doing micro services or loads of small serverless functions way too early
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.
You're claiming all of this without a product launch? If so, this doesn't seem like a counterpoint at all.
That's a nonsense reply, and kind of an ad hominem attack. The claim was:
>"It will make your project 1000x more difficult to maintain and extend in the short term for no significant gain."
Nowhere was "launching" anything mentioned. Nice of you to move the goalposts wherever you want to. My project is doing just fine, thank you. Sorry I didn't rush out a piece of crap that nobody wants to use?
I hope you have a better day tomorrow.
This really emphasises the Just Use Django (or Rails) advice.
Database indexing by default, check. Working, good, auth systems, check. Test framework, check.
> honestly just spend 2 weeks on architecture before writing code
This is true, or just import an existing architecture and stick to it. My previous company was all Django from day 1, and we mostly didn't have these issues. It's not a full replacement for thinking about architecture, but if you always think "where would Django put this" and do that (should it be in the form, the view, the model, etc), it'll get you a long way. Past the 24 months.
Does this work for all software? No obviously not. But even though most SaaS businesses will have a complicated non-web app sort of component, you can build that bit separately and keep it simple, while having the bulk of your accounts, billing, CRUD, etc, in a basic web app.
Importantly, there are very few frameworks that actually do this. Django, Rails, maybe Spring (I have no experience in that) do it, but composing a bunch of Node packages together is not a replacement, it never works that well. Flask, etc in the Python ecosystem are the same, every Flask app that gets big becomes a custom mess.
One of the top comments, which was echoed by others: "I'm guessing here, but it would not surprise me if you would find the same patterns in succesfull startups as well.. Only they had the money coming in to rebuild sooner and hire more experienced engineers.."
I remember how in the days way before the Web, it seemed that companies of various sizes that wanted to "computerize" their operations either built their own homebrew systems from scratch with in-house programmers or consultants, or they bought packaged software systems (MRP for manufacturers, or a distribution package for wholesalers, retail package for brick and mortar, etc.), usually with options to customize.
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.
Not indexing your tables is a fireable offense.
For whom?
I would argue that it depends quite a bit on the circumstances.
If the founder(s) or CTO hired a team of web developers to be full stack developers without actually figuring out whether they have the skills to do that or not, then the ones doing the hiring should be on the chopping block especially if they then took no action to properly train their employees and/or review their output.
It's a much more likely situation that whoever actually created the application without database indexes had no idea how to operate a database and were asked to do so anyway. That's not their fault in almost all cases.
If the startup tanks, the firing happens automatically.
What strikes me as the actual root cause is a lack of proper oversight.
Did any of these companies have a CTO who actually knows something? Did the founder hire all of his friends to work ((or ask them to help for free) ) with him regardless of their skills? Did anyone even identify what skills would be appropriate for building what was being built (having some sort of idea about the architecture would help here)?
Nobody knows everything. Don't have people working on things they have no clue about, or make sure you watch closely if you do.
This happens when you have “technical” founders who don’t really know the tech, and a bunch of engineers who then have to report to that person.
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.
this is a claude output verbatim, wonder what happens to reddit over the next 3-6 months, we really destroyed the commons.
One of the top comments (https://old.reddit.com/r/Entrepreneur/comments/1o4jup6/i_aud...):
"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?
Of course it was. As are a lot of the blog posts posted here.
It doesn't automatically devalue the message.
Yeah you have to be very skeptical of anything on Reddit anymore. It's beyond ripe for shill accounts and shill advertising. My first thought was he's low-key prompting people to DM him and hire him to save their crappy startup.
His account is 4 years old but hardly any comments. Definitely doesn't use reddit regularly.
This is very glib. Hindsight is always 20/20 vision. No corpse appreciates the coroner explaining why they died. A patient prefers a doctor who prevents them moving from a patient to a corpse. A lot of startups have 3-6 months before they're dead. Stone dead! Architectural review sounds great, and it is, but the requirements change every day - they know what those requirements are right now; but later, even a day later, who knows? Can any company do a review before they know the "shape" of what they're trying to achieve? They have 3-6 months, and they need to ship. No startup has a reasonable chance of getting the architecture right unless the requirements for the product (a product that should generate income, and should pay the bills) are at least close. Testing? Test what? The product hasn't gelled. What are they testing? They're fumbling though. That reddit fella should cut them some slack at the funeral, and not dance on the grave. Ex post facto bs.
Oh c'mon. This is circa 202x not 1960. Hind sight of what? If you can't understand 13% utilization of servers for the bills you're paying or indexing queries ... what did you expect? To be taken seriously? Please ... they had to hire an outsider to point out the stunningly obvious.
If a morbidly obese person dies then saying that maybe they should have eaten less is not really a case of 20/20 hindsight.
If you write a query but don't add an index for the fields in your WHERE ... I don't know what to tell you.
I don't want to be "that" guy, but...
The author's GitHub profile shows a novice, not a seasoned professional. Take that for what it's worth.
https://github.com/MeirDavv
"91% had no automated tests at all". I call bullshit. The rest is all plausible, but startups love test coverage. It doesn't help them scale, it just helps with maintainability which is a different problem.
> like 89% had zero database indexing.
This shocked me when I worked in a corp. Large team of quite good Java programmers and the database was severely lacking indexes. When I (hired as a frontend dev) pestered them about it and they finally added indexes they were pretty much glowing because suddenly everything took no time at all.
Indexes are the reason why databases exist. If you don't use them you might just as well use files directly.
Meh. I’d like to see the codebase of the ones that survived. It may not be much different stats.
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.