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?
Top comments (0)