System Design for Small Products
A grounded way to think about architecture before a product has the traffic, team, or complexity of a large platform.
Rizky Romadon//2 min readTL;DR
Small products do not need large-platform architecture. They need clear boundaries, boring storage, good observability, and enough flexibility to survive the next product decision.
Start With the Product Shape
Architecture should follow the product, not the other way around. Before choosing queues, caches, or service boundaries, I want to understand the core user journey.
What data is created? What needs to be fast? What can be delayed? What would be painful to lose? Those questions usually matter more than whether the system starts as a monolith or multiple services.
Prefer Boring Until Proven Otherwise
Boring is not lazy. Boring is strategic. A relational database, a clear API layer, background jobs, and structured logs can carry a surprising amount of product work.
I try not to add distributed complexity before the product proves it needs it. The cost is not only infrastructure. The cost is debugging, local development, deployment, and the mental load of every future change.
Design the First Boundary Carefully
Even small products need boundaries. The first important boundary is often not a microservice. It is a module, a package, or a service class that keeps business rules separate from delivery details.
Good boundaries let the product evolve without forcing a rewrite every time the UI changes.
What I Watch Early
- Data ownership.
- Transaction boundaries.
- Background job visibility.
- Authentication and authorization rules.
- Audit requirements.
- Slow queries.
- Manual recovery paths.
These are the places where small systems quietly become hard to operate.
Conclusion
System design for small products is about choosing the simplest architecture that still respects the future. Build the product first, but leave enough clarity for the next version to arrive without panic.