Cube of spheres, the studio mark

12 years building custom software

Automated software testing for the system you already run

Find out that a release broke something before your customer does — from a team whose own marketplace runs 173 end-to-end tests on every build, whose platform carries 2,053 checks besides, and whose mobile app is driven through 30 journeys on a real device.

See our work
Test Automation//Test Automation//Test Automation//Test Automation//Test Automation//Test Automation//Test Automation//Test Automation//Test Automation//Test Automation//Test Automation//Test Automation//Test Automation//Test Automation//
Sound familiar

You probably came here after one of these weeks

  • “Before every release someone clicks through the same twenty screens by hand. It still gets through sometimes.”

    The check exists, it is just made of a person and their attention on a Friday evening. It scales by hiring, and it fails quietly.

  • “Payments were broken for two weeks. We found out from a customer who could not pay us.”

    Nothing was watching the path that carries the money. The gap between breaking and knowing is where the revenue goes.

  • “We have tests. Half of them are red, nobody remembers why, so the pipeline is set to carry on anyway.”

    A suite nobody trusts is worse than no suite: it costs minutes on every push and buys no confidence at all.

  • “Nobody wants to touch the checkout code. It works, and we would rather not find out what else it touches.”

    This is the expensive one. When a team stops changing a part of the product, the product stops improving there.

The package

Fifteen critical paths under test, green on every push

from $3,900
Fixed for the scope below. Not an hourly rate, so the number does not move while we work. Mobile paths are quoted on top — emulators in CI cost more than a headless browser.
Two weeks
From the first call to a suite running in your own pipeline, not on our laptop.

What you get

  • Twelve to fifteen critical paths, chosen together — the ones that cost you money when they break
  • A suite in your repository: Playwright for the web, Patrol for a Flutter app. Yours, and it stays if we part ways
  • Wired into your pipeline: every push and every pull request, with the result on the pull request itself
  • Video and a trace for each failure, so a developer sees what happened instead of reproducing it
  • Test data that creates itself, so runs do not depend on a database someone seeded once
  • A short runbook on writing the next test yourself, written against your suite
  • Two weeks of fixes after handover, included

What is not included

  • Full regression of every screen — that is a different size of job, and we will say so before you buy this one
  • Load and performance testing
  • Manual checking of each release
  • Fixing the bugs the tests find. We will show you them and quote separately
  • Rescuing a large suite someone else abandoned
173
end-to-end tests on our own marketplace build
30
Patrol tests driving the Flutter app on a device
2,053
automated checks across the operations platform
What ends up under test

The paths we cover, and the surfaces we cover them on

A test suite is worth what its worst uncovered path costs you. So the scope is not "the app" — it is a named list of journeys, each running where your customers actually take it. This is the shape of a typical package; the real list comes out of the first two days.

Your product runs on
Which journeys are covered on which surface
JourneyWebMobile appAPI
Sign-in, sessions, password resetIncluding the lockout after failed attempts and the token that expires mid-session.Covered · WebCovered · Mobile appCovered · API
Checkout and paymentThe card that is declined and the terminal that times out matter more than the card that works.Covered · WebCovered · Mobile appCovered · API
Money moving: deposits, payouts, refundsBalances are asserted after the fact, not just the confirmation screen.Covered · WebCovered · Mobile appCovered · API
The main job your product exists to doAn order placed, a shift closed, a piece of work submitted — whatever pays your invoices.Covered · WebCovered · Mobile appNot covered · API
Roles and permissionsThat the wrong role cannot open the right page is a test, not a code review.Covered · WebCovered · Mobile appCovered · API
Notifications and receiptsPush and email are checked at the API, because a mail client is not ours to automate.Not covered · WebCovered · Mobile appCovered · API
Reports and exports the business readsThe Monday report is opened by the person who signs off your invoice.Covered · WebNot covered · Mobile appCovered · API
Search, filters and the empty stateThe empty state is where a demo breaks in front of an investor.Covered · WebCovered · Mobile appNot covered · API
20 checks — 8 journeys across web, mobile app, api
under testnot on this surface

