For teams with a launch, a sale or a migration coming, and no load numbers they trust

Performance testing services

Performance testing tells you what your system does when a lot of people use it at once: where it slows down, where it breaks, and whether it comes back afterwards. Most teams find out on the day that matters. We would rather you found out a few weeks before.

We are an independent testing company. We have tested other people's software since 2018, we did not write yours, and we have no reason to round a bad number up. 50+ engineers, in Cluj-Napoca, Romania.

Two weeks, complimentary if you are not happy with what we deliver. We invoice from week three.

2 weeksComplimentary if you are not happy
€20-45Per hour
4.9Clutch, 70 reviews
4ISO certificates
BetterQA engineers at a shared office table with laptops open, one colleague typing
// 01

Who this is for

  • You have a date you cannot move. A launch, a campaign, a seasonal peak, a migration to new infrastructure. You need to know before it arrives whether the system holds, and what to fix if it does not.
  • Your system is slow and nobody can say why. Users complain, dashboards show averages that look fine, and the team has stopped guessing.
  • Someone is asking for evidence. A customer, a procurement team or your own board wants to know what load the product was tested at, and "it has been fine so far" is not an answer they accept.
  • You need a performance engineer for a few weeks, not forever. Hiring one full time for work you need twice a year makes no sense. A specialist can join your account for a fortnight without us recruiting for it.

If none of those sounds like you, the functional testing or test automation pages are probably a better place to start.

// 02

What we test, and how

We start from how your system is really used, not from a round number. Your analytics, your logs and the journeys that earn money tell us what a normal hour looks like and what a bad one looks like. The test is built from that, so the result means something when we hand it back.

Then we run the kind of test the question needs:

  • Load testing. Expected traffic, sustained. Does the system meet its response-time targets at the load you actually plan for?
  • Stress testing. Past that point, until something gives. Where does it break, how does it fail, and does it recover cleanly or need a person to restart it?
  • Spike testing. A sudden jump, the way a campaign email or a sale opening produces one. Does scaling react in time, or does the queue fall over first?
  • Endurance testing. Normal load held for hours. This is where memory leaks, connection pools that never give connections back, and caches that slowly fill show up.
  • Scalability testing. What happens when you add capacity. Whether more servers buy you more throughput, or just a bigger bill.

And the question nobody asks until launch week: how does the app behave on a bad mobile connection in a lift.

We report percentiles, not averages. An average response time can look healthy while one user in twenty waits ten times longer, and that user is the one who writes the review. So you get p50, p95 and p99 latency, throughput, error rates, and what the servers, database and connection pools were doing at each point. Load generation is mostly JMeter.

For the wider picture of building systems that hold up under load, see our article on performance engineering: optimizing software for scale.

// 03

What you get at the end

Numbers are only half of it. The other half is why.

  • The limits, stated plainly. The load at which each important journey stops meeting its target, and what fails first.
  • The cause, where we can find it. A slow query, a missing index, a pool sized for a tenth of the traffic, a synchronous call that should not be. Found by reading the traces and the resource data, not by guessing from the outside.
  • What to fix first. Ranked by what it costs you, so your developers spend the first week on the thing that matters.
  • A test you can run again. The scripts and load profiles stay with you, so after the fix the same test can be re-run to see whether the number moved. Where it makes sense, we wire a smaller version into your pipeline so a slow release gets caught before it ships.

Retests are billed at the same hourly rate as any other testing time.

When an engagement ends, you keep the scripts, the documentation and the tooling configuration.

// 04

What it costs

€20-45per hour

€20 to €45 an hour.

The rate moves with three things: the seniority of the engineer, how long you commit for, and the mix of manual, automation and specialist work. Performance work sits in the specialist part of that mix. Longer commitments move down the range.

It does not move with whether we can find somebody cheaper. Every engineer put on your product has shipped commercial releases before, and we would rather lose to a lower bid than put somebody new to load testing on your launch.

We start the same way on every engagement. Two weeks, complimentary if you are not happy with what we deliver. We invoice from week three. We work on your system, you read what we found, and you decide whether to carry on.

// 05

Why us

We are independent. We test software we did not write. A supplier that built your system has a reason to call its limits acceptable. We do not.

We have done this on products people use. Collaboard, the Swiss real-time whiteboard, is one: we tested performance under concurrent load, alongside WebSocket and cross-browser work. We have also done performance work for Avilabs, an ecommerce platform in Florida. Collaboard's COO, Michael Gorog, said of us: "They have a holistic testing approach and are good at finding bugs."

Four ISO certificates, all current: ISO 9001:2015, ISO/IEC 27001:2022, ISO 13485:2016 and ISO 14001:2015. 27001 covers how we handle your data, credentials and test environments, which matters when a load test needs production-like data. We send the certificates with their scope statement.

A NATO procurement agreement. The NATO NCIA Basic Ordering Agreement, NCAGE 1JGAL. It is a signed ordering agreement.

4.9 on Clutch, from 70 reviews. Written by clients, not by us.

// 06

Common questions

Do you need access to production?

Usually not. We recommend a staging environment that matches production closely enough for the numbers to mean something. Where it does not, we agree with you what can safely run against production and when.

How is load testing different from stress testing?

Load testing checks the system at the traffic you expect. Stress testing pushes past that to find where it breaks and how it recovers. Most engagements need both.

How long does it take?

About two weeks to have an engineer working on your system. How long the testing runs depends on how many journeys matter and how often you want to re-test after fixes. We scope it with you on the first call.

Can you work with our developers and our monitoring?

Yes. We work inside your tooling and your VPN where you want us to, and the results are only useful if your team can read them in the tools they already use.

Can we keep running the tests ourselves?

Yes. The scripts are yours.

How do you handle our data?

NDAs, and the handling is covered by our ISO 27001 management system. For a regulated product, ask for the scope statement rather than the certificate.

Talk to us

Tell us what is coming up, what the system runs on, and what worries you about it. We will tell you what we would test and how long it would take, and if the answer is that you do not need a load test yet, we will tell you that instead.