Agency architecture advice: what to check before signing

Why a diagram is not enough

A tidy system diagram can feel reassuring in a sales call. Boxes, arrows, cloud icons, and clean labels make the work look settled before anyone asks the hard questions.

The problem is that a diagram only shows what exists. It does not explain why each part is there, what simpler option got rejected, or what your team will need to live with later. You can see a queue, a cache, two databases, and a cluster. You still do not know which problem each one solves.

That missing context matters. If a proposal includes five services, each one needs a clear reason. "Best practice" is not a reason. "Future scale" is not enough either. Your team will pay for those choices in time, money, support work, and hiring pressure.

A few direct questions cut through weak thinking fast:

• What problem does this component solve today?
• What happens if we remove it?
• When do we actually need it?
• Who will maintain it after launch?

Scale is another blind spot. Many diagrams look fine at current traffic because they hide failure points. Ask what breaks first if usage doubles, data volume grows fast, or one outside service slows down. A serious answer names the likely bottleneck and the fix. A weak answer stays fuzzy.

Costs also hide outside the picture. A diagram rarely shows log storage, backups, monitoring, build jobs, support work, vendor fees, or the hours your team will spend learning unfamiliar tools. A build that looks clean on day one can become expensive every month after that.

This shows up most often in stacks that are too heavy for the company using them. A small SaaS team might get a proposal with Kubernetes, multiple databases, a message bus, and several managed services. That setup is right for some products. It is also an expensive way to solve problems that may not exist yet.

Before you approve anything, ask the agency to turn every box into a decision. Each decision should come with a reason, a failure mode, and a running cost. If they cannot do that, the diagram is decoration, not a plan.

What a proposal should explain

A useful proposal starts with the business goal, not the stack. "We need to cut release time from two weeks to two days" tells you far more than "we will use microservices." If an agency cannot explain the problem in plain language, the design probably fits their habits more than your company.

Most teams do not have one perfect answer. They usually have two or three workable options. A SaaS company might keep a modular monolith for another year. It might split out billing first. It might separate reporting and leave the rest alone. More than one path can work. The right choice depends on team size, budget, release pace, and how much operational risk you can handle.

Ask the agency to show the options they considered and why they dropped them. That part often tells you more than the final diagram. If they rejected a simpler design, they should explain why. If they picked a more complex one, they should name the price in plain terms: more operations work, longer onboarding, harder debugging, or tighter vendor dependence.

A proposal should also make the weekly workload visible. Architecture is not only a build cost. Someone has to run the system, watch it, fix it, and pay for it.

You should be able to get simple answers to questions like these:

• How many engineers do we need after launch?
• Which tools need paid licenses?
• Who handles monitoring, security updates, backups, and incidents?
• What support is needed on weekends or after hours?

This is where many proposals go soft. They describe the build, then skip the people and tools needed to keep it alive. If your product team has five people but the design assumes a full-time platform engineer and round-the-clock support, the plan is too heavy for your stage.

You also need clear success and failure conditions. A real proposal sets targets and limits. Success might mean deployment time drops below 15 minutes, uptime stays within your target, and your own team can support the system after a short handoff. Failure might mean cloud spend doubles, bug triage slows down, or every meaningful change still depends on the agency.

When those conditions are missing, you are not reading a decision document. You are reading a technical pitch. That is a weak basis for a contract, especially when the real cost shows up months after launch.

Ask about tradeoffs directly

A clean diagram can hide expensive choices. If an agency cannot explain what you gain and what you give up, they are selling a story, not giving advice.

Put direct questions on the table and wait for direct answers:

• What do we gain from this choice, and what do we give up?
• If usage doubles, what gets worse first: speed, reliability, or team workload?
• Where will custom code pile up over time?
• Which parts make us depend on one vendor?
• What is the simpler option, and what problem would it leave unsolved?

Vague answers are a warning sign. "It scales better" is not enough. A useful answer sounds like this: "This will cut launch time by about a month, but your team will spend extra time every week on monitoring and deployment work."

Speed, reliability, and team effort rarely improve together. A cache can make pages feel faster, but stale data bugs appear more often. Microservices can isolate failures, but a small team may spend far more time on deployments, logs, and service-to-service issues than on product work.

Pay attention to where custom code will collect. It usually builds up in integrations, permissions, billing rules, sync jobs, and admin tools. Those areas change often. Every shortcut there turns into future maintenance.

Vendor dependence also needs plain language. A proposal might lean heavily on one cloud database, one queue, one search engine, or one workflow tool. That is not always bad. It becomes a problem when the agency pretends replacing it later will be easy when it clearly will not.

