Services · Launch-readiness review
Find the problems before your users do
Before your app reaches real users, we test it end to end for every user role, on desktop and mobile, in a staging environment. Each defect is written up so your team can act on it, and we fix and retest the ones you assign to us.
Request a launch-readiness reviewRead the sample report
- Starts with
- A written scope of what is in and out
- You get
- A test plan, a ticket per defect, fixes as pull requests, a retest
- Price
- Set by the written scope, agreed before work starts
Before you launch or ship a major release, we test every user role end to end, on desktop and phone, in your staging environment. That includes the accounts teams forget: signed-out visitors, invited users, people who were just demoted, and deactivated accounts. For each action a role must not take, we send the request straight to the server and check that it refuses. Every defect is written up with steps to reproduce, the expected and actual result, and a severity agreed before testing starts. We fix the defects you assign as pull requests your team reviews, and we retest every fix against its original finding. Thomas scopes the review and signs off every finding, and the testing is AI-assisted. See the format first in our sample report, a demonstration on an app we built with invented data.
Is this a fit?
Who it is for
Startups and small software teams preparing to launch a product, or to open it up to many more users.
Problems it solves
- A product tested so far only by the people who built it.
- A permission mistake that would show one role another role’s data.
- Bugs that keep being found by users rather than in testing.
How to request it
- Open the request form; this service is already selected.
- Say what the product does, which user roles it has, which devices matter, and when you plan to launch.
- Thomas replies by email. After a short call or a few written questions, you get a written scope and price before any work starts.
Free checklist. Pre-launch QA checklist: the checks we run, written so your team can run them on its own product before launch. No email needed.
Proof from our own demonstration
Numbers from a demonstration on an application we built with invented data. It is labelled as a demonstration, not client work, and the defects planted on purpose are disclosed.
- 75 of 75automated checks passing after the review, up from 48 of 75
- 8 of 8logged defects fixed and verified by retest
- 3 rolestested end to end, on desktop and at phone width
Situations this fits
A review before launch fits when software is about to reach real users and nobody independent has tested it the way they will use it. Situations like these:
- A product close to launch, tested so far only by the people who built it.
- A product where each role, for example admin, staff and customer, sees different data, and a permission mistake would show the wrong data to the wrong person.
- A major release to a product people already depend on.
- Bugs that keep being found by users rather than in testing.
What the review covers
- A test plan built around each user role and what that role needs to do.
- End-to-end testing for every role, on desktop and mobile, in your staging environment.
- A defect report for each problem: steps to reproduce, expected and actual result, and severity, filed as a ticket in your tracker.
- Fixes for the defects you assign, each as a reviewed pull request.
- A retest of every fix before launch.
How findings are rated
Each finding is rated on the same four levels, the ones used in the sample report below:
- Critical: a user can do something or see data their role does not allow, records can be lost or corrupted, or a core task is blocked for everyone with no workaround. Should be fixed before release.
- High: a control the business relies on, such as the audit trail, is wrong or missing, or a core task fails for a whole role with no reasonable workaround. Fix before release unless you accept the risk in writing.
- Medium: a feature works incorrectly or cannot be used for some users, devices or inputs and a workaround exists; an accessibility failure stops some users without help; or bad data can be saved. Fix before or soon after release; you decide.
- Low: cosmetic issues, console noise or confusing messages with no effect on data, permissions or task completion. Schedule normally.
The rating says how serious a finding is. The decision to launch stays with you.
What you receive
- A test plan built around the people who will use the product.
- A ticket for each defect in your tracker, with steps to reproduce, expected and actual result, and severity.
- Fixes as pull requests for the defects you assign, reviewed by your team before they’re merged.
- A retest of every fix, recorded against the original ticket.
- A list of open defects at launch time, so the launch decision is made with everything known in front of you.
What this does not include
So the scope is clear from the start:
- A penetration test, security certification or compliance audit. A launch-readiness review checks that the product works as intended for each role; it is not a certified security assessment.
- A guarantee that the software is free of defects. Testing covers the agreed scope.
- Testing in production. Testing happens in staging, and production access only if you grant it in writing.
- Fixes for defects nobody has assigned to us. You decide which ones we fix.
How the work runs
- Scope. We agree in writing which roles, devices and features are in, which are out, and how findings will be rated.
- Test. We exercise the product end to end for every role, on desktop and mobile, in staging.
- Report. Each defect goes into your tracker, rated on the levels above.
- Fix. We fix the defects you assign, each as a reviewed pull request.
- Retest. Every fix is retested before launch.
How we work with your team
The same rules apply to every engagement:
- Staging only. We work in a staging environment. We have no production access unless you grant it in writing.
- Every change is a pull request. Your team reviews it before it’s merged.
- Tickets in your tracker. Findings and fixes live where your team already works.
- A weekly written progress note: what’s done, what’s next, and anything blocked.
- AI tools only on accounts that don’t train on your data. Credentials and bulk data never go into AI tools.
Related services
If your product books time or syncs calendars, a Calendar and scheduling audit looks at that part in more depth. If it uses AI to create records or draft messages, see AI data and output review.
Ownership and handover
- Your copy. The test plan, tickets and retest results are yours; their use is set out in the signed agreement.
- Terms in writing. Access to your staging environment and test accounts, and how test data is handled, are set out in the signed agreement.
What moves the cost
There is no fixed price list, because cost follows scope. These are the things that usually make a review larger or smaller:
- How many roles and permission levels need testing.
- How many devices and browsers are in scope.
- How many features and user journeys the release changes.
- Whether a staging environment and test data are ready, or need setting up.
- How many defects you want us to fix, and how many rounds of retest the release needs.
Who’s accountable
Thomas Wagenberg, founder. He scopes and leads every engagement and signs off every finding. Testing and fixes use AI-assisted engineering under his direction, and every change reaches you as a pull request your team reviews.
Wagenberg Technology Group serves startups and small software teams remotely across the United States, with a focus on Cleveland and Fort Lauderdale.
Where and how we work
We work remotely with teams across the United States, including teams in Cleveland and Fort Lauderdale. Pricing depends on the scope of the project, which we agree in writing before work starts.
For teams in Cleveland and Northeast Ohio: software audits and launch-readiness reviews for Cleveland and Northeast Ohio.
From the articles
- How to test every user role before you launch
A written role matrix, server-side checks, two accounts per role, and desktop and phone passes.
Tell us what you’re launching
Describe the product and what worries you about it. Thomas will reply by email.
In your request, say what the product does, which user roles it has, which devices matter, and when you plan to launch.