Empty cells are deliberate. A suite that claims every path on every surface is a suite that was never run.

We test the day it goes wrong, not the day it goes right

The happy path is the one your team already clicks through, and it will be green on the morning your system is losing money. What earns the suite its keep is the deposit that fails halfway, the webhook that arrives twice, the token that expires while a form is open, the network that drops between the payment and the confirmation. On our own marketplace those are not adjectives: the scenario files are named deposit_cardpay, deposit_terminal, token_refresh, reset_lockout, login_unhappy, and two separate arbitration flows for when two people disagree about the same order. We write yours the same way, and we ask you early which failures you have actually seen — that conversation usually rewrites the list.

The marketplace those scenarios belong to

A mobile app is a different job, and most studios quietly skip it

Web end-to-end testing is a solved, comfortable problem. Driving a real Flutter application on a real device — through the system permission dialog, the payment sheet, the push notification, the app that was killed in the background and comes back — is not, and it is where the interesting failures live. We use Patrol for it, because it can reach the parts of the phone that live outside your app. Our own app carries 30 integration tests plus a widget layer, and the backend under it carries 173 more across 24 suites, so the same journey is asserted from both ends. If your product is web-only this is simply not in your quote. If it is not, this is usually the half nobody has covered.

How we build the mobile side

Tests that are green for a reason, not by luck

The reason most suites end up ignored is flakiness, and flakiness is a design problem, not bad luck. So: no fixed sleeps anywhere — every wait is on a condition. No shared fixture that a previous run left behind: each test creates the data it needs and can run alone, in parallel, in any order. External services are stubbed at the boundary, so a third party being slow is not your build failing. A test that fails twice for a reason we cannot name gets deleted rather than retried into silence — a suite you can trust has to be allowed to be smaller than the one you imagined.

24 suites that have stayed green for months

It runs in your pipeline, not on someone’s laptop

A folder of scripts is not a deliverable, because it depends on a person remembering. We wire the suite into whatever you already use — GitHub Actions, GitLab CI, Bitbucket, Jenkins — so it runs on every push and every pull request, and the result lands on the pull request where the decision is made. Failures come back with a video, a trace and the exact step, which is the difference between a developer fixing it and a developer trying to reproduce it. Self-hosted runners are fine, and often cheaper: we run our own CI on a self-hosted machine, so we know what that setup costs to keep alive.

The suite is yours, in your repository, in your language

Everything lands in your repository under your licence, in the stack your team already reads. No agent to install, no dashboard to subscribe to, nothing that stops working when we stop talking. At handover we walk one of your developers through writing a new test from scratch, and leave a runbook written against your suite rather than a generic one. The measure we care about is simple: three months later, are there tests in there that we did not write? If not, we built the wrong thing.

And what we do not do

  • We do not chase a coverage percentage. It is the easiest number to move and the least connected to whether you can ship on a Friday.
  • We do not test in production, and we do not need your production data. Staging and generated data, always.
  • We do not replace a manual tester who knows your domain — we take the repetitive part off them.
  • We do not do load or performance testing in this package. Different tools, different skill, different conversation.
How it runs

Two weeks, and you see something working at the end of each

No discovery phase that produces a document. Every stage ends in something you can open — that is also how you find out early whether you want to keep going.

  1. Days 1–2

    We find out what actually costs you money

    Two hours with whoever knows the product, a walk through the app, and a look at what has broken in the last six months. We come out with a ranked list of journeys and an honest note on which of them are hard to automate and why.

    You seeA ranked list of paths, priced and agreed, before anyone writes a test.

  2. Days 3–5

    The first paths go green

    We set up the harness in your repository and cover the top of the list — usually sign-in and the one journey that carries the money. Small on purpose: this is where we find out how your staging environment really behaves.

    You seeA suite you can run locally, plus the first failures we found on the way.

  3. Week 2

    The rest of the list, and the unhappy paths

    The remaining journeys, then the failures around them: declined payments, expired sessions, dropped connections, the second webhook. On mobile this is where permissions, background kills and the payment sheet get their own tests.

    You seeTwelve to fifteen paths under test, each with a video and a trace when it fails.

  4. Day 9–10

    Wiring and handover

    The suite goes into your pipeline on every push and every pull request, results land on the pull request, and we sit with one of your developers while they write a test themselves. Then a runbook against your suite, not a generic one.

    You seeGreen checks on your pull requests, and a developer on your side who has written one.

  5. The two weeks after

    We stay on the hook

    Included, not an upsell: if a test turns out to be flaky or the product moves under it, we fix it. Keeping the suite current beyond that is our support service, and only worth buying if the product changes weekly.

    You seeA suite that is still green a month later, which is the only proof that matters.

