DEV Community: Fabrice Grenouillet

I stopped managing translations manually (and built this instead)

Fabrice Grenouillet — Sat, 04 Apr 2026 06:24:30 +0000

Managing multilingual content has always felt… wrong to me.

In most projects, it quickly turns into:

duplicated fields (title_en, title_fr)
messy i18n JSON files
constant synchronization issues

At some point, I started wondering:
why is this even a developer problem?

Rethinking the approach

Instead of treating translations as something external (keys, files, etc.), I tried a different approach:

What if multilingual support was part of the data model itself?

So I built a small Airtable-like system where fields are multilingual by design.

You write content once, and it becomes available in multiple languages automatically.

Example:
Title: "Hello world"
→ fr: Bonjour le monde
→ es: Hola mundo

No keys. No duplication. No sync issues.

How it works

Each field stores multiple language versions internally.

On top of that:

automatic translation (using GPT)
ability to override manually per language

Where it can be used

The system can be accessed:

via API
or directly inside a templating engine I’m building (Ekit Studio)

So content flows directly into rendering without extra i18n layers.

Why this feels better

This approach shifts the problem:

from code → to data
from developers → to content structure

And in practice, it removes a lot of friction.

Curious to hear from others

I’m building a project-based content & templating tool — looking for beta testers

Fabrice Grenouillet — Wed, 04 Feb 2026 08:30:39 +0000

Hi 👋

I’m a solo developer working on Ekit Studio, a developer-focused tool I built after years of rebuilding similar backoffice stacks for different projects.

Why I’m building it

Across many web projects, I kept facing the same issues:

structured content getting messy once multilingual is involved
fragile template pipelines
a lot of glue code between data, APIs, and rendering

I eventually decided to standardize a single internal architecture and turn it into a standalone tool.

What Ekit does (current beta)

Project-based structured data (tables, records, fields)
Multilingual content as a first-class feature
Server-side rendering with custom templates
Public API per project

It’s still an early beta: the core is solid, but I’m actively refining UX and workflows.

What I’m looking for

I’m looking for a few developers/makers willing to:

try it on a real or side project
give honest feedback on onboarding and usability
tell me what feels unclear, overkill, or missing

What you get

Free beta access
Direct feedback loop with the creator
Real influence on the roadmap

👉 Beta available here: https://ekit.app

If you have questions, feedback, or want more technical details, I’ll be happy to discuss in the comments.
Thanks for reading 🙏

Filtering 13M Records at 2ms: Where to Draw the Line Between UX and Performance?

Fabrice Grenouillet — Fri, 30 Jan 2026 04:18:22 +0000

Filtering 13M Records at 2ms: Where to Draw the Line Between UX and Performance?

I’m currently building Ekit Studio, a data-driven SaaS where users can manage dynamic schemas.

Naturally, I looked at tools like Airtable or Notion for inspiration.

From a UX perspective, the dream is simple:

“I should be able to filter and sort on any field, instantly.”

But when you're hitting 13 million records on a MongoDB collection, “instantly” becomes a real engineering constraint.

1. Context: A Scoped Architecture

To keep things fast, the data is multi-tenant and always scoped.

Total records: ~13M
Per scope: ~4.4M (filtered by project + proto + lang)
Stack: Node.js + MongoDB (running on a beefy Xeon)

To guarantee performance, I designed a slot-based indexing system, mapping user-defined fields to a fixed set of indexed slots:

4 string slots (s1, s2, s3, s4)
1 number slot (n1)
1 date slot (d1)

Only those slots are guaranteed to be filterable and sortable at scale.

2. The Surprising Benchmarks

During stress tests, I noticed a clear divide in how MongoDB behaves with unindexed queries.

Small datasets (< 10k rows)

Everything is basically “open bar”.

Multi-field filtering
Unindexed sorting
~10 ms max

At this scale, you don’t need a strategy — you just need a database.

Large datasets (~13M total / ~4.4M scoped)

When queries are scoped using the main composite index (project + proto + lang), results look like this:

Pagination only (no filter, no sort): ~1.2 ms
Unindexed “contains” filter (scoped): ~2.2 ms
Pagination + contains filter: ~2.0 ms

Takeaway:

Unindexed filters, when scoped properly, stay acceptable much longer than I expected.

The wall: unindexed sorting.

As soon as you try to sort millions of rows without an index, MongoDB hits its in-memory sort limits and performance collapses.

3. The Strategy: “Performance Mode”

Rather than punishing small users for the needs of large datasets, I’m leaning toward an adaptive UX.

Below 10k rows

→ open filtering and sorting on all fields (Airtable-like UX)
Above 10k rows

→ automatically enable Performance Mode

→ only indexed slots are available for filtering and sorting

Even in the “open” mode, there are guardrails:

hard query timeouts (maxTimeMS)
no deep offset pagination
no unbounded sorts

4. Lessons Learned

Sorting breaks before filtering.
Prefixes are king. Always scope your queries.
UX vs engineering: a restricted UX that actually works is better than a “free” one that freezes.

I’d love to hear from you

For those who’ve built similar systems:

Where did you draw the line? 10k? 100k?
Did you allow unindexed sorting early on?
Have you tried on-demand or adaptive indexing?

I’m especially interested in real-world war stories.

Let’s discuss 👇

Why I ran load tests before having users

Fabrice Grenouillet — Sat, 24 Jan 2026 13:56:23 +0000

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?

A dev-first approach to managing multilingual content without rebuilding backends

Fabrice Grenouillet — Fri, 23 Jan 2026 06:58:59 +0000

I kept rebuilding backends for small multilingual websites, so I built a tool to stop doing that.

I just recorded a few short demos showing:

structured multilingual content
API access
SSR preview and deployment

I’d really appreciate feedback from other developers who’ve faced similar problems.

Link