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.
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.
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.
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.
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).
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
I hold that the Wii U was primarily an advertising problem, with a dash of the Wii itself being an anomaly.
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.
> 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...
Software Devs love solving pretend problems, and the state of modern web development reflects this.
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.
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.
Are you kidding, have you seen the C programming language?!
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.
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.
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).
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.
Go use Python for your triple A next gen game rendering engine.
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.
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.
It’s like php. Facebook got locked into php and had to develop a whole new language around it.
It is indeed a hybrid, but a very well-thought one I'd say.
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.
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.
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.
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.
Precisely why the term is popular.
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.
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).
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.
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 was a nightmare at that point. We pretty much gave up.
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.
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)
I am good with that. What we often see is 10 microservices per team of 3 devs. And ideally using the same database.
And Service Oriented Architecture is the nice middle ground of that infrastructure axis
I prefer a service that fronts the database. Swap the database, scale it, whatever, and clients keep going.
The team was stuck in a mindset that they just hadn't split things up enough to arrive at nirvana.
An anti-pattern is a commonly used process, structure, or pattern of action that, despite initially appearing to be an appropriate and effective response to a problem, has more bad consequences than good ones.
Simeon Simeonov first wrote an introduction to the value of startup anti-patterns back in 2013. To sum it up, it’s hard to pinpoint the exact set of reasons startups succeed, but experienced entrepreneurs and investors have a good sense of what drives startups’ failures.
Startup anti-patterns are all about that — patterns that increase the risks associated with startups (hey, it’s a risky business to begin with). Pursuing an anti-pattern doesn’t mean that your company will die tomorrow or in the next year, but each anti-pattern adds-up and could lead to clouding your focus and hampering your ability to execute.
Together with Itamar Novick from Recursive Ventures, Simeon Simeonov is bringing the Startup anti-pattern series to life. Stay tuned for more in this series as we work through each anti-pattern with tangible examples from our experiences as founders and investors in 100+ startups, and the experiences of guest founders from our portfolio.
Note: the list is not “drawn to scale.” Some anti-patterns occur more frequently than others and some are more likely to cause a startup to fail than others.