Start Small, Scale Smart: The Real Value of Incremental Architecture

A practical guide to designing software that can evolve as fast as you do

This issue is part of the series on Incremental Architectures for SaaS products.

You can read the previous one here 👇🏻

Incremental Platforms: Monolithic Modular Architecture

As you grow as a Software Engineer or Tech Lead, you need to grow in people skills, of course, but also in technical depth. That’s why this series exists. I hope you find this one useful.

Today, you will read about incremental architectures. Let’s put a bit of common ground first.

An incremental architecture is an architecture designed to grow.

☝🏼 And why should you want that?

Two simple reasons.

1. You care about code.

2. Your code will evolve. Your system will evolve. That is natural. The question is whether it can evolve easily or not.

If your architecture makes change painful, you are in trouble. If it is easy to modify, you can iterate fast without rewriting everything every few months.

👉🏼 There is a set of ideas, patterns, and organizational moves that enable this. Below are the core ones you should know.

1. Mission of the architect

The job of an architect is not to impose diagrams.

The job of an architect is to teach and keep coherence across the system. Guide decisions, set constraints, and help teams move forward without blocking them.

From my personal perspective, this can be achieved by implementing code and solutions, and not just advising people from an Architecture role. In some special cases, when an engineering organization is in a concrete momentum, a dedicated and non-coding architect could be ok.

2. Organization before technology

Cross-functional teams deliver faster than layered organizations because each team owns a domain end-to-end. No waiting for “the backend team” or “the frontend team” to free up a sprint.

👉🏼 One team, one domain, full ownership.

Keep this in mind:

• If you want microservices, you need cross-functional teams first.

• If you want incremental architecture, you need independent teams first.

This is why Gall’s Law matters, and with it, one of the takeaways for you today 👇🏻

If you start with a complex system, you will end with a complex system that does not work. Start small, grow intentionally.

3. Change the conversation

Instead of asking:

“how long will this take?”

ask:

“Can we make this smaller?”

👉🏼 You shift from deadlines to value. You move from guessing time to defining learning.

The real loop of incremental architectures is very simple and very effective:

1. Build something small.

2. Ship it.

3. Get feedback.

4. Adjust.

5. Repeat.

This loop is architecture. Not diagrams.

4. When the team lacks skills

A common blocker is “we cannot move fast because not everyone knows this part.”

Try mob programming. It spreads knowledge incredibly fast and aligns the whole team around real code, not documentation that nobody reads.

Other techniques that I practice and get great success with are:

• Pair Programming.

• Pair Review.

5. Patterns, but at the right time

Patterns are solutions to problems.

👉🏼 Use them when you have a problem, not before.

Some helpful patterns for incremental growth:

• Layered architecture: good separation of concerns, but people skip layers, so be careful.

• Hexagonal or microkernel: other ways to separate responsibilities, more explicit.

• Distributed architectures: enable incremental deployment and elasticity, but recovery can be hard. Know the distributed systems fallacies before you embrace distribution.

👉🏼 Remember: patterns are tools, not the goal.

6. The Strangler Pattern

This one is for when you have a big ball of mud and you want something cleaner.

I have a dedicated email for you on this here 👇🏻

Incremental Platforms: Monolithic Modular Architecture

And here in a nutshell:

1. Build a new module inside the existing system.

2. Give it clean, explicit interfaces.

3. Extract it from the system.

4. Redirect the rest to use the new module.

It is not easy, but it is a safe migration strategy without big-bang rewrites.

7. Component Architecture: your growth engine

A good component has a few strict qualities:

• Small classes and single responsibility.

• High cohesion and a focused interface.

• Hard boundaries, a single entry point. No spaghetti.

• Replaceable implementation, so clients do not depend on internals (Liskov matters here).

👉🏼 A component is not a microservice. It is smaller.

The trick is this: if you build components well, you can extract them into microservices whenever you need to. Zero drama.

This is how incremental architecture feels in real life.

8. Event-Driven Architecture

Strong coupling is bad.

👉🏼 You cannot eliminate it completely, but you can reduce it.

Event-driven approaches help. Instead of orchestrating a whole flow from a central component that calls payment, billing, shipping, and so on, the core component simply emits an event, for example, “OrderPlaced”.

Other parts react if they need to.

Everyone listens, no one knows each other, and events go through a broker, not direct calls.

This reduces coupling dramatically.

9. Domain Driven Design

DDD is a technique, not just a pattern, and it fits beautifully with incremental architectures.

👉🏼 And pay attention to this: Ubiquitous language is not a luxury. It reduces confusion and accelerates change.

When you map events and work, try this mental model:

• Orange stickers: events, written in the past tense.

• Blue stickers: consequences, the actual work to do.

• Yellow stickers: who performs the work, your services.

• Red stickers: questions, gaps in your knowledge.

If you see many red stickers, do not code yet. Answer the questions first.

✨ Takeaways

Today has been a very focused email about incremental architectures, but with many important things to take into consideration.

Take this list with you:

• Can you make the work smaller?

• Do teams own domains end-to-end?

• Do you apply patterns when they solve real problems, not by default?

• Do components have hard boundaries and respect Liskov?

Incremental architecture is a discipline, not magic. It pairs organizational change with pragmatic technical choices so you can grow without breaking everything.

---

Thanks for your support and feedback, I really appreciate it!

You’re the best! 🖖🏼

𝘐𝘧 𝘺𝘰𝘶 𝘦𝘯𝘫𝘰𝘺𝘦𝘥 𝘵𝘩𝘪𝘴 𝘱𝘰𝘴𝘵, 𝘵𝘩𝘦𝘯 𝘤𝘭𝘪𝘤𝘬 𝘵𝘩𝘦 💜. 𝘐𝘵 𝘩𝘦𝘭𝘱𝘴!

𝘐𝘧 𝘺𝘰𝘶 𝘬𝘯𝘰𝘸 𝘴𝘰𝘮𝘦𝘰𝘯𝘦 𝘦𝘭𝘴𝘦 𝘸𝘪𝘭𝘭 𝘣𝘦𝘯𝘦𝘧𝘪𝘵 𝘧𝘳𝘰𝘮 𝘵𝘩𝘪𝘴, ♻️ 𝘴𝘩𝘢𝘳𝘦 𝘵𝘩𝘪𝘴