The context
You have a product. Maybe vibe coded, maybe a first MVP built by a freelancer. It works, it has its first users, and you want to take the next step: handing it over to pros.
You ask for quotes. Three vendors, three pitches.
The first proposes to "consolidate what exists and ship fast". The second wants to "rebuild on a microservices architecture with Kubernetes to guarantee scalability". The third talks about event-driven, message brokers, and multi-cloud.
And you have no way to judge. The second one sounds more serious, it uses more impressive words. Maybe it's justified. Maybe it's also the most expensive quote, the slowest one, and the one that locks you in.
This article gives you the reading grid. Not so you can pick the architecture yourself (that's your vendor's job), but so you understand what you're being sold and ask the questions that make the difference.
An architecture is a city-planning decision
Architecture is how your app is split up: one single block or several pieces, and how those pieces talk to each other. There aren't dozens of families to know. There are four, and the house analogy is all you need.
The monolith: the house. Everything under one roof. One app, one database, one thing to deploy and monitor. It's simple, fast to build, cheap to run. The limit: to expand, you expand the whole house at once. What nobody tells you: almost every SaaS you use daily started this way, and many happily stayed there.
The modular monolith: the house with well-designed rooms. Still one house, but every room has a clear purpose, clean walls, doors that close. The day you need to push a wall, you push a wall, you don't raze the house. It's the right default for the vast majority of products, ambitious ones included.
Microservices: the housing development. One small house per function: one for payments, one for accounts, one for emails. Each can be built and renovated by a different team without disturbing the others. But you have to build the roads between houses, run water and electricity into each one, and when a letter gets lost between two houses, good luck finding where.
Serverless: the hotel. You don't own the walls, you pay per night. Zero maintenance, and if a thousand guests show up at once, the hotel absorbs it. Perfect for occasional needs or spiky traffic. The trap: at constant traffic, the hotel bill ends up far above the price of a house. And moving out of a hotel you've grown into all the habits of is a real project.
The main thing to remember: none of these options is "modern" or "outdated". They're answers to different situations.
What microservices actually cost
It's the word that shows up in every other quote, so let's stop on it.
On paper, the argument is true: each service evolves independently, each service can absorb more load on its own. What you're told less often:
- Each service is deployed, monitored, and updated separately. Ten services means ten times the baseline maintenance.
- Pieces that used to talk directly now talk over the network. The network is sometimes slow and sometimes down. Your app has to handle all those cases.
- You need a conductor to keep it all running (that's what Kubernetes is for), and someone who knows how to use it. That someone is expensive.
- A bug that crosses three services gets hunted in three services. Debugging becomes detective work.
The real reason microservices exist is an organizational problem, not a technical one: when fifteen teams work on the same product and step on each other, splitting the product lets each team move without blocking the others. You, with one product and one or two devs, don't have that problem.
A few reference points. Shopify absorbs Black Friday on a (well-organized) monolith. Stack Overflow served a good chunk of the internet with a handful of servers. And the Prime Video team at Amazon publicly wrote about merging microservices back into a single block, cutting their bill by 90%. If they hold up with a well-built house, so will your 200-user SaaS.
That doesn't mean microservices are bad. It means they're a tool for a problem you probably don't have yet.
The 5 over-engineering red flags in a quote
When you reread your quotes, here's what should raise an eyebrow.
- Microservices from day one. For a product still looking for its users, that's building the housing development before knowing whether anyone wants to live in the neighborhood.
- Kubernetes for a single app. It's a tool designed to orchestrate dozens of services. For one app, it's hiring a symphony orchestra to play Twinkle Twinkle Little Star.
- "Scalable" without a single number. Ask: scalable up to how many users? And how many do we have today? If the answer stays vague, the word is decorative.
- Several languages or several databases from the start. Every extra technology is one more profile to hire the day you want to switch vendors.
- A full rewrite as a prerequisite. "Let's start from scratch" is sometimes justified. It's also the most comfortable option for the vendor and the most expensive one for you. A good vendor starts by looking at what can be kept.
And a bonus that sums them all up: the quote talks more about the infrastructure than about your product. Three pages on pipelines and ten lines on your features is a quote written for the engineer's enjoyment, not for your business.
The questions to ask (and the answers that should reassure you)
You don't need to get technical. You need five questions.
The secret weapon first: "Why not simpler?" It's the question that sorts best. A good vendor has a concrete answer, with your context and numbers in it: "because your customers import 2 GB files and that would block everything else". A bad one answers with generalities: "it's best practice", "it's what the big companies do".
Then:
- "How many users does this hold before we have to change something?" You're looking for an order of magnitude, not a promise. Whoever has no order of magnitude hasn't thought about your actual load.
- "How much does it cost per month to run?" The impressive architecture gets paid for every month, in servers and in human time. That number must exist in the quote.
- "If I ask for a small change, what happens?" A simple change should stay simple. If changing a button label means redeploying four services, something's off.
- "If we stop working together, who can take over?" A standard stack, any decent dev can pick up. An exotic cathedral, you stay married to its architect.
Again, you don't have to judge the technical substance of the answers. You judge their shape: are you getting your context and numbers, or slogans?
When complexity is justified
Let's be honest, there are cases where the heavy artillery makes sense.
- Violent, unpredictable traffic spikes. A ticketing site on sale night goes from 100 to 100,000 visitors in ten minutes. There, serverless or a dedicated piece to absorb the spike is relevant.
- Several teams that need to move in parallel. If your realistic, funded plan is three product teams within a year, preparing the split makes sense.
- Regulatory isolation constraints. Health or banking data that must live in a separate environment isn't over-engineering, it's the law.
- A measured bottleneck, with numbers. "This job takes 40 seconds and blocks other users, we're isolating it": that's a healthy justification.
What these four cases have in common: the complexity answers a problem you already have, measured and documented. Not a problem you might maybe have someday if everything goes great.
The rule to remember
If you keep only one thing:
The right architecture isn't the most impressive one. It's the simplest one that holds today's load, with headroom, and doesn't block tomorrow's.
The vendor who proposes simple, with a clear plan to grow the day the numbers call for it, respects you more than the one selling you the full arsenal upfront. The first optimizes for your product. The second optimizes for their invoice, or their resume.
And if you want to see what a badly chosen foundation costs over time, I detailed the real bill in the hidden cost of vibe coding.
Need a second opinion before you sign?
If you've received proposals and can't tell them apart, I can give you a second read: I look at your product and the quotes, and tell you what's justified and what's superfluous. And if you're looking for someone to build your product, check out my custom development offer: we start simple, and beef up the architecture the day your numbers call for it.
For more reading grids like this one, sign up for the newsletter. Substance, no spam.
