Industries
Software quality in SaaS
A SaaS product is a release cadence with a business attached. The quality problems that matter are the ones that make the cadence slow down — a regression pass nobody can shorten, a tenant boundary nobody tests, a security questionnaire that arrives with a deal attached.
What shapes SaaS software
What tends to go wrong
Weekly releases outrun manual regression. The suite that fit a quarterly cycle becomes the reason the quarterly cycle cannot shorten.
Multi-tenancy turns one access-control mistake into a cross-customer data incident, and tenant isolation is rarely covered by feature tests.
The first enterprise prospect arrives with a security questionnaire and a penetration-test requirement, usually with a deadline attached.
Free-trial, upgrade and cancellation paths touch billing, entitlements and email — and break quietly, because nobody on the team walks them weekly.
What binds you
GDPR
You are almost certainly a processor for your customers’ data and a controller for your own. That means a processing agreement each way, a defensible answer on sub-processors and transfers, and — the part that reaches engineering — a test environment that does not quietly become a second copy of production personal data.
NIS2
Most SaaS vendors are not themselves in scope, but customers who are will push the obligations down the contract: incident notification windows, supply-chain security evidence, and a named security contact. In practice it arrives as a questionnaire long before it arrives as law.
Cyber Resilience Act
Usually not you, and that is worth knowing. The CRA covers products with digital elements placed on the EU market; pure SaaS sits outside it unless remote data processing is integral to a product someone buys. Worth confirming rather than assuming, because the reporting duties start on 11 September 2026.
Engineering practice, not legal advice.
How we work on it
What that means in practice
We build the regression layer that lets a weekly release stay a weekly release: automated coverage of the flows that generate revenue, run in CI on every merge rather than by hand before a deploy. Alongside it we test tenant isolation and role boundaries directly, and run OWASP-based assessment against the questionnaire enterprise buyers will send you, so the answer exists before the deal depends on it.
Related reading
- Test automation
CI test gating: deciding what a red build is allowed to stop
Wiring a suite into a pipeline takes a day. Deciding what it may block is the real project, and it is a social agreement with a configuration file attached.
- Test automation
Diagnosing flaky tests: a procedure, not a retry
A retry policy converts an unreliable suite into a slow one that sounds confident. Four families of flake, the tell that identifies each, and the order to work through them.
- Test automation
Test data management: five strategies and what each one costs
How a test obtains the state it needs decides whether a suite survives parallel execution. Five approaches, the failure mode of each, and the problems nobody puts in the estimate.
FAQ
SaaS questions we hear often
We release weekly. Where should automation start?
With the flows that carry revenue and the ones that are expensive to get wrong — sign-up, upgrade, billing, and whatever your support queue complains about most. Automating the whole regression suite at once is how automation projects stall; automating the five journeys that gate a release is what lets the release stop waiting for a manual pass.
How do you test multi-tenant isolation?
Horizontally, which is the direction feature tests never go. A test authenticates as tenant A and then deliberately attempts tenant B’s resources by identifier — reads, writes, exports, and any endpoint that takes an id in the path or body. The interesting failure is a 200 where a 403 belongs, and it is invisible to a test suite that only ever asks whether the right user can do the right thing.
An enterprise prospect sent a security questionnaire. Can you help?
Yes, and the honest sequence is assessment first, answers second. An OWASP-based assessment across the application and its APIs gives you findings, a remediation pass and a report you can attach. What it is not is a certified penetration test by an accredited body — if procurement specifically requires that, you need a different supplier and we will say so.
Do you work inside our sprints or separately?
Either. Embedded means our people work in your board, your standups and your definition of done; project means we own a defined piece — a framework build, an assessment — and hand it over. Embedded suits a team that already has a process worth joining; project suits one that needs the thing to exist before there is a process around it.
Contact
Building for saas?
Tell us what you are shipping and where it worries you. You will get a considered reply from an engineer, not an autoresponder.