Digital Engineering/AI Product Assurance/Architecture & Scalability Review
Find the load your architecture stops holding at
Systems rarely slow down politely. They hold, and then at a particular number, whether a row count, a tenant count or a concurrency figure, several things give way at once. This review finds that number, names the first three components to fail, and gives you a target design and a sequenced path to it.
Working is not the same as holding
There are two versions of this problem, and most products arrive with one.
Failure mode one
A product that works now and will not work at ten times the load.
Nothing looks wrong: response times are acceptable, errors are rare, nobody is complaining. But the design rests on assumptions that were true at launch and are quietly expiring: that a table stays small, that a request can afford to wait on a third party, that one connection per request is fine because there were never many requests. None of them fails gently.
Failure mode two
A product that carries its load perfectly well and cannot be changed.
The structure fights every modification. A pricing rule lives in three places and you must find all three. Two modules both believe they own the subscription record. A change that should take two days takes two weeks, because the blast radius of any edit is unknowable, so each one begins with archaeology.
Both are architecture problems, and both are common in software assembled quickly with AI assistance. This is not because generated code is poor, but because architecture is the thing a generator cannot hold in its head. Each session produces something locally sensible, and nobody asks what the whole design does at fifty thousand rows and a hundred tenants. The decision was never taken. It was inherited, one file at a time.
What the review covers
Data model integrity
Normalisation that suited one tenant fails at twenty: a global unique constraint that should be per tenant, an unindexed foreign key turning a cascade delete into a scan. We check unbounded tables with no archival strategy; soft-delete debt, where half the queries filter on deleted_at and the half written later do not; denormalised columns drifted out of sync; and the multi-tenancy model, since changing that once you hold data is among the most expensive migrations there is.
Service and module boundaries
What the system deploys is rarely what the diagram claims. One deployment unit carrying three unrelated responsibilities and called a service. Components that cannot ship independently, because changing one forces a coordinated release of two others. Shared-database coupling, where two components write the same tables and neither can safely alter a column. Chatty boundaries, where a page render fans out into fourteen internal calls. And duplicated logic across a boundary, because a generator with no memory of the last session re-implements a rule rather than importing it.
State and record ownership
For each significant entity: which component may change it, and what happens when two do. Subscription status written by both a billing webhook and an admin screen, last-writer-wins. We look for eventual consistency assumed rather than designed, and test idempotency against real failure sequences. One recurs: checkout calls the payment provider, the card is charged, your side times out, the job runner retries, and because the idempotency key is generated inside the retry rather than derived from the order, the card is charged again.
Query and load behaviour
N+1 patterns, where a list endpoint loads fifty records then queries once per record and again per nested relation. Endpoints with no pagination, harmless at two hundred rows, fatal at two hundred thousand. Synchronous work belonging in the background: mail, PDF rendering, analytics while the customer waits. Connection pool sizing against real concurrency and query duration. And cache invalidation, including the common case where there is none. Keys omitting the tenant identifier are a correctness problem, not a performance one.
Integration design
Every third-party dependency is reviewed for how it fails. Timeouts that exist, and are short enough for your request budget. Retries with backoff and jitter, not a stampede when a provider recovers. Webhooks that verify signatures, deduplicate on the event identifier and process out of band. Then the question that sets availability: when that provider is down for forty minutes, does checkout refuse, queue and settle later, or hang until it times out.
The specific breaking point
The headline output is a named threshold in whatever unit governs your system, plus the first three things to fail and how. Not “the database becomes a bottleneck”, but “the orders table passes nine million rows, the dashboard’s unindexed status filter exceeds two seconds, connection hold time triples, and the pool exhausts at 09:00”.
Who this is for
Founders who can feel the system straining.
The same pages are slower, a job that finished in minutes now takes an hour, or you have started scheduling deploys for quiet periods without deciding to. You have no engineering leader to ask, and you want a number, not a worry.
Engineering leads who need the argument made externally.
You know roughly where the problems are. What you lack is a written, evidenced case that survives a board wanting three more features first. A review turns your judgement into a document with a number in it.
Teams facing a step change in load.
A large customer going live, a launch, another product’s users migrating onto yours. The load is not speculative and the date is in a calendar.
Anyone considering a rebuild.
Someone has proposed starting again. That is occasionally correct and usually expensive, and it should be settled against a map of the design, not how the team feels on a Friday.
When to book one
When the cloud bill grows faster than usage.
The most reliable early signal. A bill outpacing revenue almost always means something is doing far more work per unit of business than it should: repeated queries, missing indexes, an instance bought to hide a design problem.
When a specific date is coming.
An enterprise customer with ten times your user count goes live next quarter. Book far enough ahead to execute the migration path calmly: a quarter before the load, not a fortnight.
When one component keeps appearing in incidents.
Three unrelated outages that all involve the job queue are not three incidents but one structural problem with three symptoms.
When change has become disproportionate to its size.
A one-line business rule requiring edits in four files and a fortnight of regression testing is a boundary problem, and it will not improve by itself.
When you are about to hire.
Onboarding cost is a function of architectural clarity, and a target architecture is worth more to your first three engineers than documentation written later.
When you are raising or selling.
Diligence examines exactly this, and it is better to hand over a review you commissioned than let it reach your investor first.
How the review runs
Scope and load model
day 0–1
We start with the business, not the code. What do the next twelve to twenty-four months look like in customers, tenants and peak concurrency, and do those figures come from a contract, a pipeline or an aspiration. We convert them into engineering units: rows per month in the fastest-growing tables, peak writes per second, concurrent sessions, largest tenant footprint. The target is agreed in writing first, because an architecture is only sound against a stated load.
Working from your telemetry
days 1–3
Where instrumentation exists we use it: traces, slow query logs, pg_stat_statements or its equivalent, pool metrics, queue depth, cache hit rates, and per-endpoint latency at the 95th and 99th percentile rather than the mean, because averages hide the behaviour that matters. Where it does not, we work from query plans against a restored snapshot, add temporary tracing to the paths in question, sample a week of logs, and reason from schema and code, labelling what is measured and what is modelled.
Design review
days 3–7
Engineers read the system against the load model: schema, boundaries, ownership, consistency behaviour, query patterns, caching, integrations. This is where the structural findings come from, and no tool does it.
Threshold modelling
days 7–9
Each cost that grows with volume is projected against the load model to find where it meets a hard limit, and those limits are ranked by arrival to produce the breaking point and the failure sequence beneath it. Where a projection turns on an assumption, we show it.
Target architecture and walkthrough
days 9–12
A target design, a sequenced migration path, and a live session for your team to argue with it. Anything already exposing you is raised the day we find it, not held for the report.
What you receive
- A named breaking point: the volume at which the current design stops holding, with the working shown so your engineers can check it.
- A ranked failure sequence naming the first three components to fail as that threshold approaches, the mechanism by which each goes, and the indicator to watch.
- A map of the system as it is: data model, deployment units, call paths, record ownership and external dependencies, often the first accurate diagram of the product ever drawn.
- A target architecture for the load you asked us to model, with the reasoning behind each decision recorded so it can be revisited rather than re-argued.
- A sequenced migration path between the two, ordered so each step is independently shippable, reversible where possible and leaves the product live, with the highest-headroom work first.
- A findings register classifying every issue Critical, High, Medium or Optimisation, each with its location, its business impact in plain language and an effort estimate.
- A Retain / Refactor / Replace position on each major component, feeding into a Vibe Code Cleanup engagement whether or not we execute it.
- A recorded walkthrough, so a new engineer or investor can absorb it without a meeting.
How findings are classified here
The four classes are the same across this cluster. What differs is the axis deciding them: arrival time rather than present severity.
Class
Meaning in an architecture context
Expected response
The threshold sits inside your current growth curve, or the design already produces incorrect data in normal operation.
Start now. This is what the next sprint is for.
Beyond today’s load but inside the horizon we modelled, and the remedy takes longer than the runway remaining.
Scheduled this quarter, ahead of the load.
A structural cost paid continuously in delivery speed rather than in outages.
Sequenced into planned work on the surrounding area.
A clear improvement with no deadline.
Do it while that code is open anyway.
The distinction that matters is between High and Critical, and it is arithmetic rather than taste: time until you reach the limit against time the fix takes. When the second exceeds the first, the finding is Critical however healthy things look.
What we need access to, and what we do not
An architecture review needs wider visibility than a code read. The boundary:
Repository access, read-only.
Application code, migration history and infrastructure definitions. Migration history matters more here than anywhere, because the order a schema arrived in explains its shape.
Schema, not records.
We work from a structural dump of tables, columns, indexes and constraints, plus row counts and table sizes. We do not need the contents of your database and do not want them. Where a query plan needs realistic data, you run it and send the output.
Telemetry, read-only.
Monitoring, dashboards, slow query logs, queue metrics. A viewer role is enough.
Infrastructure, read-only and scoped.
A console or IAM role covering the environments in scope, so we see instance classes, pool limits, autoscaling rules and network topology as deployed, not as documented.
No write access and no production credentials.
Nothing here needs either, and load testing, where in scope, runs against staging.
An NDA is signed before scoping. Access goes to named reviewers listed in the engagement note and is revoked on delivery. Snapshots are destroyed on completion unless remediation follows, with deletion terms in the note rather than promised on a call.
An architecture review is not a rebuild proposal
There is a version of this service, sold widely, in which the review is the sales document for the rebuild: the finding is always that the system is unsound, and the remedy is always a project priced at several times the review. It is worth naming, because it is why technical buyers are wary of the category.
A review is a diagnosis, and diagnoses are frequently reassuring. A meaningful proportion of the systems we assess are structurally sound with three or four expensive defects (a missing index, an absent boundary, an integration with no timeout), and the right output is two weeks of work, not two quarters.
Where the news is worse, the output is still not "rebuild". It is a component-level position.
Retain
What works and does not obstruct the target design. A sound component stays, whatever its age.
Refactor
What is structurally fine but wrongly bounded. The logic is right; where it lives and what it owns is not.
Replace
Only where the underlying decision cannot be adjusted incrementally, most often a multi-tenancy model, or a data model whose entity relationships no longer describe the product you sell.
That is deliberately the framework used on Vibe Code Cleanup, because the review is built to feed it. Each component reaches that engagement with a position, a justification and an effort estimate attached, so remediation starts with a plan, not a fortnight of rediscovery, and it still stands if you take it to another supplier.
What changes afterwards
Capacity planning becomes a calculation.
“Can we take this customer” stops being a judgement made by whoever is most confident in the room, and becomes a comparison of a known threshold against a known requirement.
Growth stops being frightening.
There is a particular anxiety in succeeding on a system you do not trust, where every good week brings something closer. Naming the boundary does not move it, but it turns a fear into dated work, and teams behave differently afterwards.
Roadmap arguments get shorter.
A written target architecture ends the debate about building the feature or fixing the foundation: both now hold positions in a sequence rather than competing.
Infrastructure spend usually falls.
Teams facing performance problems without a diagnosis buy their way out with larger instances; once the real cost driver is named, that spend is often reversible.
You stop being surprised by your own product.
Which is what most founders were buying.
Why Noseberry
We commit to a number.
The deliverable contains a threshold and a failure sequence, with the working shown. That is a falsifiable claim and uncomfortable to make, which is why it is worth more than a document of it-depends.
Reviewers have operated systems at scale, not only designed them.
The engineer modelling your connection pool has been on the wrong end of one at three in the morning. Advice from people who never carried a pager is elegant in theory, naive in practice.
The migration path is sequenced to be shippable.
Recommendations arrive as independently deployable steps, highest-headroom work first, because a target architecture reachable only through a six-month freeze is not a plan anyone executes.
We assess AI-built systems constantly.
Noseberry engineers use AI tooling daily under governed conditions and review software built the same way every week, so we know which patterns recur.
One framework across the cluster.This review reports against Product Architecture and Scalability & Performance within The Noseberry Product Assurance Framework, so it slots into a wider assessment rather than beside one. It sits alongside the AI Code Audit and Production Readiness & Hardening engagements, all reporting against the same six dimensions.
Frequently asked questions
You cannot tell from your dashboards, because latency stays flat right up to the point it is not. Three signals matter: a cloud bill growing faster than usage, change effort disproportionate to change size, and repeat incidents in one component. Beyond that it is arithmetic. Take the costs that grow with data volume or concurrency, project them against a stated target load, and find where each meets a hard limit such as a pool size or a memory ceiling. That calculation is what this review performs.
Almost certainly not, and the question is usually a symptom of a boundary problem, not a deployment one. Microservices trade a code-level problem you can debug for a distributed-systems problem you cannot, adding network failure, partial failure and release coordination to a team that may not need it. Most products asking us this need clean module boundaries inside one deployable, which delivers the independence they want at a fraction of the cost. Where extraction genuinely helps, we name the component.
Very rarely, and less often than it feels when you ask. A rewrite discards working business logic, including every undocumented rule learned from a customer complaint, and typically runs two to three times its estimate, because that estimate priced the software you meant to build, not the one you have. It is right when a foundational choice cannot be changed incrementally: a multi-tenancy model, or a data model whose entities no longer match what you sell. That is a component-level judgement, which Retain / Refactor / Replace gives you.
Yes, and roughly half the products we review arrive that way. We work from query plans against a restored snapshot, table sizes and growth rates, schema and code reading, and temporary instrumentation added to the paths in question for a week or two. The conclusions are the same in kind, the confidence is wider, and we label which findings are measured and which are modelled rather than blurring the two. A frequent side effect is that you finish with the monitoring you lacked, because what we add is worth keeping.
Two to three weeks for a single-product system, longer for multi-repository estates or where load testing is in scope. Pricing is quote-led, because effort varies with the number of services, the size of the schema and whether usable telemetry exists. After a scoping call you get a fixed price and a fixed scope in writing, including what is explicitly out of scope. We do not quote an open-ended hourly rate, and we will say so before you commit if the spend looks premature.
Whatever you can justify, agreed in writing before the review starts. We take your twelve to twenty-four month plan and turn it into engineering units, such as rows per month in the fastest-growing tables, peak writes per second and concurrent sessions, then model against that plus a margin. If a figure is aspiration rather than pipeline we model both and give you two thresholds. An architecture is never sound in the abstract, only against a stated load, and that load has to be yours rather than ours.
No. Load testing, where in scope, runs against staging, sized to a ratio agreed beforehand, with results extrapolated and the ratio stated. Most of the review needs no load testing at all: thresholds are calculated from measured per-operation costs and growth rates, which is safer and more precise than driving traffic at a system until it gives. If your staging environment is not close enough to production to be useful, we will say so rather than produce a number that looks authoritative and is not.
No. Shared-schema multi-tenancy is the correct default for most SaaS products and scales a long way. What matters is whether it was done deliberately: every query scoped by tenant, unique constraints per tenant rather than global, indexes leading with the tenant column, caches keyed by tenant, and a workable answer for per-tenant export and deletion. We also assess whether any single customer is large enough to need isolating. Changing the model later is expensive, so the value is in knowing early.
Both, as separate purchases. The review is deliberately available on its own, and plenty of clients take the target architecture and the migration path to their own team, which is an expected outcome, and the reason every deliverable is written to work without us at all. Where you want execution, the Vibe Code Cleanup and Production Readiness & Hardening engagements pick up from the migration path, with the product live throughout. Nothing in the review is written to make the follow-on look necessary.
Yes, and often more urgently, because managed platforms move the limits rather than remove them. You still have connection ceilings, function timeouts, cold starts, row-level security evaluated per query, egress pricing that scales with your least efficient endpoint, and per-plan quotas that become hard walls at a given volume. The review treats platform limits as first-class constraints alongside those in your own code, and the breaking point is frequently a documented quota that nobody had checked against the growth plan.
Find the number before your users do
Send us read-only repository access and a sentence about the load you expect. Within two working days you will have a scope, a fixed price, and an honest view of whether this is the right spend now.
Related resources
Go deeper with our thinking
From Spreadsheets to a Scalable Platform – building Canada’s Most Tenant- First Coliving System
Read case study
How to Build a SaaS Product
Read guide
The MVP Development Guide
Read guide
Building a Digital Engineering Roadmap That Aligns With Business Goals
Read article
Engineering IoT Products: Key Challenges and Best Practices
Read articleNot sure where you stand?
Take a free two-minute readiness scorecard built for your industry.