Manual QA for production releases

Shipping fast?Something's breaking.

AI coding tools and tight release cycles mean more code reaches production than anyone has properly checked. Our QA engineers manually test your releases end to end, so your users aren't the ones who find the bugs.

Manual
Real people testing real user journeys
End to end
From sign-up to payment, across devices and browsers
Go or no-go
A clear verdict on every release
Plain English
Reports your developers and PMs can act on
The problem

Your test suite says green.Your users say otherwise.

Most teams aren't short of code. They're short of time to check it. AI tools write features and tests faster than anyone can review them, and those tests only check what the code does, not what your users need.

So the same pattern repeats: a release goes out, something unrelated breaks, a customer reports it, and the team scrambles.

01Release goes out02Something unrelated breaks03A customer reports it04The team scrambles
CI · release/2.14All checks passed
Unit tests✓ 128 / 128
End-to-end suite✓ 24 / 24
Lint and types✓ clean
↓ deployed to production · 14:02
What your users see3 new reports
14:19
Support · PriyaThree customers say Sign in with Google stopped working.
14:26
App Store · ★☆☆☆☆Update broke my settings page. Can't save anything.
14:31
#engWho touched auth? Rolling back 2.14.
If any of these sound familiar, we can help.
v2.13 · sign-in✓
v2.14 · sign-in✕
Releases regularly break features that used to work.
Reported bycustomer
Customers find bugs before your team does.
Authordev
Testerdev
Developers are expected to test their own work, and don't have time to.
Tests128 ✓
Clicks0
Automated tests pass, but nobody has actually clicked through the product.
Lines added+4,812
Reviewed6%
AI-generated code is landing faster than you can review it.
We can help.Tell us how you ship and where things keep breaking.
Book a call→
What we test

The things automated tests miss

Automation is good at confirming what you expected. Manual testing finds what you didn't. Our engineers use your product the way your customers do, following the happy path and then deliberately going off it.

Hover a layer to see what we check.Tap a layer to see what we check.

release › journeys
Create your account
Email
maya@accepted ✕
Password
••••••••
Sign up ×2 clicks = 2 accounts
Happy path ✓Invalid email acceptedEmpty state missing
Core journeys end to endPASS
Empty, error & loading statesWARN
Form validation & edge inputsFAIL
What users shouldn’t be able to doPASS
How we work

Manual testing, shaped around how you ship

Start with a single release or bring us in for every one. Either way, you get the same engineers learning your product over time.

Most teams start here

Ongoing release QA

A dedicated QA resource on a monthly retainer, testing every production release and maintaining a regression checklist that grows with your product.

Every release, testedchecklist · 58 journeys
2.11go
2.12go
2.13go
2.14caught
2.15next
2.14: Google sign-in regression caught before release
+Every release tested before it goes live
+A living regression checklist for your product
+The same testers, who get to know where your product breaks

Best for: teams shipping regularly who keep breaking things.

Release 2.14 · changed + around it
GoNo-go · 1 critical

Release testing

A manual end-to-end pass before a production release. We test what's changed, re-check the critical journeys around it, and give you a go or no-go.

Best for: major releases, migrations, or anything you're nervous about.

Whole product swept42 journeys
35 working7 already broken

Regression sweep

A one-off manual pass across your whole product to find what's already broken, and to build the regression checklist we'll use from then on.

Best for: teams who've shipped fast for months and suspect things have slipped.

Sprint 14your team + 1
SKJMRTQA
Stand-upJiraSlack

Embedded QA engineer

A manual tester working inside your sprints, your tools and your stand-ups, through our TTaaS model.

Best for: teams who want QA as part of the team, not a service on the side.

Process

From release candidate to sign-off

01/ 05
release-2.14-scope.mdScoped
What’s going out✓
Priority journeys12
Usually breaksauth, billing
Step 01

Scope

You tell us what’s going out, which journeys matter most and where things usually break.

Step 02

Plan

We turn that into a test plan and regression checklist, focused on what changed and what it could affect.

Step 03

Test

Our engineers manually test on your staging or preview builds, across real devices and browsers.

Step 04

Report

Severity-rated bugs with steps to reproduce, filed into Jira, Linear or GitHub, plus a go or no-go recommendation.

Step 05

Retest

Once fixes land, we re-check them and the journeys around them before you release.

Tools & platforms

We test what your AI tools ship

We file bugs in your tracker, work in your Slack and test on your staging or preview environments.

CursorGitHub CopilotClaudeChatGPTWindsurfCursorGitHub CopilotClaudeChatGPTWindsurfCursorGitHub CopilotClaudeChatGPTWindsurfCursorGitHub CopilotClaudeChatGPTWindsurf
PlaywrightCypressPostmank6BrowserStackAppiumGitHub ActionsPlaywrightCypressPostmank6BrowserStackAppiumGitHub Actions
Sample report

Bug reports your team can act on straight away

No vague pass or fail. Every issue comes with a severity, a clear explanation and the exact steps to reproduce it.

+Severity-rated so you know what blocks the release and what can wait
+Steps to reproduce so developers, or their AI tools, can fix it first time
+Filed where you work in your tracker, with screenshots and recordings
CriticalAuth and APIIllustrative example

Any logged-in user can read other users’ bookings

Suggested fix: enforce ownership checks server-side and enable row-level security on the bookings table.

STEPS TO REPRODUCE
01Log in as user A and open a booking
02Change the booking ID in the request to one owned by user B
03The response returns user B’s booking and contact details
EXPECTED403 Forbidden for bookings the user doesn’t own
ACTUAL200 OK with the full booking record
Release 2.14 · 42 journeys testedVerdict: no-go until 2 critical issues are fixed
Who it's for

Built for teams moving faster than their QA

Shipping with Cursor, Claude Code, Copilot and similar tools, and producing more code than anyone can review.

WHAT YOU GET
+Every release tested before it goes live
+Features you didn’t touch re-checked after every release
+Steps to reproduce, so developers, or their AI tools, can fix it first time
Add Stripe payments and user accounts to the booking flow
Feature mergedRelease 2.14
Automated tests✓ green
Database access rules✕ missing
Webhook retries✕ duplicates
Reviewed by a person! not yet
What our clients say
01 / 04
“I had critical technical issues with my taxi app, and Gunpowder Innovations was extremely helpful in resolving them. Their team quickly identified the root cause, provided clear guidance, and supported me through the entire fix.”
RA
Rocket AppCameroon
FAQ's

Frequently asked questions

Anything else, ask us on a call.

Automated tests confirm what someone thought to check. Manual testing finds what nobody thought of: broken journeys, confusing states, device quirks and side effects from unrelated changes. We complement your test suite rather than replace it.

No. We test any product. AI-assisted teams just tend to need it more, because code is landing faster than it can be reviewed.

Yes. We file bugs in your tracker, work in your Slack and test on your staging or preview environments.

We can. Every engagement includes severity-rated bug reports, and if you’d like, our engineers can resolve critical and high-severity issues and then retest them.

Access to a staging or preview environment, test accounts for each user role, and a short list of your most important journeys. Read-only repository access helps but is optional.

Stop finding bugs in production

Tell us how you ship and where things keep breaking. A senior engineer will walk you through how we'd test it.

Innovation starts with a conversation.