
The Entrepreneur Trilemma
Your co-founder got a brilliant idea to solve the problem of saving all the kitties in the world. Fantastic! He raises the money and you take care of building the product.
He gets just enough to run for 3 months. Your idea is to create a kitten-rescue team and then a market place for kitties to give them in adoption. Then your co-founder asks you for a mobile app, a web app, with a cool design, and ask you do get it done in ONE month, because “each second our idea is not built a kitten dies!”.
You can only have 2 options between Cheap, Fast and Good. Welcome to the Entrepreneur’s Trilemma.
Think about the project you’re working on right now at your job. What project you’re working on right now? Is this your project or you’re working for someone? Really it doesn’t matter, because you will still have to pick only 2 options. That’s called project-management trilemma.
The Project-Management Trilemma
Any project can be fast, cheap or good, it can be only 2 of them at any given time.
These triangle models are called trilemma, they’re used to understand and solve different types of problems across systems, and even social situations.
The CAP Theorem
A common triangle model is the CAP theorem: a distributed system can be only 2 of the following: Consistent, Available or Partition tolerant.
Databases such as Cassandra offer availability, partition tolerance, and “eventual consistency”. A nice way to prioritize the most important two and “eventually” to get the third one.

The Blockchain Trilemma
In blockchain or in general in any DLT, the trilemma is between Decentralization, Scalability, and Security. When you hear about a blockchain that is faster than Bitcoin and with the same security, you know for a fact that is more centralized, and therefore not censor resistant.
The Drama Triangle
You may have not heard of the drama triangle, but you definitely lived through it many times, in different situations. You were late to complete a project and your boss blamed you. You were the victim, your boss the persecutor.

In a partnership relationship, during different arguments, you often jump from one role to the other. The way you avoid the drama is choosing to stay in the center of the triangle, basically choosing no option. This requires self-awareness and maturity.
Try to recognize your role and the role of your partner next time you have an argument.
The Entrepreneur Trilemma
OK. Let’s get back to our initial problem. When you’re working on a project you have to pick between fast, good and cheap. Like in the CAP theorem, you need all of three at some point, as an entrepreneur, you’ll have to choose fast, cheap, and “eventually good”.

Divide and Conquer
Understand the problem you’re solving better than anyone else, that includes researching and building quick prototypes, to better understand the problem and to test the (cheap-fast) solution.
Once you understand the problem well, you want to divide and conquer, breaking down the problem into more manageable components. The scaffolding (or foundation) that keeps those components together must be really solid and good.

When doing divide and conquer at the application layer and even at the infrastructure layer, make sure you’re following the SOLID principles. In brief, those are principles to design architectures that are modular, so that you can build a component in a cheap way, and later replaced it with a good component.
Functional Layers
Your first divide and conquer should be dividing UI, backend. And have them communicating via API. In the UI layer, you may want to use React or Angular. In the backend, go for the language you’re more comfortable with.
Monolith vs Microservices
Another divide and conquer opportunity is in the backend. You can divide your APIs into a monolith (with components) or into microservices.
5 years ago I’d suggest you going monolithic to start. Today I suggest starting microservice from day one.
Infrastructure as a Service is mature, serverless solutions and container orchestration solutions allow to build microservices architecture very easily, quickly and cheaply.
Designing a good architecture is very difficult, it requires experience and knowledge. So before jumping into it, read all the possible contents about microservice from Martin Fowler’s blog, and learn as much as you can from someone who went through the pain of running microservices in production.
Buy vs Build
This is a question that will come at any step of the development, and it will come up in different forms.
At the application layer, most of the time you want to use open source packages. At the infrastructure level, you may have to actually buy a service, such as GCP or AWS.
Save the kittens
Did I mention that you need to have a “Why”, a “How”, and a “What”?
Your “Why”, or vision, is to save the kittens. Your “How”, or mission is how you’re going to save them which means you’ll need to have a kitten rescue team, then a market place where you can adopt the kitten, a customer support line, etc.
In this blog post, we focused only on the implementation, or the “What”. Remember that any successful business always starts with the Why.
Now that you got new mental models and tools, go building a startup and start saving those kittens.
