Software architecture: a guide for the founder paying the bill

You can’t read the diagram of boxes and arrows. But you can read what it will cost: what gets slow, what gets expensive, what becomes impossible. This is the guide to software architecture for the person who signs the check and lives with the decision.

In a kickoff meeting, the technical team opens Miro and draws a rectangle, then three more, connects everything with arrows, writes “API Gateway” in the middle, and asks: “Does this make sense to you?” The founder looks, recognizes none of the words, and says “yes.” It’s the wrong answer, and not because the architecture is wrong. It’s wrong because nobody just approved a software architecture. Someone just approved a bet about what the company will need to change later, without knowing it was a bet.

Software architecture is the set of high-level structural decisions that define how a system is organized: what its parts are, how they talk to each other, and where the boundaries between them sit. Those decisions get made in the first weeks of a project and determine how much every change will cost for years afterward. It’s not the code. It’s the shape the code is written inside. And it’s the most expensive thing to reverse that you’ll approve without understanding.

Martin Fowler, one of the most respected names in software engineering, puts it this way: architecture is “the things that people perceive as hard to change.” Keep that sentence. It’s the only definition that matters to the person paying the bill.

It’s worth separating two terms that confuse founders. Your tech stack is the list of tools the team uses (React, Node, Postgres). Architecture is how those tools are organized and where the boundaries between them fall. Two teams can use the same stack and build systems with completely different maintenance costs, because the difference isn’t in the tools, it’s in the shape.

Why this is the founder’s problem, not just the dev’s

There’s an obvious temptation: architecture is a technical subject, so delegate it to someone technical and get back to running the business. The problem is that architecture isn’t a technical decision with technical consequences. It’s a technical decision with financial consequences, and the consequences land on your desk, not the developer’s.

A system with the wrong structure doesn’t break the next day. It gets expensive quietly. Every new feature takes a little longer than it should. Every fix touches three places instead of one. Six months in, the team says it “needs to refactor before continuing,” and you have no way to judge whether that’s true or an excuse. A year in, a change your competitor ships in a week takes a month at your shop. Nobody made a visible bad decision. The bad decision was made in the first month, in the diagram you approved by nodding along.

It’s the same pattern we describe in technical debt: the cost doesn’t show up now, it shows up as interest. Architecture is where technical debt is born, or isn’t.

What architecture actually answers (the founder’s three questions)

You don’t need to understand the diagram. You need to understand what it’s betting on. Every architecture decision answers, in practice, three questions you can evaluate without reading a line of code.

What happens when we have 10x the users? Some shapes absorb growth without a major overhaul; others have to be rebuilt when volume tightens. That’s scalability, and it’s a business question dressed up as a technical one.

What happens when we need to change one thing? In good architecture, touching pricing doesn’t affect login. In bad architecture, everything is glued together, and every change risks breaking something unrelated. This decides your speed for the rest of the product’s life.

What happens when the person who built this leaves? Clear architecture can be understood by a new developer in days. Architecture that lives only in one person’s head is a business risk, the bus factor that costs you sleep.

Scalability, changeability, and independence from people. Those three you can hold a team accountable for. Don’t ask “which pattern will you use.” Ask “what does this choice do to those three things.”

The types of architecture, translated into trade-offs

The internet will offer you a taxonomy: monolith, microservices, serverless, layered architecture, event-driven. Presented as a CS list, it’s useless to you. Translated into trade-offs, it becomes a business decision.

Monolith. The whole system is one piece. Simpler to build, cheaper to run early, faster to stand up. The classic criticism is that it “doesn’t scale,” but for the overwhelming majority of early-stage companies, the monolith is the right answer. Martin Fowler himself argues for starting with the monolith and only splitting when the pain shows up. A well-built monolith carries a product much further than fashion suggests.

Microservices. The system is broken into many small, independent services. You gain flexibility and scale; you pay with heavy operational complexity. Each service is one more thing to monitor, version, and connect. For a five-person startup, microservices are usually an answer to a problem it doesn’t have yet, and a way to burn months of runway building infrastructure instead of product.

The middle ground. Most good decisions in 2026 live between the two: a well-organized monolith, with clean internal boundaries, that can be split into specific parts when (and if) a specific part needs it. You don’t have to choose between the extremes on day one. You need to make sure today’s choice doesn’t close tomorrow’s door.

The right question is never “monolith or microservices.” It’s “which shape solves the problem we have now without chaining us to the problem we may never have.”

The four questions for a decision you can’t read

When the team presents the architecture, you won’t evaluate the diagram. You’ll evaluate the answers. These four questions pull out what the drawing hides, and none of them requires you to be technical.