Runs with what you already use
  • Playwright
  • Patrol
  • GitHub Actions
  • GitLab CI
  • Bitbucket
  • Jenkins
  • Docker
What you keep

Three things that stay with you when we leave

Not mock-ups. Every screenshot below came out of a real suite running against this very website — the same shape of deliverable you get, produced the same way.

Playwright HTML report listing ten passing end-to-end tests with their durations

A report that says what passed and what did not

Every run leaves this behind, in your pipeline, on every push and pull request. Ten journeys, each named after the thing it protects rather than the function it calls — so the report reads as a list of promises, not a list of code.

Real report from the suite that runs against swiftandscale.com.

Playwright trace viewer on a failed test, showing the error: broken links, /services/pricing returned 404

And what a failure hands you

Nobody has to reproduce it. The trace replays the run frame by frame — every action, the page as it looked before and after, the network calls, the console — and states the failure in one line a person can act on. Here a link on the home page had started returning 404, and the run named it: /services/pricing. That is the difference between a bug fixed today and a bug argued about for a week.

A real run against this site with one link deliberately broken, so you can see the red as well as the green.

The source of a Playwright spec file with tests named after visitor journeys

The tests themselves, in your repository

Plain code in your stack, under your licence, reviewed like any other pull request. No agent to install, no dashboard to subscribe to, nothing that stops working when we stop talking.

The spec file that produced the report above.

Be honest with yourself

This is worth buying for some teams and a waste for others

Buy this if

  • The product is in production and people already pay for it
  • You ship more than once a month — the suite pays for itself in releases
  • A staging environment exists, or you are willing to have one
  • Something has broken in production in the last six months and you remember what it cost
  • Someone on your side can answer domain questions for a couple of hours
  • There is a developer who will own the suite after we leave

Do not buy this if

  • The product is still a prototype and its shape changes weekly — tests would be rewritten faster than they run
  • You need someone to also fix everything the tests find; that is a separate quote and it can be larger than this one
  • You want a full manual QA function — this covers the repetitive part, not the exploratory one
  • You need certification or a regulatory audit trail; we are not that supplier
  • Nobody will own it afterwards, and it will be switched off within a quarter

If that reads like a no, say so on the call and we will tell you what we would do instead — sometimes the honest answer is a two-day smoke suite rather than this package.

Questions we get about test automation

Short answers. The long ones happen on the call.

From $3,900 for the two-week engagement on this page: fifteen critical paths under test, running in your CI on every push, in your repository. The number moves with what the paths cross — a payment flow or a role model costs more to cover than a signup form — and with how much scaffolding your project already has: if nothing has ever run in CI, the first pipeline is part of the job. What it does not move with is hours: you are buying a working suite with a named scope, not our time.

Often, and we will say so. A hire makes sense when testing is continuous work: a product shipping several times a week, exploratory testing alongside the automated kind, someone who learns your domain over years. What a hire does not do is start on Monday — recruiting an experienced QA engineer takes months, and the first suite still has to be written by someone. Most teams we work with buy the suite first and hire later, against a codebase that already shows what good looks like.

Not as a standing team, and we would rather be straight about it than sell you a seat. We build and hand over the automated part, then keep it alive on a support arrangement if you want one. A full outsourced QA function — release management, test plans per feature, exploratory passes — is people rather than code, and a supplier who does only that will do it better than we would.

