How a Founder Thinks About System Design

389 words, 2 min read
Last updated on

How a Founder Thinks About System Design

You don’t need to design like a staff engineer. You need enough of a mental model to make good calls fast, scope honestly, and talk credibly with engineers. The goal isn’t the “right” architecture — it’s the simplest system that solves the requirement and won’t trap you later.

The loop

  1. Start from the requirement, not the tech. What does the user need to happen? Write that first. Most over-engineering comes from designing for an imagined future instead of the stated need.
  2. Build the simplest thing that works. Solve today’s problem with the least moving parts. Complexity is a loan you repay with interest.
  3. Know where each piece sits. For any feature, be able to say: where does the data live, what talks to what, and who is allowed to do it. That’s most of system design at an early stage. (See Databases-and-APIs.)
  4. Hold a few options across the spectrum. Cheap-and-simple → robust-and-complex. Pick deliberately, not by default. (See Engineering-Practices.)
  5. Leave a door, not a wing. Don’t build the scaled version now — just don’t make a choice that’s expensive to reverse. Reversible decisions can be fast and rough; one-way doors deserve thought.

The three questions for any feature

  • Data — what do we store, and how do the pieces relate? (an ERD answers this)
  • Flow — what calls what, in what order, and what happens when a step fails?
  • Access — who can do this, and how is that enforced? (auth + roles — see OAuth, RBAC)

If you can answer those three, you can spec a feature an engineer can build.

Founder-specific instincts

  • Speed of iteration beats theoretical scalability early on — but watch for the one or two things that are genuinely hard to change later (your core data model, your auth model).
  • Being a little technical is leverage: you scope better, estimate better, and earn trust. Take on small builds and learn from the mistakes.
  • Match the system to the stage. A two-engineer team shipping fast needs different architecture than a 50-person org. Don’t cargo-cult big-company patterns into a startup.

Open questions

  • When is it worth introducing a queue / async processing?
  • What’s the cheapest way to add caching, and when does it actually pay off?
  • How do I reason about a data model I’ll regret in a year?