Over the years, I've spent a lot of time thinking about how software projects should begin.
An architecture diagram doesn't make a system alive. Neither does a well-structured codebase. For me, an idea starts becoming real when its first meaningful scenario works for someone who needs it.
A small, complete scenario
Think of a user requesting an operation. The system accepts the request, tracks its progress, handles failures, and lets the user verify the outcome, even if the connection is interrupted.
It's a small scenario, but it's complete. And that's where I like to start.
Reduce uncertainty before writing code
Before implementation, I want to understand who the consumer is, what problem we're solving, and where the system boundaries are.
C4 helps clarify system boundaries and interactions. DDD helps identify business rules and ownership. Sometimes a simple sequence diagram is enough to expose an important assumption.
The point isn't to produce diagrams. It's to reduce uncertainty before writing code.
The first end-to-end scenario
Then comes the first end-to-end scenario.
I bring a TDD mindset to it: think about observable behavior, acceptance criteria, and failure cases before implementation. When TDD fits, tests can drive the implementation itself.
Once that scenario works and can be tested, we have a working behavior to build upon.
A meaningful beginning
I think of it like birth. A newborn doesn't have every capability yet, but has the foundations to grow. An early software system should be designed with that same idea in mind.
We don't need every future feature, or microservices from day one. A well-structured modular monolith can be a practical starting point, keeping boundaries clear without premature distributed-system complexity. SOLID principles help keep responsibilities focused and future changes manageable.
A first scenario is not yet an MVP
The first working scenario isn't necessarily an MVP, though. An MVP needs to deliver enough value to be useful. Releasing it to production also requires appropriate testing, security, failure handling, deployment, and observability.
Minimal scope shouldn't mean ignoring what makes software reliable.
- 01
Understand
Consumer, problem, boundaries. C4, DDD, a sequence diagram.
- 02
First scenario
End to end, tested, failure cases included.
- 03
MVP
Enough value to be useful.
- 04
Production
Testing, security, failure handling, deployment, observability.
- 05
Real usage
New scenarios challenge the assumptions.
Refactor, move a boundary, or keep the design: then the next scenario.
Room to evolve
After release, real usage challenges our assumptions. New scenarios reveal coupling, unclear responsibilities, or gaps in our understanding of the domain.
Sometimes we refactor or change a boundary. Sometimes the design is good enough.
I've become less interested in predicting the final architecture and more interested in making sure we can change it for the right reasons.
A software system doesn't need to be fully grown on day one. It needs a meaningful beginning, a foundation appropriate to its risks, and room to evolve.
How much architecture is enough before building the first real scenario? I'd like to hear how you decide. Join the conversation on LinkedIn, or tell me about the system you're starting.