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.
Startup Anti-Patterns
81–90 of 102 posts
Re: Startup Anti-Patterns
#82Some 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.
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.
Re: Startup Anti-Patterns
#83Earlier quoted context omitted.
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…
You don't need network boundaries for good architecture. Split monolith into modules with an interface
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.
Re: Startup Anti-Patterns
#84Such 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.
or worse, what if an anti-pattern is "your" way to success
Re: Startup Anti-Patterns
#85Hiring 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.
Re: Startup Anti-Patterns
#86Useful 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.
Re: Startup Anti-Patterns
#87Such 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.
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...
Re: Startup Anti-Patterns
#88Hiring for specific skills
Re: Startup Anti-Patterns
#89Hiring 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.
[deleted]
Re: Startup Anti-Patterns
#90Earlier quoted context omitted.
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 tw…
> 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.
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.