SaaSArchitectureSimplicityBuild in Public

Why I stopped overengineering my projects

I used to add pieces to look smart. Now I build the smallest version that makes the problem visible.

Published April 12, 20261 min read
Why I stopped overengineering my projects

The old mistake

I wanted to look technical. So I kept adding stuff.

Multi-tenancy. Queues. Gateways. Microservices. Dashboards. Automations. Deployments I couldn't even explain myself.

It looked professional. Really I was just dodging the actual question: does anyone need this thing?

The new rule

Now I build the smallest version that makes the problem visible. That's it.

Validating a tool for a warehouse workflow? I don't need a huge infrastructure. I need to understand the data, where people get stuck, and who's actually going to use it.

The rest is theater.

What I keep

I'm not saying ship garbage. I'm saying put quality where it matters:

  • clear data model
  • readable code
  • simple interfaces
  • testable logic
  • understandable deployment

Everything else is decoration.

What I remove

I cut the words that make me sound bigger than the project: enterprise, production-ready, scalable infrastructure.

I'll bring them back when they're true. Not when they fill a page.

For now: small prototype, clear problem, zero marketing.