Quality Assurance: Why "Test in Production" Costs You

A founder told me last year that his team didn't write tests because "we move too fast for that." Six months later, they shipped a pricing bug that undercharged customers by 40% for nine days before anyone noticed. The cleanup cost them $73,000 in refunds, retention apologies, and engineering time.

That's the bill for "moving fast." The team that moves fast and skips QA isn't actually moving fast — they're racking up debt that gets called in at the worst possible moment.

Quality assurance isn't a phase you bolt on at the end of the project. It's a discipline running through every commit, every PR, every deploy. The teams that take it seriously ship more features per quarter than the teams that don't. Not less. Here's why — and what the actual stack looks like in 2026.

"We'll Test In Production" Is The Most Expensive Phrase In Software

Every team that's said this has paid for it.

The math nobody likes to look at: a bug caught while a developer is writing the code costs roughly $1 to fix. The same bug caught in code review costs maybe $10. In QA testing — $100. In production with customers hitting it — anywhere from $1,000 to $10,000 once you count engineer hours, support load, refunds, reputation damage, and the related code you have to rebuild.

That's a 10,000x cost gap.

The "we move fast" teams I've worked with optimize for the cheapest column and pay in the most expensive one. Eighteen months in, they've spent more total engineering time on production firefighting than disciplined teams spent on tests in the first place. They just spread the cost out over so many incidents that no one noticed the pattern.

For the deeper "discipline saves money" angle using NASA's playbook: NASA's 10 Coding Rules — Space-Grade Standards That Save Business Software.

What Real QA Actually Covers

Most teams hear "QA" and picture a tester clicking around before launch. That's maybe 10% of the job. The other 90% is automated, continuous, and invisible when it works.

A real QA practice covers:

→ Automated tests on every commit. Unit tests for business logic, feature tests for the flows that matter, integration tests at boundaries. Run on every PR, block the merge if they fail.

→ Exploratory manual testing. A real human poking at the new feature, trying to break it, using realistic data and unrealistic patience. Catches what automation misses.

→ Cross-browser and cross-device checks. Safari iOS still does weird things. So does Chrome on Android. Edge cases live where browsers disagree.

→ Performance testing. Page load under load. Slow query detection. Database connection pool behaviour. The stuff that's fine for 10 users and breaks at 1,000.

→ Security testing. SQL injection. XSS. Authentication bypass. Exposed endpoints. The OWASP top issues that show up in 80% of breached apps.

→ Accessibility testing. Keyboard navigation. Screen reader compatibility. WCAG color contrast. Real users with real assistive tech, not just an automated audit.

→ Regression testing after every update. Did the new feature break something old? Automation should answer this in minutes, not weeks.

If your "QA process" is just the last bullet on a launch checklist — that's not QA. That's hope.

The 2026 Stack For Laravel + React Teams

I've tested a lot of QA stacks over the years. The one that consistently delivers — for small to mid-sized teams — looks like this.

Backend (Laravel):

composer require --dev pestphp/pest             # Modern test runner
composer require --dev nunomaduro/larastan      # Static analysis (Laravel-aware)
composer require --dev fakerphp/faker           # Realistic test data

Pest reads cleaner than PHPUnit for new code. Larastan catches type errors before tests even run. Faker generates test data that looks like real users, not "test1" placeholders.

Frontend (React + TypeScript):

npm install --save-dev vitest @testing-library/react   # Component + unit tests
npm install --save-dev @playwright/test                # End-to-end browser testing
npm install --save-dev eslint @typescript-eslint/eslint-plugin

Vitest is faster than Jest and Vite-native. Playwright handles real browser tests across Chrome, Firefox, Safari, mobile viewports — the cross-browser problem solved cleanly.

Security:

# Backend
composer require --dev enlightn/security-checker   # Known CVEs in dependencies

# Frontend
npm audit                                          # Dependency vulnerabilities
npx snyk test                                      # Deeper static security scan

The npm supply-chain attacks of recent years aren't hypothetical. Run these on every PR. We covered the scale of it here: npm Hack 2025 — Massive Supply Chain Attack Hits Billions of Downloads.

CI gate (GitHub Actions, simplified):

