Concurrent-user degradation testing for cloud-deployed web applications

The moment that triggers the search for something like this is when a team gets a support ticket saying the app 'sometimes does not support all features' when many people use it at once, and they have no idea at what user count things start breaking — not crashing, just silently degrading. Load testing tools exist, but they measure throughput and latency. What these complaints describe is different: features stop working, GUIs stop loading, index pickup fails mid-operation. That's behavioral degradation, not just slowness.

The reason this gap hasn't been filled well is structural: traditional load testing is bought by QA teams who care about p99 latency, but the complaints here come from end users who notice that a specific workflow (fetching a big dataset, running a simulation, loading progress state) breaks under concurrent use while other things still work. No QA tool is designed to map feature availability against concurrent user count — they map response time against request rate, which is a different question.

What's actually needed is a test harness that runs realistic user journeys (not just HTTP requests) across a parameterized user count, and reports which specific UI states or operations fail first and at what threshold — so a team can say 'phpMyAdmin large table operations degrade at 15 concurrent users' rather than 'it gets slow sometimes.'

This is a recurring business problem because every new deployment, every infrastructure resize, and every significant traffic event (a product launch, a batch job running in parallel) forces the same question again. The cost of not having the answer is either over-provisioning 'just in case' or a production degradation that affects real users.

What to build

Build a test runner that takes a set of Playwright or Selenium user journey scripts, executes them at stepped concurrency levels against a target environment, and produces a feature-availability degradation curve — showing which operations start failing (not just slowing down) and at what concurrent user threshold.

Where to start

Target teams already using Playwright for end-to-end testing who have had at least one production incident where a feature silently broke under load — they already have the scripts, so onboarding cost is near zero and the first report is demonstrably better than what they had.

The hard part

Most buyers already have a load testing tool and will frame this as 'we could just add assertions to our existing tests' — the hard sell is convincing them that behavioral degradation under concurrency is a categorically different problem from latency, which requires seeing a real failure their current tooling missed.

How it makes money

Monthly subscription per project with tiered pricing based on number of concurrent test runs, with a free tier capped at 10 concurrent virtual users to drive adoption among individual engineers before a team purchase.