By the numbers, and they are countable rather than claimed. Our marketplace runs 173 end-to-end tests across 24 suites on the server and 30 journeys on a real device; the operations platform carries 2,053 checks across three repositories. Both products are open to walk through — the case studies link to demos you can use without asking anyone. Ask any supplier the same question and see whether the answer has a number in it.

That is the usual state, and it is worse than having none: a suite nobody trusts still costs time on every push. We start by deciding which of them are worth saving, delete the rest, and leave you with a small suite that is green for a reason. Rescuing a large abandoned suite is a separate job, and we will say so rather than quietly absorb it.

Because the first fifteen catch most of what actually hurts. Sign-in, checkout, the money moving, the report the director opens on Monday. Covering everything is a programme, not a package, and studios that promise it in two weeks are selling you a suite you will switch off in a month.

Both. Web runs on Playwright, and a Flutter app runs on Patrol against a real device or emulator — including the parts outside your app, like the system permission dialog, the payment sheet and a push notification arriving. Our own app carries 30 integration tests written that way. Native iOS and Android are a conversation rather than a yes: tell us the stack and we will say plainly whether it is in our wheelhouse.

Your pipeline does, on every push, without anyone remembering to. That is the point of wiring them in rather than handing over a folder of scripts. If you would rather we watched the results and kept the suite current as the product changes, that is our support service, priced separately.

Almost everything that matters. We test the deposit that fails, the webhook that arrives twice, the session that expires mid-form, the shift where the network drops halfway through. A test that only proves the good day passes will be green on the morning your system is losing money.

No. Tests run against your staging environment on data they create themselves. If you do not have a staging environment, setting one up is part of our deployment service, and we would do that first.

By treating flakiness as a design problem. No fixed sleeps — every wait is on a condition. No shared fixtures — each test builds its own data and can run alone or in parallel. Third-party services are stubbed at the boundary. And a test that fails twice for a reason we cannot name gets deleted rather than retried into silence.

They usually find some, and that is the point — better on day four than on release day. Fixing them is not in this package: we hand you the list with a video and a trace for each, and quote separately if you want us to fix them. Bundling the fixes would mean pricing a job neither of us can size yet.

Selected work

Both of these are tested the way we are describing

Not a portfolio slide: these are our own products, and every number below was counted in their repositories rather than estimated. Open either demo and try to break it yourself.

Two-sided marketplace app · Creator economy

Marketplaces where the money sits in the middle

A marketplace with two sides, a payment held between them, and an AI studio that bills by the generation. The hard part is never the catalogue — it is deciding, in code, the exact moment money and files change hands.

173 end-to-end tests across 24 backend suites, and 30 more driving the real Flutter app through Patrol — deposits by card and by terminal, token refresh, lockout after failed sign-ins, two arbitration flows. Three of those suites hold nothing but negative cases.

4 months
from kickoff to a working product
173
end-to-end tests, 24 suites
21
data models behind it
Live demo insideRead the case
Creator feed in the marketplace app, with an order button
Made-to-order production platform · Medical manufacturing

Operations platforms where every order is one of one

Made-to-order production has no catalogue and no reorder button. Every item is built for one person from measurements a computer takes off a scan, and the system has to hold that thread from the first appointment through manufacturing, delivery, and the remake eighteen months later.

2,053 automated checks across its three repositories: 1,060 on the backend across three suites, 717 on the web client, and 276 over the vision pipeline, the offline queue and the risk rules. Every order here leaves as a physical object cut to one person’s measurements, so the checks are about numbers rather than clicks.

8 months
and still building — the largest system we run
13
flow families, from intake to remake
2,053
automated checks across its three repositories
Live demo insideRead the case
Order board in the operations platform, with production stages
Every solution we build

Worth reading before you brief anyone

All articles →
Web development

Why two studios quote the same project three times apart

You send one brief and get back three very different numbers. The spread is not greed — it is four different readings of the same sentences, and closing it is your job as much as theirs.

2 min read

Talk to us about test automation

Tell us what you are building

A person reads it and answers within one business day — with a range and the assumptions under it.