Signs Your SaaS Architecture Needs an Audit

An audit is due when the same kinds of surprise keep arriving

A SaaS architecture usually does not fail all at once. It gives notice: a deploy that somebody has to hold their breath through, an outage that nobody can fully explain, a security questionnaire from a large customer that takes three weeks to answer. Each one is explainable on its own. Together they are the product telling you that what it was built on is no longer what it is carrying.

This page lists ten signs, in the order we see them matter, and says what each one usually means underneath. It also describes what an independent review should give you at the end, so you can tell a useful audit from a long document. The checks are ours, drawn from reviewing products we run and from published standards that are linked where they apply. They are not a guarantee about your system, and several are rules of thumb. Where a sign is a judgement call, the text says so.

If three or more of the first eight apply, an audit is likely to repay its cost. If either of the last two applies, do not wait. The review itself is described on our SaaS architecture review page.

Ten signs, grouped by where they show up

Delivery: how changes reach production

1. Deploys are an event. If shipping needs a quiet hour, a specific person, or a rollback plan that lives in somebody's head, the system has no safe path to production. The usual cause is a manual step nobody wrote down, a database change coupled to the code release, or no way to go back. The DORA research programme names the measures worth watching: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate. You do not need a dashboard. Ask the team how long a fix takes to reach production and how often a release needs immediate repair, and notice how long the answer takes.

2. Only one person can fix it. A bus factor of one is an architecture problem as much as a staffing one, because it means the system is understood by recall and not by documentation, tests or structure. A review will find the parts only one head holds. If what is missing is senior judgment rather than more hands, a fractional CTO is one way to cover it.

3. Every feature takes longer than the last. Some slowdown is normal. A steady rise in the time to add similar features usually means the structure fights the change, for example business rules spread across screens, handlers and database triggers, so that one rule has to be changed in four places.

Data: what the system remembers and can recover

4. Nobody has restored a backup this quarter. A backup you have never restored is a hope. The PostgreSQL documentation on continuous archiving is blunt about how it fails: if WAL archiving is not monitored correctly, "the backup might not include all of the WAL files and will therefore be incomplete and not able to be restored". The test is simple: restore last night's backup to a scratch environment, run the application against it, and time the whole thing. If nobody can say how long that takes, you do not know your recovery time.

5. The database is the bottleneck, and the fix is "a bigger server". Scaling up a database is a legitimate first move and a poor only move. If the answer to every slow page is more memory, the cause is probably missing indexes, queries that load a whole table to show ten rows, or reports running on the same database as live traffic. A review reads the slow queries and the access patterns, not just the graphs.

6. Tenant separation is a convention, not a constraint. In a multi-tenant product, "every query remembers to filter by customer" is a convention, and conventions fail on the one route somebody forgot. Stronger designs make the tenant part of the identity in the token and part of every relationship in the schema, so a request cannot reach another customer by asking nicely. This is the single most expensive thing to fix late, because it touches every table and every query.

Access: who can do what

7. Authorisation is checked in the interface, not on the server. The top entry in the OWASP API Security Top 10 (2023) is broken object level authorization, and the next entries include broken authentication and broken function level authorization. In plain words: the server must decide, for every request, whether this caller may act on this particular record. Hiding a button is not a check. If your team cannot point to where that decision is made, assume it is made inconsistently.

Visibility: how you find out

8. You learn about outages from customers. Google's SRE book names the four golden signals of monitoring: latency, traffic, errors and saturation. If you cannot see those four for your own product without logging in to a server, your first alert is a support email. A review will also ask whether a service level is defined at all. An SLO is "a target value or range of values for a service level that is measured by an SLI", and without one, "reliable enough" is an opinion.

Urgent: signs that should not wait for a quarter

9. A credential endpoint has no limit. Sign-in, one-time-password send and password reset each need rate limits per address and per account, plus lockout or progressive delay, and uniform responses so they do not reveal which accounts exist. In our own reviews, the defect we meet most is a throttle that exists in the code and silently does nothing, for example because it keys on a value the client can change. The only way to find one is to try to break it. If you have never tested your limits by exceeding them, treat them as absent.

10. Secrets or customer data in places they should not be. Keys in the repository history, a database snapshot shared in chat, production credentials on a laptop, or customer data in a staging environment. These do not degrade gracefully. One leak is the whole problem, and the fix is rotation plus finding out how it happened.

