What is Software Architecture? How Engineers Plan a System Before Writing Code

If you are a founder hiring engineers, you have heard the word “architecture” used in two ways: by serious teams, who treat it as the most important phase of the engagement, and by less-serious ones, who use it as a synonym for “the code.” This guide is for founders who want to understand which one you are talking to.

The Plain Definition

Software architecture is the set of structural decisions made before code is written, governing how the system is shaped — its data model, service boundaries, API contracts, security model, and deployment topology.

The defining characteristic of an architectural decision: it is expensive to reverse. A function name can be changed in five minutes. A data model can be changed in five months. A microservices boundary, once data and code have been built around it, can be changed in five years — sometimes never.

That is why architecture matters disproportionately. The decisions made in week one decide what features you can ship in year three.

Architecture vs Design vs Code

A useful three-layer model:

Layer	What it covers	Cost to change
Architecture	Data model, service boundaries, security model, deployment topology	High (months/years)
Design	Function signatures, class hierarchies, UI components, internal modules	Medium (days/weeks)
Code	The actual implementation	Low (minutes/hours)

Founders worry about code (the most visible layer). Engineers worry about design (the layer they touch every day). The work that decides the product’s long-term cost happens at the architecture layer — and almost always before anyone writes a line of production code.

A good engagement reflects this. The first week or two of a custom SaaS development project should produce architecture documents, not a working prototype.

What an Architecture Document Actually Contains

A real architecture artifact — the kind you’d see at the start of a senior engineering engagement — usually covers six things:

1. The data model

The entities the system manages, their relationships, the constraints between them. Not the database schema — the conceptual model that the schema will eventually reflect. Done well, this is the document the team returns to most often.

2. The service boundaries

Even in a single-service system, there are internal modules with their own responsibilities. What does each one own? What does it expose? Where are the seams that allow you to extract one into its own service later, without rewriting everything around it?

3. The API contracts

The shape of the interfaces between services, and between the backend and frontend. REST? GraphQL? gRPC? Versioning strategy? Backwards-compatibility commitments? See our deeper notes on API-first architecture for the structural questions worth answering early.

4. The security and identity model

Authentication (who you are) and authorisation (what you can do) are architectural choices, not feature choices. Single-tenant or multi-tenant? Roles or attribute-based access control? Session, JWT, or paseto? SSO/SAML pre-built or deferred? Get this wrong in week one and you fight it for the life of the product. We have a longer note on enterprise authentication and SSO for the deeper version.

5. The deployment topology

Where the system runs. How it scales. What “production” actually means as infrastructure. Single region or multi-region? Containers, serverless, or managed services? CI/CD shape? Observability stack? Disaster recovery posture?

6. The integration architecture

Every system depends on third-party APIs — payments, identity, email, AI, telemetry. The architecture decides how those dependencies are abstracted, where failures are absorbed, how retries and idempotency work. Build this layer thoughtfully and you can swap providers later; build it carelessly and your product is married to its initial vendor set.

The Main Architecture Styles, Translated

You will hear engineers throw these names around. The founder-useful summary:

Monolithic

One deployable unit, one codebase, one database. Easiest to build, easiest to operate at small scale. The default for most early-stage SaaS, and often the right one for years.

Common misconception: “monolithic” does not mean “bad.” Shopify, GitHub, Basecamp and Stack Overflow ran for years on enormous monoliths because the alternative — a fleet of microservices — would have been worse for them.

Modular monolith

A single deployable with strict internal module boundaries. Looks like a monolith from the outside; looks like microservices from the inside. The pragmatic default for serious early-stage products that may want to break things out later.

Microservices

Many independently deployed services, each owning their own data. Powerful when team size and domain independence justify the operational cost. Disastrous when adopted before either condition is true.

The honest rule: microservices solve scaling problems for teams, not for traffic. If you have fewer than 20 engineers, microservices are probably the wrong shape.

Serverless

Functions that run on demand, no servers for your team to manage. Great for event-driven workloads, scheduled jobs, glue logic. Awkward as the primary architecture for stateful, latency-sensitive applications.

