Trap
Clean Architecture is one of the most overrated things at the start. And one of the most underrated over time. The problem is that it is either idolized or completely ignored. Both options are mistakes. I have seen projects where a small team on a simple product built a full-fledged DDD with Clean Architecture, a bunch of layers and interfaces. The result: slow development, not everyone understands the structure, high entry threshold. And the main question is - why?
MVP does not need Clean
If you have a startup with 1-2 people and you're writing an MVP, you don't need Clean Architecture. At all. Your task at this stage is to quickly test the hypothesis, roll out features, and understand if there is a product at all. In this context, layers, DTOs, interfaces, and domain separation are just a slowdown.
Many try to "do it right from the start so they don't have to redo it later." Sounds logical. In practice — no. You don't know what the product will be like, where the load will be, and what will remain. And you start designing for a future that doesn't exist yet.
Where Clean is Really Needed
Clean Architecture is needed when the product grows, a team forms, turnover begins, and the code lives for a long time. In this scenario, it provides a predictable structure, quick onboarding, and manageable changes. A simple guideline: if a new developer gets up to speed with the project in 1–2 weeks, the architecture works. If not, you've just overcomplicated things.
There is also the opposite extreme: "we don't need Clean at all" — and they continue to grow. Then real problems begin: the code expands, dependencies intertwine, and changes become expensive. At some point, you have to rewrite.
Evolution, not religion
The right approach is evolution. Start with simple code, a quick MVP. Then comes understanding, bottlenecks, and only then is structure introduced. Clean Architecture is not a "switch on a flag." You don't have to do everything at once: domain, DTO, mappers, repositories. You come to this when there is a real need.
And yes, it's better to write tests right away, as they allow you to safely change the code and gradually introduce structure. The main question is always: does this speed up development now or slow it down? Developer maturity is not about "always doing it right." It's about understanding when exactly it is needed.
