Most SaaS founders over-think architecture before launch and under-think it after. The goal for an MVP is to ship something learnable; the goal 12 months later is to scale what works without a rewrite. This is a founder's guide to making architecture decisions that hold up across both — written from the engagements we have run at QwertyBit as a custom software development partner for SaaS founders.
Two reference points worth bookmarking: Martin Fowler on architecture for the vocabulary, and Google's Core Web Vitals for the user-facing performance signals Google actually ranks on.
When architecture actually matters (and when founders over-think it)
Before your MVP has product-market fit, architecture is mostly a distraction from the only question that matters: will the thing people do with this software be valuable enough that they pay for it? A clean, boring, single-server Next.js + PostgreSQL app gets you from zero to your first 1,000 users without any drama. Picking "microservices because it'll scale" at that point is the architectural equivalent of opening a second warehouse before you have customers.
Architecture starts mattering when one of three things happens:
- You have a workflow that is genuinely core to the product's differentiation — and the database shape that fits it naturally is not "one relational table per entity."
- You have a dependency with real latency, cost or reliability characteristics — AI model calls, heavy background processing, third-party APIs that throttle.
- You are about to hire the third and fourth engineer, and the current codebase cannot absorb them without merge conflicts.
Until then, ship. After then, the decisions in this post start to matter.
Three architecture patterns for SaaS MVPs — and who each fits
Most SaaS MVPs land in one of three shapes. Picking the right one on day one saves a rewrite in year two.
Pattern 1: "Monolith + queue"
A single web app (Next.js, Rails, Django — boring wins) with a background queue (Sidekiq, BullMQ, Celery) for async work. One database. One deployment. Two services max.
Fits: 80% of B2B SaaS MVPs. Low-complexity CRUD with some async processing (email, webhooks, reports). Small team.
Why it wins: one codebase, one migration story, one observability surface. You can onboard a new engineer in a day.
Pattern 2: "Monolith + agent backend"
As above, plus a Python service for agent work behind a typed API. Two services, one database, a queue between them.
Fits: AI-native SaaS where the agent pipeline is the product (or a major feature). Document processing, AI-driven analytics, agent-assisted workflows. See our AI agent development service for how we scope the agent half.
Why it wins: keeps Python where it is strongest (agents, data work, ML) and TypeScript/Node.js where it is strongest (product API, UI, real-time). The boundary is cheap because it is typed.
Pattern 3: "Vertical-slice microservices"
Three to five services, each owning a bounded slice of the domain (e.g. accounts, billing, ingestion, agent-workers, notifications). Each has its own database or schema.
Fits: teams above 8 engineers, products with multiple distinct revenue-generating workflows, or regulated domains where audit and isolation matter.
Why it wins: team-level ownership, independent deployability. Why it loses at the wrong stage: plumbing costs explode with a two-engineer team.
If in doubt, start with Pattern 1. Graduate to Pattern 2 the moment agents stop being a side feature. Graduate to Pattern 3 only when team size forces it.
The five decisions that cost the most to reverse later
These are the calls we spend the most time on during feasibility for our custom software builds. Each is cheap to get right on day one and expensive to fix in year two.
1. Where does the agent / model call happen?
If AI is part of your product, decide on day one whether the call happens synchronously inside a request or asynchronously via a queue. Synchronous is simpler but locks you into model latency. Async is more plumbing but keeps your p95 predictable when model providers degrade. Our LLM integration service has a lot more on this decision — it shows up in every agent-heavy product.
2. What is your tenancy model?
Single-tenant (one DB per customer), pooled (one schema per customer inside a shared DB), or shared (customer_id column in every table). Shared is cheapest and is the right answer for most B2B SaaS below €1M ARR. Single-tenant is a compliance lever worth what it costs only if your buyers actually demand it. Migrating from shared to single-tenant is a six-month project. Migrating from shared to pooled is a weekend.
3. Where do you put the billing boundary?
Billing always tries to creep into every feature. Isolate it early: a single billing module or service that owns pricing, subscriptions, invoice generation, and the API surface the rest of the app uses. Product code should never know what plan a customer is on directly — it should ask the billing module "is this action permitted?" and let the module answer.
4. What's your read vs. write seam?
Reads outnumber writes by orders of magnitude in most SaaS. A clean seam between them is the single biggest scaling lever. It lets you add read replicas, aggressive caching, and materialised views on the read path without touching write correctness. This is cheap to design in, expensive to retrofit.
5. Where does observability live?
If you cannot answer "what is slow right now?" and "which customer's traffic is in the top 1% of cost this month?" in under five minutes, your production is a black box. Structured logging, per-tenant metrics, and traces from day one. Every AI agent call attributable to a user, a feature, and a dollar amount.
How to scope architecture without derailing your launch
The failure mode for founders is spending three months on architecture before shipping anything. The failure mode for engineers is shipping a prototype and never revisiting the decisions. Both are avoidable.
The 90-minute opening move. One founder, one engineer, one whiteboard (or Miro) session to draw the system: boxes for services, arrows for data flow, diamonds for the five decisions above. Most MVPs will land on Pattern 1 in this session.
Decide the top three trade-offs explicitly. Tenancy model, sync vs. async agent calls, database-per-feature vs. shared schema. Write the decision down with the reasoning. Future-you will thank past-you when someone asks "why did we choose shared tenancy?" in a sales cycle.
Budget architectural debt. An MVP will accumulate shortcuts. Accept that. But keep a list. Every quarter, spend one engineer-week paying down the most expensive item on it. Process automation workflows — the kind our business automation service builds — are a great first refactoring target because they are usually already behind a queue.
Re-evaluate at 10×. Every time your user count or data volume hits a 10× milestone, re-walk the five decisions above. Most hold up. One usually doesn't. That's normal.
Working with an engineering partner on your architecture
Most SaaS founders don't need a full-time staff engineer for their first 18 months. They need someone senior on the key decisions, and a team that can ship the MVP around those decisions without requiring architectural supervision every day. That is exactly the shape of a QwertyBit custom software development engagement — the founder personally leads the architecture decisions, the senior team delivers the build, and your engineers inherit a codebase they can reason about from day one.
Our fintech compliance case study is a good example: a regulated B2B SaaS where the architecture decision (on-prem LLM, isolated data perimeter) was worth more than the build itself. Our document automation engagement is another: the architecture separated ingestion from reasoning from delivery, so each could scale independently as volume grew. Both started with a 90-minute opening session like the one above.
If you are scoping an MVP, considering a rewrite, or staring at a legacy system wondering whether to refactor, book a scoping call. We have run enough of these conversations to give you a sharp answer within a week — not a proposal deck three months later.
Written by
Vlad Niculescu — Founder
Software engineer with 10+ years of production experience and a decade inside London's AI, fintech and startup scene.