Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Startup Anti-Patterns

itamarnovick.com

Post reply on HN
Print view View original

61–70 of 102 posts

Re: Startup Anti-Patterns

#61

Post by lungeloslx »

threethirtytwo wrote: post #7

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.

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.

Re: Startup Anti-Patterns

#62

Post by taberiand »

plmpsu wrote: post #58
HeavenFox wrote: post #50

Earlier quoted context omitted.

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…

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.

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

Re: Startup Anti-Patterns

#63

Post by taberiand »

tikhonj wrote: post #31
brinepot wrote: post #28

Yep, seen too many startups jump straight to Kubernetes and microservices before they even have a validated product. Ouch.

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 aspe…

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)

Re: Startup Anti-Patterns

#64

Post by mojuba »

bigcat12345678 wrote: post #57

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 f…

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.

Re: Startup Anti-Patterns

#65

Post by jonhohle »

vjvjvjvjghv wrote: post #47
strken wrote: post #33

Earlier quoted context omitted.

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 t…

"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.

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.

Re: Startup Anti-Patterns

#66

Post by lelanthran »

Joel_Mckay wrote: post #12
saimiam wrote: post #11

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.

It takes understanding your own impulses and cognitive biases. 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 mor…

> 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.

Re: Startup Anti-Patterns

#67

Post by sharadov »

1saadcodes wrote: post #30

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

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.

Re: Startup Anti-Patterns

#69

Post by Joel_Mckay »

lelanthran wrote: post #66
Joel_Mckay wrote: post #12

Earlier quoted context omitted.

It takes understanding your own impulses and cognitive biases. 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 mor…

> 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.

>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

Re: Startup Anti-Patterns

#70

Post by mcapodici »

vjvjvjvjghv wrote: post #47
strken wrote: post #33

Earlier quoted context omitted.

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 t…

"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.

[dead]
Post reply on HN