# .github/workflows/ci.yml
- run: composer install
- run: vendor/bin/pest --parallel
- run: vendor/bin/phpstan analyse
- run: composer security-checker
- run: npm ci
- run: npm test
- run: npm run typecheck
- run: npx playwright test
- run: npm audit --audit-level=high

That's the floor. Below this, you're shipping bugs you could have caught for free.

What To Test (And What To Skip)

Coverage percentage is the most overrated number in software. 90% coverage on the wrong code is worse than 50% on the right code.

The right things to test:

1. Business logic. Pricing rules, permissions, validations, calculations. The code that makes your app your app. Test these obsessively.
2. Critical user journeys. Signup, checkout, payment, the 4-6 flows that produce revenue. Break these and the business breaks.
3. Integration boundaries. API calls, queue jobs, third-party services. The seams where your code meets reality and reality is unreliable.
4. Anything that's broken before. Every bug fix gets a regression test. Once. So it never comes back.
5. Edge cases on form inputs. Names with apostrophes, addresses with non-Latin characters, prices with leading zeros. The stuff that breaks in production at the worst time.

The wrong things to test:

• Framework code (Laravel itself doesn't need your tests)
• Trivial getters and setters
• Internal helper functions used in one place
• UI animations and transitions

Test for value, not for coverage trophy. The first list catches 90% of real bugs. Chasing the rest is theatre.

Manual Testing Still Matters

Automation is great. Automation is not enough.

Three things manual testers catch that automation never will:

• "That's confusing." Copy that's technically correct but obvious nobody will read it. UX flows that work but feel wrong. The vibe of the product.
• Real device weirdness. That iPad in landscape with iOS 16 and a slow connection. The Android phone with the system font scaled up. Conditions you'd never script.
• Workflow gaps. "I expected to be able to undo this." "Why does the back button reset my filter?" Real-user expectations that no spec captured.

A senior team budgets one hour of manual exploratory testing per significant feature. Cheap. Effective. Catches the bugs that crash launches.

Security Testing Is Not Optional

Most apps I've audited have at least three of these problems sitting in production right now:

• SQL injection vulnerabilities through unparameterised queries
• XSS via rendered user input without escaping
• Broken authorization (users seeing data they shouldn't)
• API endpoints with no rate limiting
• Authentication tokens stored insecurely
• File upload endpoints accepting executable types
• CORS misconfigured to allow any origin
• Verbose error messages exposing stack traces in production

Each one is a breach waiting to happen. The fix is a $0 OWASP ZAP scan plus 30 minutes of code review per PR.

Skip this and you're a headline waiting to happen.

Accessibility: The QA Bucket Most Teams Forget

WCAG isn't optional in regulated markets, and it shouldn't be optional anywhere else either.

The minimum manual checks per release:

• Tab through every form. Every action keyboard-reachable?
• Run a screen reader (VoiceOver on Mac/iOS, TalkBack on Android) through one critical flow
• Use the contrast checker on text and interactive elements
• Resize text to 200%. Does anything break?
• Disable JavaScript. Does the core content still render?

I tell teams: the accessibility QA pass takes 20 minutes per release. The retrofit when you skip it for 18 months takes weeks.

What To Do This Week

Pick the matching action:

If you have no automated tests: install Pest (Laravel) or Vitest (React) today. Write one test for your most-broken endpoint or function. Then write one more next week. The trick is starting, not perfecting.

If you have tests but no CI gate: add a GitHub Actions workflow that fails the PR if tests fail. Two hours of work. Saves the next "merge that broke main" incident.

If you have CI but no security checks: add Snyk free tier and composer security-checker this sprint. Two more lines in the CI file. Catches dependency CVEs you didn't know existed.

If you have automation but no manual testing: budget one hour per major feature for exploratory testing before release. Either a teammate or an external QA contractor — both work.

The fastest way to feel ahead of the rest of your industry: take QA seriously when most teams pretend they will tomorrow. Tomorrow doesn't come on its own. Pick the one item from this list that hurts most, and fix it this week.

The cost of doing QA well is roughly 15-25% of dev time. The cost of skipping it is one or two production incidents per year that each eat 10x that. Run the numbers. Then write the first test.