Why I stopped overengineering my projects
A note about moving from oversized architectures to small, measurable prototypes closer to real problems.
The old mistake
When you want to prove you are technical, the temptation is to add pieces: multi-tenancy, queues, gateways, microservices, dashboards, automations, complex deployments.
The result may look more professional, but it often hides an unanswered question: does anyone really need this thing?
The new rule
First I build the smallest version that makes the problem visible.
If I need to validate a tool for a warehouse workflow, I do not need a huge infrastructure first. I need to understand the data, the friction point, and the person who will use the tool.
What I keep
This does not mean ignoring quality. It means moving quality where it matters:
- clear data model
- readable code
- simple interfaces
- testable logic
- understandable deployment
What I remove
I remove words that currently make me sound bigger than the project: enterprise, production-ready, scalable infrastructure. I will bring them back when they are true, not when they decorate a page.