When to test
Six situations where it pays to find the limit early.
Every one of these situations has one thing in common. Someone assumes the system will hold up and bases a campaign, a contract, or a funding decision on that assumption. A test turns the assumption into a number before the real traffic arrives.
You're going live
The date's been announced and the team is wrapping up deployment. Before you let real users in, we find out how much the system can take.
Marketing is preparing a campaign
The promotion is meant to bring in more traffic than usual. We find out whether pages still load within an acceptable time at that volume and whether orders go all the way through.
You're negotiating with a major client
The contract includes an availability guarantee (SLA). At the negotiating table, you show test results, not assurances.
You're growing faster than planned
New scale, new infrastructure. We put it under load before you move production traffic onto it.
You're acquiring a startup
You're paying for the product and its technology together. A test shows how much that technology can really take. You know the weak spots before you sign.
A fund before the next tranche
The company's forecasts assume traffic growth. A test shows the fund whether the technology can handle that growth. Hard data instead of the team's word.
Don't see your situation here? Tell us about it, and we'll assess whether a test makes sense for you.
Questions and concerns
It helps to know the answers to these questions before you decide.
Is it safe for our system?
We work in the test environment you point us to. Before we run anything, you read and approve the scenario: which actions we run, with how much traffic, and in what time window. Traffic builds gradually, and we can stop the test at any time.
What if we don't have API documentation?
Missing documentation doesn't stop the project. We reconstruct user journeys from a recording of browser traffic or from a conversation with someone who knows the system. We decide which one together on the first call.
Do we have to install anything?
We install nothing on your system. Traffic goes from our infrastructure to the environment you point us to. All you need to do is add our IP addresses to your allowlist. If we give you helper tools, for example to prepare the environment, you run them yourself and see exactly what they do.
How long does it take?
It depends on three things: how big the system is, how much material you have on it, and when there's a free window for the test. We write the scenario once we have your API documentation or a traffic recording. We run the test in the agreed window and repeat it after every fix until the system reaches the goal you set. You get a specific date on the first call.
Will test traffic hurt our real users?
The test runs against a test environment, at an agreed time, away from production. Your users never see it. If the environment shares resources with production, or you choose to test in production, we say so up front and pick a window and traffic profile so that nobody notices.
What do we get after the test?
A prioritized diagnosis: which part fails first and where to start fixing. After your fix, we run the same test again and compare the results before and after.
What if we can't fix the bug?
You're not left on your own. The diagnosis says what to fix. If needed, we sit down with your team and help get the fix in.
What about CAPTCHA, 2FA, and email verification?
In the test environment, you turn them off for test accounts or set a fixed code. We give you an exact list of what to change and where, plus helper tools you run yourself.
What about payments, emails, and external APIs during the test?
They never reach the real providers. Under heavy traffic, we stub those connections out: the stub responds like the provider but sends nothing and costs nothing. The providers' sandboxes couldn't handle that kind of traffic. We agree on the list of integrations when we write the scenario.
Couldn't we do this ourselves with a free tool?
You could. The tool is the easy part. The time goes into the scenario, test data, environment setup, and interpreting the results, and that means weeks of your team's time away from the work you pay them for. We do this every day.
What if we don't have enough time for a load test?
We've worked under deadline pressure before. Tell us your deadline, and we'll tell you what we can get done before it.
Got other questions? We're happy to answer them in a call about your system.
Facing a performance problem? Tell us what you're up against.
You'll know whether you're ready for a load test.
30 minutes · online · free