Start with edges, not the core

Tech Architect Insights – Issue #5

Author

Bogdan Colța
June 08, 2025

👋 Hey there,

If you’re like most developers, you start design work by jumping into the internals:

  • How will we model the data?

  • What does the core logic look like?

  • Which pattern fits best here?

That used to be me, too. And honestly, sometimes it felt like I was moving fast, getting things done.

But over time, I realized something:

The stuff in the middle is often the easiest part to rewrite.
The hard part? The edges. The contracts. The integration points. The assumptions baked into your APIs.

That’s where systems get brittle.
That’s where things break silently.
That’s where handoffs between teams go wrong.

So here’s the mindset shift:

📔 Before you write logic, design the edges.

📖 Why Boundaries Are the Real Architecture

When architects begin planning a system, they don’t start with database schemas or services.
They start with boundaries:

  • What components exist?

  • How do they talk to each other?

  • Who owns what?

  • What lives inside vs. outside the system?

This might sound abstract, but it has real-world consequences:

🔸 Mistake 1: Designing logic before APIs

You write internal logic first, then slap an interface on top.
Result: Leaky abstractions, messy endpoints, hard-to-use systems.

🔸 Mistake 2: Ignoring future ownership

You don’t consider who will own each part of the system long-term.
Result: Teams tripping over each other, unclear responsibilities, hidden dependencies.

🔸 Mistake 3: Hardcoding integration

You make assumptions about how upstream/downstream systems will behave.
Result: Tight coupling, expensive refactors, fragile coordination.

💭 Think like a boundary-first architect

When you design the edges first, you:

  • Avoid coupling too early

  • Make interfaces more deliberate

  • Set your team up for parallel development

  • Build systems that evolve instead of calcify

🛠 Tool of the Week: Boundary-First Architecture Brief

Here’s a simple structure I use when planning a new system or major component.
Use it before you write a single line of code.

🧩 Boundary Planning Checklist

1. What’s the purpose of this component?
Describe what it does, not how it does it.

2. What are its boundaries?
Where does this responsibility end? What doesn’t belong here?

3. What does it need from the outside?
What external data, systems, or inputs does it depend on?

4. What will it expose to others?
Define clear, minimal interfaces. Consider future extension points.

5. Who owns each boundary?
Think in terms of people, teams, and future maintenance.

6. What are the edge cases (pun intended)?
Where could inputs be unclear, delayed, duplicated, or fail?

Start here. Then design the insides.

✅ Mini Challenge: Redraw the Edges

This week, take one system or service you’ve worked on recently, even if it’s already live.

Sketch the boundaries. Ask:

  • What’s actually inside this component?

  • What are its contracts, and are they clear?

  • Where have things broken due to unclear edges?

Then, and this is key, ask a teammate if they see it the same way.

Systems that fail at the boundaries don’t always fail loudly.
They just rot slowly… until someone spends a weekend unraveling why.

Let’s avoid that.

🗣️ Engage or Explore

Have you ever worked on a system with terrible boundaries?
Endpoints that expose internal logic? Services that do way more than expected?
I’d love to hear your example, just send me an email 📩

And if you haven’t yet, check out the 5-Day Crash Course. It dives deeper into tradeoffs, communication, and system design habits that most devs never learn on the job.

👋 Wrapping Up

Thanks for reading.

A strong system isn't defined by how clever the logic is, it's defined by how clearly it connects, communicates, and holds its shape under pressure.

Start with the edges.

See you next week,
Bogdan Colța
Tech Architect Insights