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.

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.

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.

Doubly so if they are mediocre to start with and triple so if they bring with them their legion of yes-men.

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.

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.

Having a good experienced team generally helps in mitigating some of them, especially in tough situations.

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.

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.

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.

I hold that the Wii U was primarily an advertising problem, with a dash of the Wii itself being an anomaly.

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 :)

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.

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.

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.