Ask for one simpler design on purpose. A thoughtful agency can say, "We can keep this as one app for now, skip the event system, and accept slower reporting until the product grows." That answer gives you a real comparison point. It also tells you whether they know how to solve your problem or just how to add more parts.

Check the exit path before you sign

Before you sign, ask a plain question: "If we part ways in six months, what do we need to keep this running ourselves?" The answer should name files, accounts, people, and tasks. If you get vague promises about future support, treat that as a warning.

A clean exit path matters more than most buyers think. A system diagram does not tell you whether another team can take over without days of guesswork. An exit plan does.

Start with ownership. You should know who owns the source code, deployment configs, domain records, cloud accounts, monitoring tools, and build pipelines. If the repository lives in the agency's account, or production runs under their billing profile, you can lose control at exactly the wrong moment.

Get these items confirmed in writing:

• code repositories and admin access
• cloud, DNS, email, and analytics accounts
• deployment configs, backup process, and secret handling
• data export method for each outside service
• runbooks for releases, incidents, and restores

Data deserves extra attention. If the stack uses outside tools for auth, payments, email, logging, or search, ask how your data leaves each one. You want usable exports, not screenshots or a promise to "help later." Ask what format you get, how long exports take, and whether the agency can test a sample before launch.

Then ask for the handover material early. Good notes should cover setup steps, naming rules, environment variables, routine jobs, and known failure points. A short runbook matters more than a polished slide deck.

One practical test works well: could one capable employee handle the daily operating tasks after a short handoff? That person should be able to deploy a change, restart a failed worker, rotate a secret, restore a backup, and find the logs. If the agency says you will always need them for those tasks, the design depends too much on the builder.

Exit paths feel boring during a sales cycle. They feel urgent when the relationship changes.

Estimate operating costs step by step

Monthly cost decides whether a system stays practical after launch. A serious proposal should show that monthly picture with clear assumptions, not just a one-time build quote.

Start with the bills that appear every month, even when nothing dramatic happens. Count compute, databases, and hosting. Add storage, file delivery, network traffic, and backups, because those often grow quietly until the bill jumps. Include monitoring, error tracking, logs, alerting, and security tools. Then add the human work behind releases, patches, routine checks, and small production fixes.

Do not ignore incident time. Outages and failed deployments cost team hours even when the cloud bill stays flat.

A proposal that skips several of these items is incomplete. Many agencies price the visible parts and leave the background work for your team to absorb later.

Then ask for two models: a normal month and a busy month. A normal month might mean steady traffic, routine releases, and no major incidents. A busy month should reflect a launch, a customer import, seasonal demand, or a marketing push that sends usage well above average.

This matters because costs rarely rise in a smooth line. A small SaaS can sit comfortably on one database tier for months, then hit a plan threshold and jump to a much higher bill. Logging and monitoring often do the same. Backup retention can too.

Ask the agency to name the exact places where cost jumps happen sharply. That could be when you need read replicas, a larger database class, more build minutes, longer log retention, or a support plan with faster response times.

People time belongs in the estimate as well. If a "cheap" setup saves $300 in hosting but burns 15 engineer hours a month in manual deploys, patching, and night-time incident response, it is not cheap.

A simple forecast works best. List each cost line, note the usage assumption behind it, and mark what changes in a busy month. If the agency cannot explain that in plain English, the system is probably harder and more expensive to run than it looks.

A simple example from a growing SaaS team

Picture a SaaS company with six engineers, one product, and a backlog that keeps slipping. An agency arrives with a polished proposal: split the app into eight microservices, add an API gateway, managed queues, separate auth, and a full observability stack.

The diagram looks neat. The problem is obvious. The same six people still have to build, deploy, monitor, and debug all of it.

For a team that size, a simpler modular app may ship faster and break less often. One codebase with clear module boundaries, one main database, background jobs, and a small number of internal interfaces can handle far more load than agencies like to admit. It is also easier to support. If billing fails at 2 a.m., one engineer can trace the issue without opening five repositories and three dashboards.

This is where the review gets practical or turns vague. The team should ask what they gain now, not what sounds impressive in a pitch deck. If the agency says microservices will help future hiring, ask when that future starts. Will the company hire three more backend engineers this year? Will traffic grow fast enough to force separate services soon?

A few questions usually expose the tradeoffs:

• What traffic level would actually push this app past a modular design?
• Which part should split out first, and why that part?
• Which managed services add monthly fees after launch?
• How hard is it to replace those services later?