Event-driven

Services communicate by publishing events to a message bus instead of calling each other directly. Decouples services beautifully. Adds operational complexity (you now have a message bus to operate). Right for systems with complex domain workflows, overkill for most CRUD products.

Most production systems are hybrids — a modular monolith with a few extracted services, plus serverless functions for scheduled work, plus an event bus for the parts that warrant it. The label matters less than the fit.

Why Architecture Matters Disproportionately at MVP Stage

A common founder belief: “Let’s ship MVP first and worry about architecture when we have product-market fit.”

Half-true. You should not over-engineer for hypothetical scale at MVP stage. But the structural decisions — data model, auth, integration shape — are baked in from the very first line of production code, whether you think about them or not. The choice is:

• Decide deliberately in week one, or
• Decide by default in week one and rediscover the decisions painfully in year two.

The second path looks faster initially. It is a great deal more expensive over a 36-month window. We have written about the hidden cost of failed software projects — most failures we have audited traced back to architectural decisions made (or unmade) in the first six weeks.

What “Enough” Architecture Looks Like at MVP

Founder-friendly answer: enough to make the next 12 months of product decisions cheap, and the next 36 months of decisions possible. Specifically:

• A data model that captures the entities and relationships you know exist, with primary key and uniqueness decisions thought through.
• A clear service boundary — even if it is one service, the modules within it have names and ownership.
• An auth model that can grow into multi-tenant if your customers will demand it. Build single-tenant if they won’t.
• An integration architecture that abstracts third-party APIs behind your own contracts.
• A deployment topology that supports zero-downtime deploys and basic observability from day one.

Skip:

• Multi-region complexity you will not need for two years.
• Microservices for a 3-person team.
• Custom infrastructure you can rent from a managed service.
• Premature abstractions for use cases you cannot yet describe.

The art is knowing what to invest in and what to defer. A senior architect is mostly someone with strong opinions about which decisions go in each bucket.

Architectural Mistakes That Are Expensive to Reverse

Almost every painful migration we have shipped traces back to one of these patterns:

1. The wrong primary key. Auto-incrementing integers when you should have used UUIDs. Composite keys that fight every join.
2. Single-tenant baked into auth. Your first enterprise prospect asks for SSO and tenant isolation; the answer is a four-month rewrite.
3. Skipping audit logging on financial or PII data. A regulator or auditor asks for an audit trail that does not exist.
4. Direct coupling to a third-party API. Your payment processor raises prices or has an outage and you cannot route around it.
5. Synchronous where it should be async. A six-second user-facing latency on what should be a background job.
6. A database picked for today’s data shape, not tomorrow’s queries. The classic: relational data forced into a document store, or vice versa.

The common thread: each one looks like a local decision in a single file when it is being made. Each one propagates outward as soon as you build on top of it.

What This Means for Hiring a Team

When you talk to a software development agency or an engineering lead, the architecture question separates serious teams from order-takers in about five minutes:

• “How would you architect this?” Good answers describe the data model, service boundary, auth choice, and integration approach. Weak answers describe the framework and the hosting provider.
• “What does the discovery phase produce?” Good answers: an architecture document, a data model, integration contracts, milestone plan. Weak answers: “we’ll know more after a few sprints.”
• “What are the three decisions you would not want to revisit?” Good answers name them and explain why. Weak answers shrug.

For our perspective on how to scope the engagement around architecture, see how to write a software development brief and how to choose a custom software development partner.

The Founder’s Take

Software architecture is not a phase you can skip — every system has one, whether anyone wrote it down or not. The choice is between an architecture that was designed and an architecture that emerged by accident.

Designed architectures cost a little more in week one and far less in year three. Accidental architectures look like a bargain until you try to scale, sell to enterprise, or change your business model.

If you are scoping a custom SaaS or enterprise web build and want the architectural foundations done properly — tell us about the project. The first conversation costs you 30 minutes and tells you what your product will need before you spend the first euro of build budget.