What the signs usually mean underneath

Most of the ten reduce to four root causes, and naming the cause is the real value of a review, because fixing symptoms one by one is how products end up in rewrites.

• Structure that predates the product. The first version was built to find out whether anyone wanted it, which was the right call. The shape it left behind is now carrying customers.
• Knowledge held in people, not in the system. Tests, scripts, documentation and automated checks are how a system stops depending on one person.
• Safety nets that were never exercised. Backups, alerts, limits and rollbacks that exist and have never been used in anger.
• Boundaries enforced by habit. Tenant separation, authorisation and secrets handling that depend on every developer remembering.

What an independent review should hand back

An audit is only worth buying if you can act on the result. Judge any review, ours or another studio's, against this list:

1. A written scope before it starts. Which parts of the system, which environments, and what is out of bounds.
2. Findings ranked by likelihood and impact, each with the evidence for it: the query, the route, the configuration, not a general statement.
3. A recommendation for each finding, with its cost in effort, so you can choose what to do and in what order.
4. A distinction between what is wrong now and what will become wrong later. A review that treats every observation as urgent is useless in practice.
5. A walkthrough with your team, so the findings are understood by the people who will fix them, not just delivered.
6. Nothing that requires you to replace your developers. A good review works alongside the team that already knows the system.

It should also say what it did not check. Our own review service covers architecture, API and database design, authentication and authorisation, infrastructure and deployment, backup and recovery, monitoring, reliability and cost, and it is described on the SaaS architecture review page and the wider architecture advisory page. It is a technical assessment. It is not a penetration test and not a compliance certification, and BitsSolved holds no SOC 2, ISO 27001 or HIPAA attestation. If a customer requires one, that is a separate programme with an accredited auditor.

What to do before you buy anything

You can establish a lot in a day, without a vendor:

• Restore a backup to a scratch environment and time it.
• Ask the team to draw the system on a whiteboard. Where they hesitate is where the risk sits.
• Try to exceed your own sign-in and reset limits from one address, then from several.
• Pick three API routes and ask where the server checks ownership of the record being requested.
• List who holds production access, and when each credential was last rotated.
• Read the last three incidents and check whether the fix addressed the cause or the symptom.

If those six produce uncomfortable silence, you have your answer, and the review becomes a way of ordering the work. For how this kind of work is sized and quoted, see SaaS development cost in India.

Frequently asked questions

How do I know if my SaaS needs an architecture audit?

If deploys feel risky, outages are hard to explain, backups are untested, or a larger customer is about to send a security questionnaire, an audit will probably pay for itself. Three or more of the first eight signs on this page is a reasonable threshold, which is a rule of thumb and not a measurement. Either of the last two justifies one on its own.

What does a SaaS architecture review cover?

At minimum: application and API design, the database, authentication and authorisation, infrastructure and deployment, backups and recovery, monitoring, reliability and cost. A good scope is written down before the work starts, including what is excluded.

Is an architecture audit the same as a penetration test?

No. A penetration test attacks the running system from outside to find exploitable weaknesses. An architecture review reads the design, the code and the configuration to find structural risk. They answer different questions and are often worth doing in sequence.

Do I have to replace my developers?

No. A review is most useful when it works alongside the team that built the system, ends with a walkthrough of the findings, and leaves the team better informed than it started.

What should an audit deliver?

A prioritised list of findings with evidence, a recommendation and an effort estimate for each, and a clear line between what needs attention now and what can wait.

Can you audit a product another agency built?

Yes. Systems inherited from previous developers are among the most common reasons for a review. Getting your website back from a previous developer covers the ownership side, which should be settled first.

Start here

1. Restore last night's backup somewhere safe and time it.
2. Count how many of the ten signs apply.
3. Write down the three incidents that hurt most in the last year and their causes.
4. If three or more apply, ask for a written scope and a fixed quote for a review.
5. Keep the findings ranked, and fix the top of the list first.

If you want an independent read on your product, that is ordinary work for us: SaaS architecture and technical advisory for a review, and SaaS product development when the findings turn into build work. The first call is free, and nothing is chargeable until you have approved a written quote for a scoped phase.