Why I ran load tests before having users

When you’re building a dev tool, performance issues tend to show up at the worst possible time:

right when users finally arrive.

I’m currently building Ekit, a dev-first data engine / CMS, still in an early stage. I don’t have massive traffic yet — and honestly, I don’t need it. Even 100–500 real users would already be a win.

Still, I decided to run load tests before traction. Here’s why — and what I learned.

Why test before users?

Most projects I’ve worked on (including my own in the past) followed this pattern:

• Build features


• Get users


• Feel the app slow down


• Panic


• Try to fix performance under pressure

After 20+ years of development, I’ve learned that latency is much harder to fix once it’s already bad.

So this time, I wanted answers early:

• Is the architecture sane?


• Are there obvious bottlenecks?


• Can I onboard early users without stress?

Test setup (kept intentionally simple)

I used k6 to run basic load tests against the API and SSR endpoints.

Nothing fancy:

• realistic request patterns


• no artificial spikes


• focus on p95 latency, not just averages

The goal wasn’t to simulate massive scale, but to validate fundamentals.

Results

The most reassuring metric was the p95 latency ≤ 40 ms.

That doesn’t mean the system is “ready for millions of users”.

It simply means:

• requests are fast


• the stack isn’t fighting itself


• there’s no obvious performance debt yet

For an early-stage dev tool, that peace of mind is huge.

What this changed for me

Running these tests early had a very concrete impact:

• I stopped worrying about infra during onboarding


• I could focus on product feedback instead of “will this hold?”


• I now know where the limits might be — before hitting them

Performance didn’t become a bragging point.

It became a non-issue, which is exactly what you want.

What I didn’t test (yet)

To be clear:

• I don’t have real production volumetry yet


• I haven’t tested extreme concurrency


• this isn’t a benchmark against other tools

And that’s fine.

Load testing early isn’t about proving excellence —

it’s about reducing uncertainty.

Final thought

If I had to summarize the lesson:

It’s much easier to scale capacity later than to fix latency you ignored early.

I’m curious:

At what stage do you usually start load testing your projects — before users, or after?