Software Architect & System Design
I make the architecture decisions that decide whether software stays changeable: where boundaries go, how tenants stay isolated, what runs async, and what to build versus buy. Software isn't features — it's decisions.
What it is
System design is the practice of choosing a system's structure — its boundaries, data flow, storage, and failure behavior — to meet real requirements at acceptable cost. For most products that means pragmatic, evolvable design, not premature distributed-systems complexity.
Why it matters
The expensive mistakes are architectural: the wrong boundary, tenant data that leaks, a synchronous path that should've been a queue. These are cheap to get right early and brutal to fix late.
My experience
I architect multi-tenant SaaS with granular RBAC, design queue-driven backends, and lead a five-person team through the decisions and trade-offs — scoping the smallest valuable slice and measuring engineering in business outcomes. I ran a full cloud migration (Heroku→OVHcloud) and a 120+ finding production-readiness program.
Projects
Architecture decisions & trade-offs
Split by responsibility, not by layer. Things that change together live together.
Buy undifferentiated infrastructure (auth, payments primitives); build what's core to the product's value.
Design for the scale you have plus the next order of magnitude — not a hypothetical you'll never reach.
- Microservices before you have the team or scale to justify them.
- Designing for imaginary scale while shipping slowly.
- Boundaries drawn by technical layer instead of business responsibility.
- Start with a well-structured monolith; extract services only when a seam earns it.
- Make tenant isolation and failure behavior explicit early.
- Decide build-vs-buy by what's core to your value.
FAQ
Monolith or microservices for a startup?
A well-structured monolith almost always — it ships faster and is easier to reason about. Extract a service only when a specific seam (scale, team boundary, independent deploy) genuinely earns it.
How do you design for scale without over-engineering?
Design for your current scale plus one order of magnitude, make the costly-to-change decisions (tenancy, data model, async boundaries) deliberately, and defer the rest.
Key takeaways
- The expensive mistakes are architectural — get boundaries and tenancy right early.
- A structured monolith beats premature microservices for most teams.
- Build what's core; buy the rest.