SQA, Deployment
From CI to observability: software that ships clean and stays clean.
Usually enters at the launch stage.
- Quality Assurance
- Testing
- Deployment
What it covers.
Automated tests, release pipelines and monitoring, set up so a bad change is caught before your users find it. We take on products we did not build as readily as our own.
Releases should be boring. If shipping is an event — a late evening, a person who knows the incantations, a quiet hope — then the problem is not the release, it is everything upstream of it. We fix the upstream.
That starts with a test plan drawn from how your users actually use the product, not from a coverage target. The paths that would cost you money or reputation if they broke get automated first and run on every change. Then the release itself becomes one reviewed action, deploying to a staging environment that genuinely matches production, with a rollback that has been tried rather than merely written down.
After release, monitoring that a person can read. Errors grouped by what broke rather than how often, alerts routed to someone who can act, and a dashboard whose first screen answers one question: is the product working for the people paying for it? We are as willing to take this on for software we did not build as for our own.
Who it’s for
- Teams whose releases are manual, nerve-wracking, or performed by one person who cannot go on holiday.
- Companies who inherited a codebase with no tests and need to change it without breaking it.
- Businesses who find out about outages from customers rather than from their own systems.
What you get.
Every engagement ends with these in your hands, in your accounts, under your ownership.
- 01
A test plan and automated suite
Unit and integration tests in CI, plus end-to-end tests on the flows that matter most, prioritised by what failure would cost.
- 02
A release pipeline
One reviewed action to ship, a staging environment that matches production, and a rollback that has actually been exercised.
- 03
Monitoring and alerting
Errors, performance and uptime, with alerts going to a person who can act rather than to a shared inbox.
- 04
A dashboard and a monthly report
A view your team can read in fifteen seconds, and a monthly note covering what changed, what broke, what it cost and what we would do next.
Built with
- Playwright
- Vitest and Jest
- GitHub Actions
- Docker
- Terraform
- AWS, Google Cloud, Azure and Vercel
- Sentry
- OpenTelemetry
How it runs from brief to launch
SQA, Deployment follows the same four steps as every discipline here, so adding another one later changes nothing about how you work with us.
- 01
Tell us the outcome
One conversation covers every discipline involved, so you explain the business once, to the people who would do the work.
- 02
Get a written plan
The plan names who does what, in what order and what each part costs, before any of the work starts.
- 03
One team delivers it
Designers, engineers and QA work from the same plan in the same channel, so handoffs happen inside the team.
- 04
We stay after launch
The people who built it keep it running, report on how it performs and keep improving it.
Work in this discipline
Projects where sqa, deployment was one of the disciplines on the plan.
Questions we get asked
The ones that come up in the first call. Anything else, ask us directly.
Can you test software you did not build?
Yes. We start with a test plan from how your users actually use the product, then automate the paths that matter most.
What do you automate?
Unit and integration tests in CI, end-to-end tests for the critical flows, and the release pipeline itself, so shipping is one reviewed action.
Which clouds do you deploy to?
AWS, Google Cloud, Azure and Vercel today. The pipeline and the infrastructure definitions live in your repository, in your accounts.
What do you watch after release?
Errors, performance and uptime, with alerts routed to the people who can act. You get a dashboard and a monthly report in plain language.
Can you work with our existing team?
Yes, and it is the usual arrangement for this discipline. We set up the tests, pipeline and monitoring alongside your engineers and hand over as we go, so the capability stays with you rather than with us.