Choosing a technology stack for your product without the obsession
Arguing over the "best framework" is usually wasted time. The criteria that matter more are the team, the product's lifespan, the cost of change and replaceability. Here is a decision framework.
One of the most repeated debates in technical teams is: "What should we build it with?" It can take weeks, and in the end the user never asks what the product was built with.
First: how irreversible is this decision
Not all choices weigh the same. Separate two kinds:
- Hard-to-reverse decisions. The main database, the data model, the core language. They are costly to change and need care.
- Easy-to-reverse decisions. The UI library, the email service, the testing tool. If the layers are separated properly, swapping them is cheap.
Don't spend much time on the second kind. For the first, record the decision.
The criteria that really matter
| Criterion | Question |
|---|---|
| Team ability | Has the team worked with this already, or must it learn? |
| Talent market | If the team changes, is it easy to find people for it? |
| Product lifespan | How many years must it be supported? Is the technology alive and maintained? |
| Ecosystem | Does it have libraries, documentation and an active community? |
| Special requirements | Local hosting, limited networks, Persian and right-to-left |
| Running cost | Do hosting and scale fit your budget? |
| Replaceability | If needed, how painful is swapping it out? |
Common traps
- Choosing by excitement. A new technology is attractive, but you pay for the unknowns.
- Building for scale you don't have. An architecture for millions of users for a product with a hundred.
- Imitation. "Company X uses it", but their conditions and team differ from yours.
- Lock-in. Deep dependence on one service with no way out.
- Ignoring the runtime environment. A service that is unavailable or restricted where you operate.
A simple way to decide
- Write the non-negotiable requirements.
- Pick two or three realistic options, not ten.
- Build a narrow trial: the smallest real flow with each option.
- Write down the decision and the reason.
- Set a date to review it.
Separate the layers so choices carry less risk
If business logic doesn't depend on a particular service, replacing it becomes possible. That is the principle of ports and adapters: hide the outside behind an interface so easy-to-reverse decisions stay easy. And to begin with, a simple, correct architecture beats a large, vague one.
What not to debate
Cosmetic taste, line counts, "cleaner" with no criterion, and popularity on social media. None of these matter to the user or the business.
The takeaway
The best technology is the one your team knows, that suits the product's lifespan and that can be replaced if necessary. Take hard-to-reverse decisions deliberately and write them down, decide the rest fast, and keep the layers separate.
To design the architecture and choose technology for your product, start a conversation.