Systems-First Design: Stop Adding, Start Decomposing

Every problem gets another tool. Every tool adds complexity. Every complexity slows you down.

You’ve seen this pattern. The tech stack grows. The integrations multiply. Each new feature requires touching five systems. Nobody understands the whole thing anymore.

There’s a different approach.

The Addition Trap

Here’s how most companies build their technology:

Year 1: You need to track orders. You add a system.

Year 2: You need to track inventory. You add another system.

Year 3: You need to connect orders and inventory. You add an integration layer.

Year 4: You need reporting. You add a data warehouse.

Year 5: You need automation. You add a workflow tool.

Year 6: You have five systems, three integration points, and nobody who understands how they all connect. Each new feature takes three times longer than it should.

This isn’t a failure of execution. It’s a failure of approach. You’re solving problems by adding things. Each addition makes the next problem harder.

What Addition Looks Like	What It Costs
New tool for every problem	More integrations to maintain
Feature-specific fixes	Duplicated logic across systems
Point-to-point connections	Exponential complexity as systems grow
Separate concepts everywhere	Training burden for every new hire
More buttons, more screens	Cognitive load for users

The addition trap is seductive because each decision seems reasonable. You have a problem. A tool solves it. Ship it.

But complexity compounds. And at some point, you’re spending more time managing complexity than solving problems.

Why Adding Fails

Ryo Lu, Head of Design at Cursor, describes the difference between two approaches to product design.

Traditional approach: Start from problems. Create specific fixes. Result: more buttons, more concepts, more navigation levels.

Systems-first approach: Decompose problems into primitives. Keep core concepts simple. Emerge complexity from combinations.

The traditional approach works in the short term. You solve the immediate problem. But each fix makes the system harder to extend.

Think about it:

• More concepts means more training. New hires need to learn five systems instead of one.
• More integrations means more failure points. Each connection can break.
• More duplication means more drift. The same logic in three places inevitably diverges.
• More surface area means more security risk. Every system is an attack vector.

Systems-first design inverts this. Instead of adding, you decompose.

Systems-First Design

The principle is simple:

“Ideally, you don’t add things. You’re actually decomposing things, merging them back, figuring out what is the better configuration of the stuff that you have now.”

What does this mean in practice?

Identify your primitives. Every domain has core building blocks. Orders. Customers. Products. Events. These are the primitives that everything else is built from.

Make primitives flexible. Don’t hardcode assumptions. An “order” should be able to represent a sale, a return, a transfer, a subscription renewal. Different configurations, same primitive.

Combine primitives to solve problems. Need a new feature? Don’t add a new system. Ask: “Can I combine existing primitives differently?”

Example: Notion

Notion built their product on a small set of primitives:

• Blocks (any piece of content)
• Pages (containers for blocks)
• Databases (structured collections)
• Relations (connections between databases)

That’s it. Four concepts. From those four concepts, users build wikis, project trackers, CRMs, habit trackers, personal websites. Not because Notion added each of those features. Because the primitives are flexible enough to combine in unlimited ways.

That’s systems-first design.

The Decomposition Process

When you face a new problem, don’t ask “What tool should we add?”

Ask: “What primitives do we need, and do we already have them?”

Step 1: Identify the entities

What things exist in this problem? List the nouns. Customer. Order. Product. Supplier. Shipment.

Then ask: Do these already exist in our systems? Are they just called something different? Can the existing entity be extended to cover this case?

Step 2: Identify the relationships

How do these things connect? Customer places Order. Order contains Products. Supplier fulfills Shipment.

Then ask: Are these relationships already modeled? Can we extend existing relationships rather than creating new ones?

Step 3: Identify the operations

What actions need to happen? Create order. Update inventory. Send notification. Generate report.

Then ask: Are these operations already happening elsewhere? Can we reuse or extend existing workflows?

Step 4: Find the gaps

Only after steps 1-3 do you identify what’s genuinely missing. The gaps are your actual requirements. Everything else is reuse.

Step 5: Extend, don’t add

When you do build something new, build it as a primitive that can be combined with other primitives. Don’t build a one-off fix. Build a building block.

When to Decompose vs. Add

Decomposition isn’t always the answer. Sometimes you genuinely need to add something.

Decompose when:

• The problem involves entities you already model
• The new requirement is a variation, not a new category
• Integration complexity is becoming a bottleneck
• You’re duplicating logic across systems

Add when:

• The domain is genuinely new (no existing primitives apply)
• The scale demands specialized infrastructure
• Regulatory requirements mandate separation
• The cost of extension exceeds the cost of addition

The test: Will adding this make the next problem easier or harder?

If harder, decompose. If easier, add.

First Thing Tomorrow

Start with an inventory of what you have.

1. Map your primitives. What are the core entities in your systems? Customers. Orders. Products. Events. List them.
2. Map your relationships. How do they connect? Draw it. You’ll find duplicates. You’ll find gaps.
3. Identify the sprawl. Where do you have the same concept in multiple systems? Customer in CRM. Customer in billing. Customer in support. That’s sprawl.
4. Pick one consolidation. Don’t boil the ocean. Pick one entity that’s duplicated. Plan how to make it the single source of truth.
5. Before the next addition, ask: Can we extend what we have? What primitives already exist? What’s the minimum we need to build?

The goal isn’t to never add anything. It’s to default to decomposition. To ask the question before reaching for a new tool.

The Bottom Line

Your tech stack will keep growing if you let it. Each addition feels justified. Each creates complexity. Complexity compounds until your systems are harder to change than the business they support.

Systems-first design is the antidote. Don’t add. Decompose. Find the primitives. Combine them differently. Build systems that get simpler as capability grows.

---

Need help simplifying your stack? We design systems that decompose complexity instead of adding to it. Let’s talk.