1. What does this make cheap and what does it make expensive later? Every architecture optimizes for something and penalizes something else. If nobody can name what gets more expensive under this choice, nobody thought about the trade-off, only the pretty part.

2. What are we betting won’t change? Architecture is a bet on stability. If the system was designed assuming you’ll never switch payment providers, countries, or billing models, then those things just became expensive to change. Check that the bets match your business plan.

3. What would it cost to reverse this in a year? This is Fowler’s question in practical form. Decisions that are cheap to reverse can be made fast and corrected later. Decisions that are expensive to reverse deserve a real conversation now. Ask for the estimate in weeks of work, not in adjectives.

4. Is this complexity for our problem or for a problem we don’t have? Technical teams, out of a legitimate pride in their craft, sometimes build for Stripe’s scale when you have 200 users. Complexity that doesn’t serve your stage is your money funding someone else’s fun.

If those four questions get answered clearly, you have a team that thinks like a partner. If they get answered with jargon and impatience, you have a warning sign worth more than any diagram.

Where architecture turns into lock-in

A good share of the vendor lock-in that haunts founders is, at its root, an architecture decision nobody discussed. A system built glued to one specific provider, with the data model shaped around a tool that was convenient in the first month, turns “switch providers” into “rewrite half the product.” Architecture doesn’t lock you in on purpose. It locks you in because the boundary that would have protected you was never drawn, and drawing a boundary later costs far more than drawing it up front.

In the same way, a legacy system is rarely legacy because it’s old. It’s legacy because its structural decisions were never documented or revisited, and now nobody has the nerve to touch it. Architecture isn’t something you define once. It’s something you keep awake.

What an “architect” does, and who does it on your project

The question that shows up in every search (“what does a software architect do?”) has an answer that matters to you. A software architect is the person who makes and defends these structural decisions and makes sure the team builds inside them. On big teams, it’s a title. In a software house or a lean team, it’s a role: someone, usually the most senior developer or the tech lead, is doing this work, with or without the title.

What matters to you isn’t the badge. It’s knowing whether someone is actually tending these decisions on your project, or whether they’re being made by accident, one commit at a time, with nobody watching the whole. In a healthy relationship with a tech partner, you can ask “who owns the architecture here?” and get a name. If the answer is silence, you’ve found the problem before it found you.

The rule of thumb

You don’t approve an architecture. You approve a bet about what your company will need to change later, and architecture is the price of getting that bet wrong.

That doesn’t mean stalling the project by demanding the perfect drawing. There is no perfect drawing, and the search for it costs more than any reasonable mistake. It means treating expensive-to-reverse decisions with the weight they carry, and cheap ones with the lightness they allow. A good team makes that separation for you and explains it in plain language. A team that treats everything as equally irreversible is selling you fear; one that treats everything as equally disposable hasn’t felt the bill arrive yet.

Architecture is invisible until the day it’s the only thing that matters. On that day, the price was already paid in the diagram you approved back at the start, nodding along. Next time they open Miro in front of you, you already know the questions.

Frequently asked questions

What is software architecture?
It’s the set of high-level structural decisions that define how a system is organized: its main parts, how they communicate, and the boundaries between them. Those decisions determine how much it will cost to change, scale, and maintain the system over time. It’s not the code itself, it’s the shape the code is written inside.

What are the types of software architecture?
The most common are the monolith (the whole system as one piece, simpler and cheaper early) and microservices (the system split into small, independent services, more scalable but with far more operational complexity). There are variations like layered, serverless, and event-driven, but for a founder what matters isn’t the pattern’s name, it’s the trade-off: what each choice makes cheap and what it makes expensive later.

What does a software architect do?
They make and defend a system’s structural decisions and make sure the team builds inside them. On lean teams it’s usually a role played by the most senior developer or tech lead, not a formal title. What matters to the person paying is knowing whether someone is actually tending those decisions, and getting a name when you ask “who owns the architecture here?”

Monolith or microservices: what should a startup choose?
In the overwhelming majority of early-stage cases, a well-organized monolith. It’s faster to build, cheaper to run, and carries a product much further than fashion suggests. Microservices solve scale and large-team organization problems that a five-person startup doesn’t have yet. Start simple and split a specific piece when the pain shows up, not before.

How do I know if my system’s architecture is good if I’m not technical?
You don’t evaluate the diagram, you evaluate the consequences. Ask three questions: what happens with 10x the users, what happens when we need to change one thing, and what happens when the person who built it leaves. A good team answers all three clearly and in plain language. Answers full of jargon and impatience are the warning sign, not the diagram.