I audited 47 failed startups' codebases(old.reddit.com) |
I audited 47 failed startups' codebases(old.reddit.com) |
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 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.
Source? The eager overfundraisers tend to be either remarkable successful or remarkably not. The only constant being remarkability.
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.
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.
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.
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!
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.
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.
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.
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.
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.
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.
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.
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 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.
"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.
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.
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.
>"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.
And the root cause is hiring process that admits devs that can do db api call but have no idea what having database as a component of your app actually entails.
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.
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.
(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.)
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.
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.
The traditional way is to work with your sales team and pay attention to them in your previous roles.