# Systems-First Design: Stop Adding, Start Decomposing — Pilot to Production

> Every new tool adds complexity. Systems-first design decomposes problems into primitives and extends instead of adding, shrinking complexity over time.

Canonical: https://thegrowthproject.com/podcast/systems-first-design/

*Pilot to Production*, the Growth Project podcast — hosted by Sam and Maya.

- Listen: https://thegrowthproject.com/podcast/systems-first-design/
- Read the article: https://thegrowthproject.com/blog/systems-first-design/
- Audio: https://thegrowthproject.com/audio/podcast/systems-first-design.m4a?v=2e103b4e

## Transcript

**Sam:** Year six. Five systems, three integration points, and not one person who understands how they all connect.

**Maya:** And every new feature now takes three times longer than it should. Nobody decided that. It just happened.

**Sam:** Welcome to Pilot to Production, from the Growth Project. I'm Sam.

**Maya:** And I'm Maya. Today: why adding another tool is the trap, and decomposing what you have is the way out.

**Sam:** Okay. Walk me through how a smart team ends up there. Because nobody sets out to build a mess.

**Maya:** Right, and that's the point. Year one, you need to track orders, so you add a system. Reasonable.

**Sam:** Sure.

**Maya:** Year two, inventory. Add another system. Year three, you need orders and inventory to talk, so you add an integration layer.

**Sam:** I can see where this is going.

**Maya:** Year four, reporting, so a data warehouse. Year five, automation, a workflow tool. By year six, you've got the sprawl.

**Sam:** And every single one of those calls was defensible.

**Maya:** That's what makes it seductive. You have a problem, a tool solves it, you ship it. The decision always seems reasonable.

**Sam:** So where's the actual cost? Because it doesn't show up on day one.

**Maya:** It compounds. New tool for every problem means more integrations to maintain. Feature-specific fixes mean the same logic duplicated across systems.

**Sam:** And duplicated logic drifts.

**Maya:** Inevitably. The same rule in three places eventually disagrees with itself. More surface area is also more attack vectors. And every separate concept is training burden for every new hire.

**Sam:** So this isn't an execution failure. People aren't being sloppy.

**Maya:** It's a failure of approach. You're solving problems by adding things, and each addition makes the next problem harder.

**Sam:** Alright. What's the alternative, in plain terms?

**Maya:** Ryo Lu, the Head of Design at Cursor, frames it well. The traditional approach starts from problems and creates specific fixes. The result is more buttons, more concepts, more navigation.

**Sam:** And systems-first?

**Maya:** You decompose problems into primitives. You keep the core concepts simple, and you let complexity emerge from combinations instead of additions.

**Sam:** Give me something concrete. Primitives sounds abstract.

**Maya:** Notion. The whole product runs on four concepts. Blocks, which are any piece of content. Pages, which contain blocks. Databases, which are structured collections. And relations, which connect databases.

**Sam:** That's it? Four?

**Maya:** That's it. And from those four, people build wikis, project trackers, CRMs, habit trackers, personal websites. Notion didn't add a feature for each. The primitives are just flexible enough to combine in unlimited ways.

**Sam:** So the move isn't add a tool, it's recombine what you've got.

**Maya:** Exactly. When a new problem lands, you don't ask what tool should we add. You ask what primitives do we need, and do we already have them.

**Sam:** How do you actually run that? Because in the moment, adding feels faster.

**Maya:** There's a process. Identify the entities, the nouns. Customer, order, product, supplier, shipment. Then ask if they already exist under a different name.

**Sam:** Then the connections.

**Maya:** Identify the relationships. Customer places order, order contains products. Are those already modeled? Then the operations, the actions. Create order, update inventory, send notification. Are those already happening somewhere?

**Sam:** And only then do you find what's actually missing.

**Maya:** That's step four. The gaps are your real requirements. Everything else is reuse. And step five, when you do build, build a primitive that combines with others, not a one-off fix.

**Sam:** Now be honest with me. Is decomposing always right? Because that can become its own religion.

**Maya:** No, and the post is clear on that. Add when the domain is genuinely new and no existing primitive applies. When scale demands specialized infrastructure. When regulation mandates separation. Or when extending costs more than adding.

**Sam:** So there's a single test.

**Maya:** One question. Will adding this make the next problem easier or harder? If harder, decompose. If easier, add.

**Sam:** I like that because it's not dogma, it's a decision rule. Okay, first thing tomorrow. Someone's listening with a stack held together by tape. What do they do?

**Maya:** Start with an inventory of what you have. Map your primitives, the core entities. Then map your relationships and draw it. You'll find duplicates and you'll find gaps.

**Sam:** Then?

**Maya:** Identify the sprawl. Where's the same concept living in multiple systems? Customer in the CRM, customer in billing, customer in support. That's sprawl.

**Sam:** And you don't fix all of it at once.

**Maya:** Don't boil the ocean. Pick one consolidation. One duplicated entity, and plan how to make it the single source of truth. And before the very next addition, ask the question. Can we extend what we have?

**Sam:** The goal isn't never add anything.

**Maya:** It's to default to decomposition. Ask the question before you reach for a new tool. Build systems that get simpler as capability grows.

**Sam:** This has been Pilot to Production, from the Growth Project. If your stack grows every quarter but understanding shrinks, that's the gap we close, at thegrowthproject.com.

**Maya:** Thanks for listening. See you next time.