Rendered at 23:33:31 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
saimiam 1 days ago [-]
Such anti patterns are like Nostradamus’s prophecies - you see a company flopping then curve fit a narrative to justify the antipatterns.
How do I, as a founder, know that I am falling into an anti pattern? I don’t believe it is possible to know. You can only “know” in hindsight and that makes these anti patterns useless.
enraged_camel 24 hours ago [-]
>> How do I, as a founder, know that I am falling into an anti pattern?
The easiest way is to have outside advisors who can and are willingto adversarially challenge the assumptions you're making. If you don't have those, good cofounders can sometimes play the same role (although that is harder since they are likely to share similar biases as you).
tcp_handshaker 11 hours ago [-]
This type of advice is much like best practices. One of the core reasons why AI will fail.
Its a bit like cooking advice
- Products should be fresh
- Use the best ingredients
- Salt early and correctly
- Cook by temperature, not time
And so on but then you cook side by side with a pro chef...and does not taste the same...
tough 14 hours ago [-]
or worse, what if an anti-pattern is "your" way to success
Joel_Mckay 1 days ago [-]
It takes understanding your own impulses and cognitive biases.
Most people start a small business for tax reasons, and the few lucky loud clowns claiming hyper-scaling BS is sustainable simply disappear within 5 years.
Best advice, answer the simple question "will random people buy this when no one is looking?"... if you have to explain/sell a product/service more than 5 seconds, than that business model likely isn't sustainable.
I also see a lot of smart folks that think they will get paid for excuses... only lawyers, PR, and politicians are in that business. =3
lelanthran 19 hours ago [-]
> Best advice, answer the simple question "will random people buy this when no one is looking?"... if you have to explain/sell a product/service more than 5 seconds, than that business model likely isn't sustainable.
For B2c, maybe. B2B is very different - they aren't going to make up their mind in 5 seconds and you aren't going to have a product that can be explained in 5s.
Joel_Mckay 18 hours ago [-]
>B2B is very different - they aren't going to make up their mind in 5 seconds
If not, than one is explaining/selling again, and you will only ever have 2.7%*(time/sales_pitch_time) customers. Letting client/customers dictate the terms of a product/service often will just turn your business into a staffing agency.
B2B is actually more risk, as any deal exceeding 12% of revenue sets a timer on how long your business will likely survive. Some unlucky folks also end up acting as a product warehouse for clients, contract labor, or a scapegoat for client internal strategic mistakes.
If people can't summarize what they do in 1 sentence, than they likely have a fuzzy definition for a business project goal. For example, people that use more than 4 conditional statements (if/but/when etc.) to describe something, than I have observed they often last less than 3 years regardless of cash burn rates. =3
lelanthran 18 hours ago [-]
> If people can't summarize what they do in 1 sentence, than they likely have a fuzzy definition for a business project goal.
I broadly agree with your point, but disagree with this sentence. IME a 1-sentence business goal is almost certainly too fuzzy to be useful. There's nothing actionable about "We help you survive audits and readiness for regulation $FOO", which is frequently the business goal.
bhouston 23 hours ago [-]
The issue with many critiques like this is that “it depends” and that many of these strategies actually work while often they do not - but given that most startups fail even generally successful strategies will have a high rate of failure.
And the people that study these types of lists to apply it to their own case are then engaging in “analysis paralysis” because the list is so long you are bound to be caught up by it.
So while I think it is useful to critique your idea and business the best thing to do is to try and sell it and make money and keep adjusting and trying new things to maximize your income. There is no magic bullet.
jpgvm 14 hours ago [-]
Hiring middle-management from large companies has to be the biggest startup killer.
Doubly so if they are mediocre to start with and triple so if they bring with them their legion of yes-men.
darksaints 8 hours ago [-]
With hiring from management consulting companies coming in a close second place.
11 hours ago [-]
1saadcodes 23 hours ago [-]
Some seem to treat microservices as a sign of good engineering when it's often just premature complexity. You can always split a monolith later, but you're stuck maintaining that complexity from day one
germandiago 21 hours ago [-]
I have been building a SaaS for a business. One of the decisions I took is "as monolithic as possible" (though you cannot just use that).
One reason is that microservice architecture requires much more operational overhead. So any server we have (except for the database) should be self-contained as a rule, so that it can be autonomous and horizontally scalable.
So far, it is working quite well. You do not need suddenly a Redis for one thing, a ZooKeeper for the next one, and 3 or 4 things to just run the damn binaries. The binaries will start, do whatever migrations need to be done if it applies, and start running. They only need the database. They land health checks, api calls and all the logic needed, in one binary with zero dependencies that is containerized.
This has saved me a lot of pain compared to other architectures where I worked, but those were massive and it was justified (and there was budget for it). But you just need a bunch of teams to be able to do that.
I think going the microservices way for a small team not only does not pay off. I think it can be a suicide.
At the same time, I keep the servers internally modular (enable/disable feature).
HeavenFox 21 hours ago [-]
well... no, splitting a monolith once it has grown past the point where services make sense is incredibly difficult. My last employer spent a couple of years doing it and ultimately gave up. There is just way too much interdependency to split it up cleanly.
So the key here is good engineering leadership to recognize when that point arrives, and push the company to start the transition.
And indeed, microservices solve a organization problem not an engineering problem. When I taught the architecture to new hires, I always say: a service is the largest piece of system that stays together in a reorg :)
plmpsu 20 hours ago [-]
That's assuming you don't separate concerns in your monolith into modules with clear boundaries and dependencies. If you did that from day one, splitting a module off to a different service is easy.
onion2k 17 hours ago [-]
If you can manage that then there's no real benefit to microservices though. The reason for splitting is to solve the problem of failing to separate concerns, so a team that can't do that well is better off building microservices from the start because the alternative for them is building a monolith that will be hard to split.
taberiand 19 hours ago [-]
That's my belief as well: modular architecture and separation of concerns is orthogonal to monolith <-> microservice infrastructure axis.
And Service Oriented Architecture is the nice middle ground of that infrastructure axis
derriz 17 hours ago [-]
I don’t agree. The technical device we use for creating clear boundaries, useful abstractions and managing dependencies in monolithic code is the function/method/procedure call.
The history of distributed software is littered with the corpses of attempts to make the RPC look like a function/method call (I worked for a CORBA vendor decades ago). But these two techniques are so different on a fundamental level they are not substitutable except in the most trivial cases. The compute and elapsed time RPC overhead which makes perfectly good local abstractions completely impractical across a network. And then there are the differences in terms of failure modes, concurrency and synchronicity.
So even a beautifully designed and layered piece of “monolithic” software with a code base costing of coherent and clean abstractions will not be easy to port to a microservices/distributed architecture.
strken 23 hours ago [-]
Big companies mostly seem to use the microservice(s) per team model. If your whole company is two founders, one account manager, and an engineer, you only have one team.
It can make sense to have more than one service for purely technical reasons. I once worked on a friend's startup where we built a separate ingress microservice so we could scale it independently from our monolith. There's no organisational benefit to doing so, however. The technical founder and the one engineer are hardly going to block each other.
vjvjvjvjghv 21 hours ago [-]
"Big companies mostly seem to use the microservice(s) per team model. "
I am good with that. What we often see is 10 microservices per team of 3 devs. And ideally using the same database.
masonhensley 21 hours ago [-]
I've seen a startup with 10 devs + 60+ microservices and growing.
The team was stuck in a mindset that they just hadn't split things up enough to arrive at nirvana.
jamesfinlayson 20 hours ago [-]
Been there before - I worked at a company where some geniuses thought that microservices would solve all of our scaling issues. We ended up with four microservices just to send an email (one to template, one to send, one to persist to database and one other which I can't remember now).
vjvjvjvjghv 8 hours ago [-]
That sounds like like they could just have used AWS Lambda instead of microservices.
jamesfinlayson 21 minutes ago [-]
This was all on-prem stuff. But it was taken to ridiculous extremes. I've worked on something that was a knot of message queues but there was one email service.
jonhohle 19 hours ago [-]
Multiple services using the same database will typically end poorly. When schemas or indexes change, how will that affect all of the different services? How do their read/write patterns differ? When one service needs to scale, will the additional connections starve the other services? And worse, if a service ends up moving to a different team or department, who controls the database?
I prefer a service that fronts the database. Swap the database, scale it, whatever, and clients keep going.
vjvjvjvjghv 8 hours ago [-]
"When schemas or indexes change, how will that affect all of the different services? "
It's absolutely horrible. Now all the services are tightly coupled without the devs really realizing this. And the side effects of database changes can be super subtle and hard to predict.
mcapodici 18 hours ago [-]
[dead]
wredcoll 21 hours ago [-]
Microservices are a solution to business/team organizational issues. Never technical ones.
strken 16 hours ago [-]
I think the example I gave is a good counterpoint:
- you have a monolith, and it handles normal API traffic patterns
- you have a workload that involves different hardware needs e.g. extremely high throughput relative to the rest of the system (video streaming would be an example), GPUs, high memory requirements with low CPU or vice versa, etc.
Solution is to deploy a service that only handles the specific workload. Whether or not this is a microservice probably depends on your point of view but I'd argue it's at least close.
onion2k 17 hours ago [-]
With microservices they're obviously complicated, and that's better. There's a complexity in monoliths as well, but it's hidden complexity. That gives developers a false impression that things are simpler.
For example, in microservices if you want some data that another service owns you have to define what it is, write an API, and handle all the fun of network problems. But once it's done you have a nice contract for getting that data.
In a monolith you can just reach over and take what you want. If you know there's a function for getting something you can use it. If you know the instantiated db connection has permission to view a row, just query the db directly. If you want to pipe some data somewhere just add it to the session object and it magically appears where you need it. And so on. You can go so fast! But then someone else does the same thing, and over time your monolith gets slower and slower, and needs more memory, and you find yourself having things on a god object that really shouldn't be there but it's hard to change because the behavior is threaded through everything.
Both of these problems are relatively simpler architectural issues, but it's always preferable to have well-defined complexity over accidental complexity. If you can define how code goes into a monolith and stick with those rules then a monolith is great. Most people can't, and I've never seen a company with multiple teams manage it.
dimaaan 16 hours ago [-]
You don't need network boundaries for good architecture. Split monolith into modules with an interface
onion2k 15 hours ago [-]
That's a modular monolith, not microservices. It's a nice architecture for dev but it comes with a downside that you need to deploy everything whenever there's a change. You usually end up with a complex release train process. Again, the complexity is still there, but it moves. Where your complexity lives is a choice.
sharadov 19 hours ago [-]
Yes start with a monolith but split it sooner than later ( was at a company where they realized it too late, after being in business for 8+ years) .
It was a nightmare at that point. We pretty much gave up.
Lio 16 hours ago [-]
I worked at a startup where a new architect decided everything needed to be split into micro services for “scaling”.
Thing is we were in an illiquid market that didn’t require the kind of scale he envisioned.
Long story short we burnt a hell of a lot of runway building something that was painful to work with compared to the monolith. It did not end well.
Micro services are something that sounds good to the inexperienced but are almost never right for an immature business looking for market fit.
If you really know you can’t scale with just a big box from the outset use something like Elixir or Erlang. Otherwise stick to a modular monolith for as long as you can.
sroussey 17 hours ago [-]
You can have microservices inside a monolith. It has the advantage of always deploying in a synced state.
misalliance 2 hours ago [-]
Very useful list. "If you build it, they will come" is one anti-pattern I try to avoid as a tech founder.
CM30 1 days ago [-]
Seems like a useful list of things to avoid when running a startup, plus situations where it may not always be a bad thing.
Still, got a few thoughts here:
> if you build it, they will come
This feels like the cause for so many news/media bundling services, akin to Blendle. Loads of people seem to have the thought process "no-one pays for journalism, that's because it's too inconvenient to subscribe seperately, let's bundle it all", but far fewer people actually seem to want such a service.
> Chasing Blue Oceans
This feels like the explanation for the Wii U, despite Nintendo obviously not being a startup of any kind. The Wii was a blue ocean product, and the company clearly thought the same logic could apply to its successor too. Find an idea that didn't have much competition (using a portable screen to control what's going on elsewhere), and use that to attract a new market.
Unfortunately, while the concept worked on a handheld device, it didn't really feel good to use on a larger scale, and the ideas designed for it (usually some sort of asymmetric gameplay experience) just didn't have the appeal that more traditional ones did.
> Boiling the Ocean
This seems really common with crowdfunded products, since if their scope isn't unrealistic as hell beforehand (and if it wants the public's attention and money, it usually is), it certainly is once the stretch goals start being added and the creators start promising everything and the kitchen sink.
Also with video games, as shown by Duke Nukem Forever, Beyond Good & Evil 2, etc.
pdpi 1 days ago [-]
> This feels like the explanation for the Wii U, despite Nintendo obviously not being a startup of any kind.
This is a particularly interesting example, because they followed up with the Switch, which is, in some ways, the diametric opposite of the Wii U. Arguably, what happened was that they had the right idea that the hybrid TV/handheld format was the right blue ocean play, but the Wii U failed by being TV first and handheld second, instead of handheld first and TV second. You could probably build a whole business strategy course on just this discussion.
CM30 1 days ago [-]
That's very true, the Switch feels like an improvement on the Wii U concept in many ways.
Though I feel the other big difference is that the Wii U Gamepad was highly limited in its capabilities. You could play games on it while other people watched TV or used that TV for something else, but you couldn't go beyond that. You still had to be close to the TV for it to function, and that usually meant being in the same room.
The Switch being a hybrid console meant you could take the whole thing outside of the room if others needed the space, or bring it with you to events or places outside of the home. So, it solved all the same problems the Wii U did (playing while others used the TV), but also a ton of more pressing ones (taking the game with you while traveling/leaving the house, playing in other rooms/areas, etc).
germandiago 21 hours ago [-]
I have a Switch 2, Nintendo user since I was very young, with the 8 bits NES, SNES, Game Boy, Nintendo 64... I would not change my Switch 2 for any PS5 or XBox, even if they are interesting :)
It is indeed a hybrid, but a very well-thought one I'd say.
annzabelle 20 hours ago [-]
I once played mario kart with the stranger sitting next to me on a plane with the switch.
terribleperson 1 days ago [-]
I don't think that's the real cause for the Wii U's woes. Consoles from the big players are almost automatic buys for a lot of people, just to get access to the new games. They have to screw up to change that. No one was particularly bothered by what the Wii U offered, even though it wasn't really compelling.
I hold that the Wii U was primarily an advertising problem, with a dash of the Wii itself being an anomaly.
bigcat12345678 20 hours ago [-]
I have done the startup thing as a failed founder and I myself call these startup patterns or antipatten mostly useless. One who enjoyed them (myself included) are destined to fail and then would concluded the same.
The so-called pattern and antipatten are useless for startup, is just like parenting guides are useless for new parents. The complexity and novel problems are so large in volume that only basic instinct function. And if you are the successful one, you would guide by whatever success brings you, if you are the failed one, well, you can fail and learned that these patterns are useless and rant here like myself.
In the end, don't destroy your health.
alpineman 17 hours ago [-]
That and luck plays a much bigger role than most would like to admit
mojuba 19 hours ago [-]
Sorry but I don't think you read any of the linked articles. Just one example of an anti-pattern that is very common and is undeniably harmful: Bad Revenue.
It comes down to deceiving or annoying your customers. E.g. making cancellation difficult or confusing, tricking the users into buying yearly subscription by showing them the monthly price of the yearly subscription (explicitly prohibited by Apple in mobile apps btw) and many others which can boost your revenue short-term but do a lot more harm in the long term, or eventually even kill your company.
These sales anti-patterns can work for bigger companies that are long past their growth stage and are now looking for ways to squeeze pennies out of every customer. Early stage or growth stage startups should not copy these practices: growth is a very fragile thing that can be destroyed by negative word of mouth easily.
brinepot 23 hours ago [-]
Yep, seen too many startups jump straight to Kubernetes and microservices before they even have a validated product. Ouch.
tikhonj 23 hours ago [-]
I worked at a startup that did this and it was... totally fine? Like, we hired a guy who knew how to set Kubernetes up, he spent like a week or two setting it up, and then it was totally solid and the development experience was great. I was building some of the core product-specific logic and it only made my life easier.
Which really just goes to show that the "legible" aspects matter far less than the illegible aspects. It's easy to say "hey, this startup is using boring technology and deploying a monolith, great!" or "Kubernetes and a bunch of services, over-complicated!". It's hard to say "hey, this startup's codebase is awful and it's an unforced error slowing them down" vs "hey, these guys are taking some shortcuts but it makes sense in context".
But a mess built on "boring", simple tech is going to derail you far more than a needlessly complex but well-executed setup.
taberiand 19 hours ago [-]
I remember reading an article years ago about how a company was running rings around its competition because they were releasing features faster and more effectively, due to their choice to use Lisp as their language. Of course a competitor who tried to pivot to Lisp was unlikely to have the same results - the specific language choice was not nearly as important as the fact that the founders were already experts in Lisp.
The point being, Kubernetes is easily the right choice for a start-up if you have a Kubernetes expert on the team (and the rest of the team is willing to put the time in learning the system and not just cargo-culting around it)
cpursley 17 hours ago [-]
Let me guess, VC funded start with plenty of cash to splash around and play with tech, beef up those resumes?
vjvjvjvjghv 21 hours ago [-]
Kubernetes is pretty ok if you keep things simple. The project I worked on had kubernetes set up years ago and from there on it just worked.
gps372 14 hours ago [-]
Useful list. Going through this list, I felt it would difficult to not fall for many of them. For example, you want to build enough to go to market early and gain customer validation and confidence but at the same time not build too much!!
Having a good experienced team generally helps in mitigating some of them, especially in tough situations.
sreekanth850 16 hours ago [-]
Platform risk is real. long back we decided to build a review management platform with Google as main. After building and getting early customers, we changed our office location that triggered to re apply for google business reviews account that ultimately blocked access to the API. They just sent an email saying we are not eligible for accessing Google Business profile API access.
e10jc 1 days ago [-]
Is there an N=1 anti-pattern on the list? I built an enterprise platform on a low 6 figure annual contract for my first customer. It’s looking like there are no other customers who desire the same type of platform.
pdpi 1 days ago [-]
Seems to be anti-pattern #4: If you build it, they will come. His description matches yours almost word for word.
> The founders automatically assumed that if they had the vision and one customer wanted it, many others would
FWIW I think it is miscategorized. "Build it and they will come" is a different type of problem: it commonly refers to building something thinking that its value and usefulness are self-evident that it will sell itself, and therefore one needs no sales or marketing.
ButlerianJihad 24 hours ago [-]
Look, this quote originated in a 1989 movie about ghosts and baseball.
The quote is from a ghostly, disembodied voice which encourages the protagonist to rip out their farm's corn crops and build a useless, pointless baseball field, in the middle of nowhere, so that the ghosts of dead players can come back to entertain people. The farm and the family are in financial trouble, and the bank wants to foreclose on the land, and so what has he got to lose?
The film has a happy ending, of course: the guy builds the field, and all the ghosts come, and the human fans come as well, and his new baseball field is a rousing financial success. Our protagonist has honored his father, a lifelong baseball fan, and he's provided for his family, in the most unlikely of business ventures, counseled by voices of the undead.
It seems weirdly missing the point to apply this to any real-world situations. You are essentially invoking a weird ghost story of baseball and utterly implausible fiction. This is not business advice, this is superstition. Field of Dreams protagonist in real life would've been hauled before a psychiatrist and medicated, and promptly served divorce papers along with the foreclosure.
xyzzy_plugh 20 hours ago [-]
> This is not business advice, this is superstition.
Precisely why the term is popular.
ghiculescu 1 days ago [-]
It’s the first item on the list.
Ozzie-D 22 hours ago [-]
[flagged]
exabrial 1 days ago [-]
"Pretending you are Google" Needs to be on there.
Scalability is not a problem: you have, you will have, you should plan for, you should build for, nor allow anyone to utter the S word. Simplicity is the correct word to use.
exabrial 1 days ago [-]
This falls into a broader category of disillusionment: "Pretend problems are the funnnest ones to solve", meaning, when the problem doesn't actually exist, any solution can be leveraged as the "right" one because there is no real world backpressure to test if it's effective.
Software Devs love solving pretend problems, and the state of modern web development reflects this.
CM30 1 days ago [-]
I suspect part of this (at least where software devs are concerned) is resume driven development. It's a lot easier to get hired at a top company if you've worked on similarly difficult problems before, while working with 'boring', simple technology makes your CV look uninteresting to a potential recruiter.
It also gives you a lot more free time if you can persuade your employer to let you use cutting edge technology rather than needing to save it for your side projects after hours.
Plus, given how many startups fail, you do kinda need a backup plan...
So, I suspect a lot of companies are... encouraged to aim for scale and encouraged to tackle problems in the most overcomplicated way possible so that the people working there can take their experience to Alphabet/Meta/Apple/whatever if things go south.
csallen 1 days ago [-]
I don't think that people are attracted to pretend problems for the sake of pretending.
I think it's more that people are attracted to tractable problems. We like to follow certain paths that are well-worn, where the next step is visible and easy to see. And whether those paths lead to a pretend/pointless destination is, surprisingly, irrelevant. They're easier to follow than whacking our way through the brush.
wredcoll 1 days ago [-]
> Software Devs love solving pretend problems, and the state of modern web development reflects this.
Are you kidding, have you seen the C programming language?!
anthonj 1 days ago [-]
The ridiculous things I was asked to do, and observed other people doing, all because "one day we will gave thousands of clients" while at the same time struggling to push out just a few units.
Gibbon1 1 days ago [-]
Up the Organization by Robert Townsend had this gem, not the exact quote but: big companies didn't get big by acting like big companies.
sebmellen 21 hours ago [-]
Wow, this is a very good site. I hope the see the other articles filled in at some point.
a_c 11 hours ago [-]
Hiring for specific skills
Wren_ops 24 hours ago [-]
Obsessing over microservices before product market fit is a common, expensive trap. Just use a monolith, please.
antonvs 17 hours ago [-]
> Designing for investors
That entry isn’t published yet, but… this can be a viable tactic as part of a larger strategy. I’ve seen people raise significant money by designing for investors, and it got them to where they wanted to be.
threethirtytwo 1 days ago [-]
Python is an anti pattern.
Nodejs + typescript is superior across almost every dimension other than data science and familiarity.
People think it’s apples and oranges but it’s not. Also don’t forget golang too.
If your app is Python in the beginning then you’re pretty much locked in. It’s doable, but you’re going to be dealing with a lot of Python specific warts.
awithrow 1 days ago [-]
Python is a perfectly fine choice for a tech stack. Just because you don't like something doesn't make it an anti-pattern. NodeJs + TypeScript have tons of warts of their own that you have to deal with as well. Every language does.
jagged-chisel 22 hours ago [-]
There are two types of programming languages: those people complain about, and those no one uses.
threethirtytwo 22 hours ago [-]
There’s a third type of language: Python. Actual poor choice for a startup, independent of complaints.
You’ll note my complaint here is actually remarkably unique. You will rarely hear a person who is an expert in both TS and Python say definitively TS is better.
Many people who know both stacks well always maintains some kind of apples and oranges opinion about it. It’s like agnosticism.
threethirtytwo 22 hours ago [-]
Nah but the warts are minor compared with other languages. Python is guaranteed to hold you back.
First it’s the worst performing language for the application stack (only among the most languages for that area). Second type checking on Python is raw garbage.
Third you’re going to have to use TS for the frontend anyway. You can’t escape ts. Choosing Python(or any other language) forces you to have redundant code in two languages. Ts is the overall best startup stack and a huge part of it is because the frontend requires ts anyway.
Also sqlalchemy is pretty garbage.
joshheitzman 21 hours ago [-]
> Third you’re going to have to use TS for the frontend anyway. You can’t escape ts.
This is obviously wrong. Sure you have to use Javascript for the web frontend that has interactivity without round-tripping to the server. Typescript compiles to Javascript, but its hardly the only language that does.
If you're frontend is a mobile app only then you don't even have to use Javascript for it all.
threethirtytwo 8 hours ago [-]
I’m talking about mainstream choices. I’m well aware of alternatives.
Would not recommend alternative choices for a startup. Those offer a larger element of risk. I would choose Python over any other non mainstream alternative.
lungeloslx 19 hours ago [-]
Wow. I cannot believe in good ‘ol 2026 there are still people who believe a whole successful programming language could be the reason for a failed experiment (startup). If your startup is solving a real problem, choosing the “wrong” language could never be the reason it fails.
threethirtytwo 8 hours ago [-]
Except I never said it’s the whole reason for a failed startup. You’re just making shit up out of thin air.
Choosing a wrong language can be a factor for failure. This is possible but rare. For example choosing Python for a triple A game engine.
Mostly choosing the wrong language results in pain and friction and extra work. These things are enough for me to consider a choice wrong. You don’t need the language to bring down the entire startup for me to consider to to be wrong.
For example if you chose nodejs. One application server instance is enough to serve the website and scale for a couple years. If you chose flask… well… setting that up for the same scale would be complicated. Your choice here is proportional to the amount of pain you feel later.
nojs 1 days ago [-]
No, caring too much about the language and not the problem is the anti pattern
threethirtytwo 22 hours ago [-]
Thinking that the stack/language is not intrinsically tied to the problem and smart ass quotations define reality is the bigger problem.
Go use Python for your triple A next gen game rendering engine.
magarnicle 20 hours ago [-]
Go use Nodejs + typescript for it. Why pick on just Python?
threethirtytwo 8 hours ago [-]
It’s just an example on how the language matters. And of course in that case nodejs would also be the wrong choice.
All in all we’re mostly talking about the web stack.
vjvjvjvjghv 21 hours ago [-]
Python is ok. People get used to it.
The biggest antipattern in my view is using different stacks for different services.
barapa 1 days ago [-]
A startup is not the code
joshheitzman 22 hours ago [-]
That's AI.
That's the most flattering thing I can think of to say about statements that are so confidently wrong.
dtnm 23 hours ago [-]
>locked in
Every tech choice is a lock in.
threethirtytwo 22 hours ago [-]
This is true. I guess I’m saying if you locked yourself into Python you’re locking yourself into a lot of pain. Much more pain than other choices.
It’s like php. Facebook got locked into php and had to develop a whole new language around it.
q8zd3 1 days ago [-]
Any stack has its own warts.
threethirtytwo 22 hours ago [-]
The Python stack is a huge wart. First performance is shit. Second type checking is shit.
The only benefit is familiarity and data science. That’s literally it. No one in this thread has stated any benefit Python brings to the table on top of other popular web application languages.
I guess ruby is a worse choice.
q8zd3 8 hours ago [-]
I don't see how it's a bad choice on its own merit. Lang choice will always be a mixture of familiarity (team or individual) and niche problem needs (some edge cases need specific tools).
I personally avoid to touch anything that is nodejs related because I do not trust its ecosystem (npms).
threethirtytwo 5 hours ago [-]
the python ecosystem is just as easily compromise-able.
tartieret 21 hours ago [-]
having built two enterprise data platforms in python, I can't disagree more. for a startup, development velocity matters more than code performance especially for a CRUD app even at medium scale. Frameworks like Django simply enable you to do so much and so quickly. and you can reach world scale, that's what Instagram did!
threethirtytwo 8 hours ago [-]
Having built more than two enterprise apps in Python and many others in many other languages I can say it is certainly possible to build it in Python. But it is one of the worst choices out of all possible languages out of all the other mainstream languages.
Django is fast but has become much less relevant in the age of AI. The issue with Django is you hit issues very early. Within 2 to 3 years of using Django the warts of using Django become apparent. Django is mostly a good tool for the first year, but if the tool survives beyond that, Django becomes more of a liability.
You get 80 percent of the convenience of Django with just popular nodejs libs like prisma, zod and express. Once you add in LLS it’s 100 percent.
elendilm 23 hours ago [-]
Validation is shorthand for saying "I don't have deterministic skills or knowledge hence I will rely on user behaviour to drive the product".
Works out for many people and usually ideal for beginners. But post a couple of years, if validation is still your primary model, your model tells you how clueless you are in your domain.
Make logical derivations. Build. Determinism is a luxury only affordable for the ones who put in the effort. Others are doomed to chase validation for eternity.
How do I, as a founder, know that I am falling into an anti pattern? I don’t believe it is possible to know. You can only “know” in hindsight and that makes these anti patterns useless.
The easiest way is to have outside advisors who can and are willingto adversarially challenge the assumptions you're making. If you don't have those, good cofounders can sometimes play the same role (although that is harder since they are likely to share similar biases as you).
Its a bit like cooking advice
- Products should be fresh
- Use the best ingredients
- Salt early and correctly
- Cook by temperature, not time
And so on but then you cook side by side with a pro chef...and does not taste the same...
https://en.wikipedia.org/wiki/List_of_cognitive_biases
Most people start a small business for tax reasons, and the few lucky loud clowns claiming hyper-scaling BS is sustainable simply disappear within 5 years.
Best advice, answer the simple question "will random people buy this when no one is looking?"... if you have to explain/sell a product/service more than 5 seconds, than that business model likely isn't sustainable.
I also see a lot of smart folks that think they will get paid for excuses... only lawyers, PR, and politicians are in that business. =3
For B2c, maybe. B2B is very different - they aren't going to make up their mind in 5 seconds and you aren't going to have a product that can be explained in 5s.
If not, than one is explaining/selling again, and you will only ever have 2.7%*(time/sales_pitch_time) customers. Letting client/customers dictate the terms of a product/service often will just turn your business into a staffing agency.
B2B is actually more risk, as any deal exceeding 12% of revenue sets a timer on how long your business will likely survive. Some unlucky folks also end up acting as a product warehouse for clients, contract labor, or a scapegoat for client internal strategic mistakes.
If people can't summarize what they do in 1 sentence, than they likely have a fuzzy definition for a business project goal. For example, people that use more than 4 conditional statements (if/but/when etc.) to describe something, than I have observed they often last less than 3 years regardless of cash burn rates. =3
I broadly agree with your point, but disagree with this sentence. IME a 1-sentence business goal is almost certainly too fuzzy to be useful. There's nothing actionable about "We help you survive audits and readiness for regulation $FOO", which is frequently the business goal.
And the people that study these types of lists to apply it to their own case are then engaging in “analysis paralysis” because the list is so long you are bound to be caught up by it.
So while I think it is useful to critique your idea and business the best thing to do is to try and sell it and make money and keep adjusting and trying new things to maximize your income. There is no magic bullet.
Doubly so if they are mediocre to start with and triple so if they bring with them their legion of yes-men.
One reason is that microservice architecture requires much more operational overhead. So any server we have (except for the database) should be self-contained as a rule, so that it can be autonomous and horizontally scalable.
So far, it is working quite well. You do not need suddenly a Redis for one thing, a ZooKeeper for the next one, and 3 or 4 things to just run the damn binaries. The binaries will start, do whatever migrations need to be done if it applies, and start running. They only need the database. They land health checks, api calls and all the logic needed, in one binary with zero dependencies that is containerized.
This has saved me a lot of pain compared to other architectures where I worked, but those were massive and it was justified (and there was budget for it). But you just need a bunch of teams to be able to do that.
I think going the microservices way for a small team not only does not pay off. I think it can be a suicide.
At the same time, I keep the servers internally modular (enable/disable feature).
So the key here is good engineering leadership to recognize when that point arrives, and push the company to start the transition.
And indeed, microservices solve a organization problem not an engineering problem. When I taught the architecture to new hires, I always say: a service is the largest piece of system that stays together in a reorg :)
And Service Oriented Architecture is the nice middle ground of that infrastructure axis
The history of distributed software is littered with the corpses of attempts to make the RPC look like a function/method call (I worked for a CORBA vendor decades ago). But these two techniques are so different on a fundamental level they are not substitutable except in the most trivial cases. The compute and elapsed time RPC overhead which makes perfectly good local abstractions completely impractical across a network. And then there are the differences in terms of failure modes, concurrency and synchronicity.
So even a beautifully designed and layered piece of “monolithic” software with a code base costing of coherent and clean abstractions will not be easy to port to a microservices/distributed architecture.
It can make sense to have more than one service for purely technical reasons. I once worked on a friend's startup where we built a separate ingress microservice so we could scale it independently from our monolith. There's no organisational benefit to doing so, however. The technical founder and the one engineer are hardly going to block each other.
I am good with that. What we often see is 10 microservices per team of 3 devs. And ideally using the same database.
The team was stuck in a mindset that they just hadn't split things up enough to arrive at nirvana.
I prefer a service that fronts the database. Swap the database, scale it, whatever, and clients keep going.
It's absolutely horrible. Now all the services are tightly coupled without the devs really realizing this. And the side effects of database changes can be super subtle and hard to predict.
- you have a monolith, and it handles normal API traffic patterns
- you have a workload that involves different hardware needs e.g. extremely high throughput relative to the rest of the system (video streaming would be an example), GPUs, high memory requirements with low CPU or vice versa, etc.
Solution is to deploy a service that only handles the specific workload. Whether or not this is a microservice probably depends on your point of view but I'd argue it's at least close.
For example, in microservices if you want some data that another service owns you have to define what it is, write an API, and handle all the fun of network problems. But once it's done you have a nice contract for getting that data.
In a monolith you can just reach over and take what you want. If you know there's a function for getting something you can use it. If you know the instantiated db connection has permission to view a row, just query the db directly. If you want to pipe some data somewhere just add it to the session object and it magically appears where you need it. And so on. You can go so fast! But then someone else does the same thing, and over time your monolith gets slower and slower, and needs more memory, and you find yourself having things on a god object that really shouldn't be there but it's hard to change because the behavior is threaded through everything.
Both of these problems are relatively simpler architectural issues, but it's always preferable to have well-defined complexity over accidental complexity. If you can define how code goes into a monolith and stick with those rules then a monolith is great. Most people can't, and I've never seen a company with multiple teams manage it.
It was a nightmare at that point. We pretty much gave up.
Thing is we were in an illiquid market that didn’t require the kind of scale he envisioned.
Long story short we burnt a hell of a lot of runway building something that was painful to work with compared to the monolith. It did not end well.
Micro services are something that sounds good to the inexperienced but are almost never right for an immature business looking for market fit.
If you really know you can’t scale with just a big box from the outset use something like Elixir or Erlang. Otherwise stick to a modular monolith for as long as you can.
Still, got a few thoughts here:
> if you build it, they will come
This feels like the cause for so many news/media bundling services, akin to Blendle. Loads of people seem to have the thought process "no-one pays for journalism, that's because it's too inconvenient to subscribe seperately, let's bundle it all", but far fewer people actually seem to want such a service.
> Chasing Blue Oceans
This feels like the explanation for the Wii U, despite Nintendo obviously not being a startup of any kind. The Wii was a blue ocean product, and the company clearly thought the same logic could apply to its successor too. Find an idea that didn't have much competition (using a portable screen to control what's going on elsewhere), and use that to attract a new market.
Unfortunately, while the concept worked on a handheld device, it didn't really feel good to use on a larger scale, and the ideas designed for it (usually some sort of asymmetric gameplay experience) just didn't have the appeal that more traditional ones did.
> Boiling the Ocean
This seems really common with crowdfunded products, since if their scope isn't unrealistic as hell beforehand (and if it wants the public's attention and money, it usually is), it certainly is once the stretch goals start being added and the creators start promising everything and the kitchen sink.
Also with video games, as shown by Duke Nukem Forever, Beyond Good & Evil 2, etc.
This is a particularly interesting example, because they followed up with the Switch, which is, in some ways, the diametric opposite of the Wii U. Arguably, what happened was that they had the right idea that the hybrid TV/handheld format was the right blue ocean play, but the Wii U failed by being TV first and handheld second, instead of handheld first and TV second. You could probably build a whole business strategy course on just this discussion.
Though I feel the other big difference is that the Wii U Gamepad was highly limited in its capabilities. You could play games on it while other people watched TV or used that TV for something else, but you couldn't go beyond that. You still had to be close to the TV for it to function, and that usually meant being in the same room.
The Switch being a hybrid console meant you could take the whole thing outside of the room if others needed the space, or bring it with you to events or places outside of the home. So, it solved all the same problems the Wii U did (playing while others used the TV), but also a ton of more pressing ones (taking the game with you while traveling/leaving the house, playing in other rooms/areas, etc).
It is indeed a hybrid, but a very well-thought one I'd say.
I hold that the Wii U was primarily an advertising problem, with a dash of the Wii itself being an anomaly.
The so-called pattern and antipatten are useless for startup, is just like parenting guides are useless for new parents. The complexity and novel problems are so large in volume that only basic instinct function. And if you are the successful one, you would guide by whatever success brings you, if you are the failed one, well, you can fail and learned that these patterns are useless and rant here like myself.
In the end, don't destroy your health.
It comes down to deceiving or annoying your customers. E.g. making cancellation difficult or confusing, tricking the users into buying yearly subscription by showing them the monthly price of the yearly subscription (explicitly prohibited by Apple in mobile apps btw) and many others which can boost your revenue short-term but do a lot more harm in the long term, or eventually even kill your company.
These sales anti-patterns can work for bigger companies that are long past their growth stage and are now looking for ways to squeeze pennies out of every customer. Early stage or growth stage startups should not copy these practices: growth is a very fragile thing that can be destroyed by negative word of mouth easily.
Which really just goes to show that the "legible" aspects matter far less than the illegible aspects. It's easy to say "hey, this startup is using boring technology and deploying a monolith, great!" or "Kubernetes and a bunch of services, over-complicated!". It's hard to say "hey, this startup's codebase is awful and it's an unforced error slowing them down" vs "hey, these guys are taking some shortcuts but it makes sense in context".
But a mess built on "boring", simple tech is going to derail you far more than a needlessly complex but well-executed setup.
The point being, Kubernetes is easily the right choice for a start-up if you have a Kubernetes expert on the team (and the rest of the team is willing to put the time in learning the system and not just cargo-culting around it)
Having a good experienced team generally helps in mitigating some of them, especially in tough situations.
> The founders automatically assumed that if they had the vision and one customer wanted it, many others would
https://www.itamarnovick.com/startup-anti-pattern-4-if-you-b...
https://en.wikipedia.org/wiki/Field_of_Dreams
The quote is from a ghostly, disembodied voice which encourages the protagonist to rip out their farm's corn crops and build a useless, pointless baseball field, in the middle of nowhere, so that the ghosts of dead players can come back to entertain people. The farm and the family are in financial trouble, and the bank wants to foreclose on the land, and so what has he got to lose?
The film has a happy ending, of course: the guy builds the field, and all the ghosts come, and the human fans come as well, and his new baseball field is a rousing financial success. Our protagonist has honored his father, a lifelong baseball fan, and he's provided for his family, in the most unlikely of business ventures, counseled by voices of the undead.
It seems weirdly missing the point to apply this to any real-world situations. You are essentially invoking a weird ghost story of baseball and utterly implausible fiction. This is not business advice, this is superstition. Field of Dreams protagonist in real life would've been hauled before a psychiatrist and medicated, and promptly served divorce papers along with the foreclosure.
Precisely why the term is popular.
Scalability is not a problem: you have, you will have, you should plan for, you should build for, nor allow anyone to utter the S word. Simplicity is the correct word to use.
Software Devs love solving pretend problems, and the state of modern web development reflects this.
It also gives you a lot more free time if you can persuade your employer to let you use cutting edge technology rather than needing to save it for your side projects after hours.
Plus, given how many startups fail, you do kinda need a backup plan...
So, I suspect a lot of companies are... encouraged to aim for scale and encouraged to tackle problems in the most overcomplicated way possible so that the people working there can take their experience to Alphabet/Meta/Apple/whatever if things go south.
I think it's more that people are attracted to tractable problems. We like to follow certain paths that are well-worn, where the next step is visible and easy to see. And whether those paths lead to a pretend/pointless destination is, surprisingly, irrelevant. They're easier to follow than whacking our way through the brush.
Are you kidding, have you seen the C programming language?!
That entry isn’t published yet, but… this can be a viable tactic as part of a larger strategy. I’ve seen people raise significant money by designing for investors, and it got them to where they wanted to be.
Nodejs + typescript is superior across almost every dimension other than data science and familiarity.
People think it’s apples and oranges but it’s not. Also don’t forget golang too.
If your app is Python in the beginning then you’re pretty much locked in. It’s doable, but you’re going to be dealing with a lot of Python specific warts.
You’ll note my complaint here is actually remarkably unique. You will rarely hear a person who is an expert in both TS and Python say definitively TS is better.
Many people who know both stacks well always maintains some kind of apples and oranges opinion about it. It’s like agnosticism.
First it’s the worst performing language for the application stack (only among the most languages for that area). Second type checking on Python is raw garbage.
Third you’re going to have to use TS for the frontend anyway. You can’t escape ts. Choosing Python(or any other language) forces you to have redundant code in two languages. Ts is the overall best startup stack and a huge part of it is because the frontend requires ts anyway.
Also sqlalchemy is pretty garbage.
This is obviously wrong. Sure you have to use Javascript for the web frontend that has interactivity without round-tripping to the server. Typescript compiles to Javascript, but its hardly the only language that does.
If you're frontend is a mobile app only then you don't even have to use Javascript for it all.
Would not recommend alternative choices for a startup. Those offer a larger element of risk. I would choose Python over any other non mainstream alternative.
Choosing a wrong language can be a factor for failure. This is possible but rare. For example choosing Python for a triple A game engine.
Mostly choosing the wrong language results in pain and friction and extra work. These things are enough for me to consider a choice wrong. You don’t need the language to bring down the entire startup for me to consider to to be wrong.
For example if you chose nodejs. One application server instance is enough to serve the website and scale for a couple years. If you chose flask… well… setting that up for the same scale would be complicated. Your choice here is proportional to the amount of pain you feel later.
Go use Python for your triple A next gen game rendering engine.
All in all we’re mostly talking about the web stack.
The biggest antipattern in my view is using different stacks for different services.
That's the most flattering thing I can think of to say about statements that are so confidently wrong.
Every tech choice is a lock in.
It’s like php. Facebook got locked into php and had to develop a whole new language around it.
The only benefit is familiarity and data science. That’s literally it. No one in this thread has stated any benefit Python brings to the table on top of other popular web application languages.
I guess ruby is a worse choice.
I personally avoid to touch anything that is nodejs related because I do not trust its ecosystem (npms).
Django is fast but has become much less relevant in the age of AI. The issue with Django is you hit issues very early. Within 2 to 3 years of using Django the warts of using Django become apparent. Django is mostly a good tool for the first year, but if the tool survives beyond that, Django becomes more of a liability.
You get 80 percent of the convenience of Django with just popular nodejs libs like prisma, zod and express. Once you add in LLS it’s 100 percent.
Works out for many people and usually ideal for beginners. But post a couple of years, if validation is still your primary model, your model tells you how clueless you are in your domain.
Make logical derivations. Build. Determinism is a luxury only affordable for the ones who put in the effort. Others are doomed to chase validation for eternity.