Know it works before your customers find out it does not
We Are Monad is a London QA and testing team, part of our wider software services. Manual and exploratory testing, automated suites, performance testing and accessibility checks, run by senior engineers who can read the code they are testing. Scoped honestly, priced per phase, and the first call is free.
The release that worked on a laptop and broke in production
A regression pass eats two days of somebody's week, every time, by hand. Bugs get reported by customers instead of found by the team. And when it is time to ship, nobody can actually say whether the release is safe. That is what QA fixes: a repeatable way to know before you ship, not after.
What we test
Six ways to find out whether a release is safe, from a one-off pre-launch review to a suite that runs on every change.
Pre-launch QA and release readiness
An honest go or no-go before you ship, covering the critical paths, the edge cases and the questions your team has been putting off. You get a clear list of what must be fixed, what can wait, and what is fine.
See our custom software workManual and exploratory testing
A person trying to break it the way a real user would: clicking the wrong things, going back a step, using it on a bad connection. This is where the bugs an automated check would never think to look for turn up.
Automated test suites
Unit, integration and end-to-end tests with Playwright, running in CI on every change. Coverage where it will keep paying you back, not coverage for its own sake.
Performance and load testing
We find the ceiling before your customers do: how the product behaves under real traffic and data volumes, and where it starts to slow down or fall over.
See our cloud servicesAccessibility checks
Keyboard navigation, screen reader support, colour contrast and focus order, checked by hand rather than by an automated scan alone, so the product works for everyone who uses it.
Bug triage and reporting
Reproducible reports with the steps, the environment and the expected result, plus a triage process that stops the same bug quietly coming back in the next release.
Why teams pick us for QA
Plenty of agencies can run a checklist. Fewer can read the code, and fewer still will tell you when not to automate.
Testers who can read the code
Our QA engineers are software engineers, so a bug report says where it broke and why, not only that it broke. That turns a fix from a guessing game into a five-minute job.
Automation only where it pays for itself
A fragile test suite that breaks on every unrelated change is worse than no suite at all. We automate what has settled and test the rest by hand, and we will tell you when automation is not yet worth building.
Experience with software that has to hold up
We have tested software that moves money, on Hubpay's fintech app, and software used by staff across a large business, on Carlsberg's Skillable rebuild. Read the Hubpay case study for how that engagement ran.
Reports a non-engineer can act on
Findings ranked by what they cost you, not by how interesting the bug is, so whoever is making the ship or no-ship call can read the report and decide without needing us in the room.
How a QA project runs with us
Small steps, real testing early, and a release you can trust at the end of each one.
Week 1
Assess
We look at the product, the codebase and the last few releases to find where quality is actually at risk, then agree what we will test first.
Weeks 2 to 3
Test plan and first pass
A manual and exploratory pass against the critical paths, with a prioritised bug list back to your team within days rather than weeks.
Weeks 4 to 6
Automate the repeatable
The checks worth running on every change move into an automated suite with Playwright, wired into your CI so a failing test blocks a bad release.
Ongoing
Gate every release
The suite runs on every change, and we keep it honest as the product moves, so a release is either safe to ship or you know exactly why it is not.
QA and testing: common questions
It depends on the scope: a one-off pre-launch review costs less than an ongoing automated suite wired into your CI. We price per phase after a short discovery call, so you get a fixed number before we start rather than an open-ended bill. The first call is free and we will tell you honestly if a smaller engagement covers what you need.
Yes. Most of our QA work is on somebody else's codebase: an agency handover, an in-house build, or a product that has grown past the team that made it. We start by reading the code and mapping the critical paths, then test against what the software is supposed to do, not just what we already know about it.
Usually both, in sequence. Manual and exploratory testing finds problems early and cheaply while the product is still changing shape. Automation earns its keep once a feature has settled and you are running the same checks release after release. Do not automate a test suite for a product that is still changing shape every week: you will spend more time rewriting tests than the tests save you.
Playwright for end-to-end and browser testing, alongside unit and integration tests written in the same stack as your product, most often React, Next.js and React Native. Suites run in CI on GitHub Actions on every change. For mobile, we test on real iOS and Android devices as well as simulators, because that is where the real bugs show up.
A first pass of manual and exploratory testing typically surfaces a working list of issues within the first one to two weeks. Automated coverage takes longer to build but starts paying off as soon as it runs in CI, catching regressions before they reach a release rather than after a customer reports them.
Yes. We test how your software behaves under real traffic and data volumes, not just how it looks in a demo, so you know where the ceiling is before your customers find it for you. That covers page load, API response times under concurrent load, and how the system degrades when it is pushed past normal usage.
Yes, and it is one of the more common shapes of this work. We plug into your existing sprint cycle, write tests your developers can read and extend, and hand over the suite rather than keeping it as a black box. Where useful, we also train your team on the patterns so QA does not depend on us staying involved.
Read before you buy
Practical notes from our own QA work, for teams deciding what to test first.
Find out whether your next release is safe to ship
Bring the release you are worried about, or the product nobody has properly tested yet. In one free call we will tell you what needs testing first, roughly what it would cost, and what to leave alone for now.
No commitment. Honest answer either way.