Hidden costs often sit outside the build quote. Managed logging, tracing, queueing, secret storage, and network traffic can add a painful monthly bill. Some tools are cheap to start and expensive to leave.

The better choice depends on hiring and traffic. If the company expects one product line, steady growth, and a lean engineering team, the modular app is often the better bet. If it already runs at high volume or plans to split into several product teams, microservices may be worth the extra work. The right answer is the one your team can afford to run, not the one that looks most advanced.

Common buyer mistakes in agency reviews

Many buyers judge an architecture proposal by how clean the diagram looks. That is the first mistake. A diagram can hide the hardest parts: traffic assumptions, response time targets, data rules, failure recovery, and who will run the system every week.

If the agency cannot write those assumptions down, you are not reviewing architecture. You are reviewing a picture.

Another common mistake is paying for scale you do not need. Agencies often pitch a 20-person SaaS company a stack with queues, event buses, multiple databases, and failover across regions before the product even has steady demand. That can feel safe. Usually it means more moving parts, more vendors, and more monthly cost. Buy the next stage, not the year-five version.

Teams also forget to price the people side. A design that depends on rare specialist skills can look smart on paper and still hurt you later. If normal operations require a senior Kubernetes operator, a database tuning expert, and a cloud networking specialist, your hiring risk rises fast.

Support after launch gets ignored too often. Buyers focus on build cost, then discover the proposal never said who handles upgrades, after-hours issues, incident response, backups, or security patches. Ask for a simple support split: what the agency owns, what your team owns, and how fast each side responds when production breaks on a Sunday.

The last trap is the polished demo. Demos help, but they can hide manual steps, temporary code, and hand-tuned data. One smooth walkthrough should never outweigh written tradeoffs, operating costs, and an exit path.

Before approval, check a few plain things:

• written assumptions behind the design
• clear reasons for each major tool
• skills needed to run it month to month
• support scope after launch
• a simpler version that fits your current size

If the agency cannot explain why the simpler option loses, keep asking. That habit saves money and keeps you out of systems your team cannot maintain.

A short checklist before approval

A proposal should still make sense after the meeting ends. If you cannot explain it to someone else in two minutes, the design is probably too vague, too complex, or too dependent on the agency that made it.

A short checklist keeps the discussion practical and stops a polished diagram from hiding future pain.

• Ask for a plain English version. The agency should explain what each major part does, why it exists, and what breaks if you remove it.
• Look for tradeoffs, not a sales pitch. Every design choice has a cost.
• Check who can run it after launch. Your team should know what needs daily attention, what needs specialist work, and what the agency will keep doing if you stop working together.
• Get a monthly cost range. You need a rough low, expected, and high monthly range for hosting, outside tools, support, and incident work.
• Ask how to make it simpler later. You want a clear path to remove services, merge components, or move to cheaper options if the product changes.

A small SaaS team can use this checklist in one call. If the agency proposes Kubernetes, event queues, three databases, and several paid services, ask which parts are required on day one. Sometimes the honest answer is that a much smaller setup will do the same job for the next 12 months.

If any of these answers are missing, do not approve the proposal yet. Ask for a revised version with plain language, cost ranges, ownership after handover, and at least one simpler fallback design.

When to get a second opinion

If the proposal sounds polished but leaves you guessing about cost, staffing, or handover, pause before you sign. A second opinion usually costs far less than fixing the wrong stack after the build starts.

Ask one outside reviewer to read the proposal, system diagram, and scope together. They should answer a few simple questions. Does this fit your team size? Can you afford to run it each month? Can another team take over without a messy rewrite?

A good review should end with a short written note for decision-making, not a showpiece deck. It should cover the main tradeoffs, likely monthly operating costs, the points where costs can rise fast, the exit path if you switch vendors or bring the work in-house, and the handover risks.

That note gives you something solid to compare against your budget and your current team. It also makes agency claims easier to test. If they cannot answer a short written list of risks and costs, that tells you enough.

Be honest about your team. A design that needs senior operations support, constant tuning, and deep cloud knowledge may look impressive and still be a bad fit for a small SaaS company with two developers and a short runway.

Second opinions work best before signatures, migrations, and long retainers. At that stage, you still have room to change scope, ask for a simpler plan, or require a cleaner handover model.

If you want an outside review, oleg.is is a practical place to start. Oleg Sotnikov works as a Fractional CTO and startup advisor, and his background spans product architecture, production infrastructure, and helping small teams move faster without taking on avoidable complexity.