Pre-Production Testing: Catch Bugs Before They Merge
Staging confirms your code runs. Pre-production testing confirms it works for users, on real devices, real flows, before the PR merges.
Your staging passed. Production broke.
A release goes green across every environment check. CI is clean. Staging looks right. You ship. Then production surfaces something: an auth flow that breaks on first login from a Samsung Galaxy on Android 13, a subscription edge case triggered only by users who signed up during a specific promo window, a German locale rendering that nobody caught because the test suite only runs against en-US.
The code didn’t change between staging and production. The environment did.
Most teams have no layer designed to catch this. Pre-production testing fills that gap. Validation that runs on every PR, before anything reaches main, at the point where fixing issues is still inexpensive.
What you’ll learn
- Why staging passing doesn’t mean production is safe
- Where pre-production testing fits alongside staging and monitoring
- The specific bug classes that only surface at the PR level
- How to add this layer without new infrastructure or maintenance overhead
What Is Pre-Production Testing?
Pre-production testing is validation that happens before code reaches production. At its best, it runs at the pull request level, catching issues while the fix is still cheap and the context is still fresh.
It doesn’t replace staging. Staging confirms the build runs in a controlled environment. Pre-production testing asks whether the product works. How well it answers that question depends on how closely your test conditions reflect real usage.
A bug caught before it merges costs an engineer an hour. The same bug in production costs incident response, support volume, a hotfix cycle, and sometimes a rollback.
How It Fits With What You Already Have
Staging and production monitoring already sit on either side of your release flow. Pre-production testing isn’t a replacement for either. It’s the layer that closes the gap between them.
| Layer | Staging | Pre-Production Testing | Production Monitoring |
|---|---|---|---|
| When it runs | Before deploy, controlled env | On every PR, before merge | After deploy, in production |
| Question it answers | Does the build work? | Does the product work? | Did something break for users? |
| Test environment | Synthetic, controlled | Pre-production build or artifact | Live production |
| When bugs surface | Pre-deploy | Pre-merge | Post-ship |
| Cost of a bug found here | Low | Low | High. Users already hit it. |
Staging was designed for environment-level validation. It answers “does the code run?” with confidence. What it can’t answer is whether the product works the way real users will encounter it. That’s not a flaw in staging. It was never designed for that question.
Production monitoring catches what makes it through. By the time an alert fires, real users have already hit the bug. Some churned. Some filed support tickets. The fastest incident response still means the code was live. Pre-production testing surfaces that same class of issue before the merge, at a point where a fix is one PR comment away.
Tired of Production Surprises?
See what pre-production testing finds on your app before the next merge.
Book a DemoWhy Pre-Production Testing Is the Layer Every Team Is Missing
The testing surface has expanded. The standard pipeline hasn’t kept up.
- More platforms. iOS, Android, web, hybrid. Every platform combination has its own device matrix, OS spread, and failure modes.
- More account states. Free tiers, trials, mid-cycle upgrades, regional pricing. Every unique state is a test case nobody scripted.
- More velocity. AI-assisted development is accelerating code output faster than teams can document what to test.
- More flakiness. According to the Quash 2026 State of QA Report, the share of teams experiencing test flakiness climbed from 10% in 2022 to 26% by mid-2025. More sprint time now goes to keeping tests from failing than to expanding what they cover.
Engineering orgs that added a pre-production layer didn’t build it because they had extra time. They built it because production kept surprising them. Auth breaks on first login from a specific device. Subscription logic that cracks under edge-case account states. Onboarding flows that pass every check and break on real hardware.
Every app has these bugs. The question is where you find them: before the merge, or after the ship.
What You Catch in Pre-Production
The bugs pre-production testing surfaces have a consistent profile. They cluster around conditions staging can’t reproduce.
-
Real-device behavior. Simulators don’t get all the way there. Touch timing, hardware-level rendering, memory constraints on older devices produce bugs that pass the emulator and fail on real hardware. No amount of simulator coverage catches these.
-
Auth flows under real conditions. Sign-in, token refresh, session expiry behave differently across device types, OS versions, and account states. The user who signs up on Android and first logs in on iOS triggers a different auth path than your test accounts follow. Staging catches the happy path. These edges stay invisible.
-
Subscription and payment edge cases. Users with trial accounts, mid-cycle upgrades, or region-specific payment methods produce behavior your default test accounts never reach. These states are invisible in staging and explosive in production.
-
Localization bugs. Most teams run tests against their primary locale. The bugs in German, Japanese, and right-to-left layouts sit untouched until a user in that region finds them. Pre-production agents surface these on every PR, not quarterly.
-
Onboarding on real hardware. Onboarding involves more state than almost any other flow: permissions requests, feature flags for new users, initial data setup, tutorial sequences. A change to an unrelated part of the app can silently break onboarding in ways nobody anticipated.
How Pie Automates Pre-Production Testing
The version teams actually adopt has to solve the overhead problem. Another test suite that requires authoring, maintenance, and debugging is a non-starter for teams already managing test debt.
-
Connect your repo. Pie connects to GitHub or GitLab. No new infrastructure to stand up, no environment to configure. Takes minutes.
-
Agents discover your flows. Vision-based agents explore your application the way a real user would. They navigate conditional UI, handle auth, and map what your app actually does. Output: test cases built from real user journeys, not scripts written in advance.
-
Every PR gets a gate. Relevant test cases run automatically on each pull request. Engineers see results inline: what passed, what failed, what’s new. No separate dashboard to monitor.
-
Tests adapt when your UI changes. Pie uses computer vision rather than DOM selectors. A button that moves or a form that gets redesigned doesn’t break coverage. Self-healing tests understand elements by how they look and what they do, not by fragile implementation details.
-
Target specific flows with plain language. Describe what you want tested: “the checkout flow for users with saved payment methods.” Agents run exactly that. No scripting required.
First discovery reaches the majority of your app’s flows before the first PR gate runs. The gate it produces understands your app the way users do, not the way a brittle script does, and it doesn’t break when someone renames a class.
Test Your Apps Before They Break
Your staging environment is useful. Keep it. But it’s a controlled set of conditions you chose in advance. Real users bring conditions you didn’t choose. Devices you didn’t test, account states you didn’t anticipate, locale configurations your suite never touched.
Pre-production testing is the layer that covers what staging can’t. It runs on every PR, before anything ships, ideally through an autonomous testing platform that adapts as your app changes. Once it’s in place, production stops being a source of surprises. Not because anyone got lucky, but because the discovery moment moved to before the merge.
Add the Pre-Production Gate
Connect your repo. First PR gate runs in hours. No scripts, no maintenance.
See It in ActionFrequently Asked Questions
Pre-production testing is a validation layer that runs automatically at the PR level, before code merges to main. It tests against real user flows, real device conditions, and edge cases that staging environments can't reproduce. The goal is catching expensive bugs before they're in production, not after.
Staging tests your code against a controlled, static environment. Pre-production testing tests your code against real-world conditions: actual device and OS combinations, real auth flows, subscription edge cases, and locale-specific behavior. Staging confirms the code runs. Pre-production testing confirms it works for users.
Production monitoring tells you something broke after real users hit it. Pre-production testing catches the same class of bugs before the merge, at a point where the fix costs hours rather than days of incident response, customer support load, and rollback coordination.
No. Pre-production testing isn't a new environment. It's a new gate on your existing pipeline. Pie connects to your repo and runs against your existing staging environment or build artifact on every PR. No new infrastructure.
Auth flows that break on first login from a specific device. Subscription edge cases triggered by specific account states. Localization bugs in non-default locales. Onboarding flows that behave differently on real hardware vs. the simulator. Exactly the class of bugs that staging misses and production surfaces.
Pie connects to your repo and completes an initial discovery of your application's flows. First PR gate is running within hours. No test scripts to write, no test plan to author, no maintenance cycle to set up.
Because Pie uses vision-based testing rather than selectors or XPaths, tests adapt when your UI changes. A button that moves, a screen that gets redesigned: agents understand elements by how they look and what they do, not by fragile implementation details.
No. Pie tests web apps, mobile apps (iOS and Android), and hybrid apps. The pre-production gate works across all of them, on every PR, automatically.
13 years building mobile infrastructure at Square, Facebook, and Instacart. Now building the QA platform he wished existed the whole time. LinkedIn →