Most testing companies tell you testing matters. Here is how we actually test the platform we sell, using the platform we sell, plus a few guard-rails we think every engineering team should steal. Everything below is verifiable in our codebase, and we will happily show you the tests running in a live demo.
Problem 1: marketing drifts from the product
Every product's landing page eventually claims a feature that was renamed, moved, or turned off. Our fix is a route-reachability drift test: an automated suite that walks every feature entry point shown in the app, including the global search index, and asserts two things. Every live feature has a mounted route, and every feature flagged "coming soon" has no route at all.
If a developer disables a feature but leaves it advertised, CI fails. When we recently rewrote our own homepage, this suite (11 assertions) is what proved the cleanup was complete.
Problem 2: pricing pages lie by accident
Our plans and quotas are enforced by an entitlements engine: plan × feature × limit, seeded into the database. It would be easy for the pricing page to say "$29" while the billing catalog said "$19". So the plan catalog is covered by a drift test asserting the TypeScript catalog, the database seed, and the price assertions all agree.
When we changed our prices, the change was not done until 136 subscription tests passed, including the assertions that pin every tier's price and feature list.
Problem 3: self-healing you can't trust
Our recorder's self-healing uses 15+ locator fallback strategies. But we don't let the machine silently rewrite tests. Every heal lands in a review queue where a human approves or rejects it. We run this on our own UI tests.
The honest lesson from dogfooding: auto-healing without review re-breaks trust the first time it "fixes" a selector to the wrong element. The queue is the feature.
What you can steal today
- Write one drift test that compares "what we advertise" to "what is mounted."
- Pin your pricing and entitlements in a test so business and code cannot diverge.
- Put a human approval step behind any auto-repair mechanism.
- Ratchet security baselines so that "known issues" can never grow silently.
How we measured this
- Test counts are the number of test cases in the named suite on the article date (2026-08-06), taken from the test runner output. The suites have grown since; the current count is whatever the runner prints today.
- The route-reachability and plan-catalog drift tests described here run in the frontend and backend suites on every change. The assertions are the tests themselves, not a summary of them.