Ekit Studio
A dev-first CMS for multilingual data
I’ve been improving Ekit and recorded a quick demo today.
I start from AI-generated HTML, paste it into a template, connect a custom domain, save, and open the live website with HTTPS.
The demo takes about 1 minute.
For the sake of time, the CNAME was already configured before recording.
Curious what you think:
is this actually compelling, and who do you think would want this most?
I’m building an early-stage content-first SSR CMS for developers.
This week, I shipped a first version of collaborative editing — earlier than I originally planned.
A few early users started working on content together and quickly hit the limits of a single-editor workflow. That pushed me to tackle collaboration sooner, even though the product is still very young.
What turned out to be harder than expected:
keeping server-side rendering predictable while multiple users edit at the same time
handling conflicts without over-engineering
making sure previews stay consistent and debuggable
deciding what not to solve yet
The current version is intentionally simple:
basic real-time collaboration
no fancy presence features
no attempt to solve every edge case
But it already removes a lot of friction for small teams working on content-heavy projects.
This reminded me how different collaboration feels when your system is content-first and SSR-driven, compared to traditional client-side editors.
I’m curious:
How early did you add collaboration to your product?
What did you intentionally not build in the first version?
If anyone is interested, the project is here: https://ekit.app
Happy to get feedback or learn from similar experiences.
Hey IH 👋
I’m currently building Ekit, a developer-focused content-first SSR engine.
As part of the project, I just launched a small blog called “Inside Ekit”, where I share:
- architectural decisions,
- technical trade-offs,
- and lessons learned while building the product (MongoDB scaling, CMS trade-offs, SSR choices, etc.).
This is not meant to be marketing content or tutorials.
It’s closer to public engineering / product notes.
👉 Blog: https://ekit.app/en/blog
Before investing more time into writing regularly, I’d love honest feedback from this community:
- As a builder, do you find this kind of content useful?
- Would it help you trust or evaluate a developer tool?
- Or is this the kind of blog you personally skip?
I’m genuinely trying to figure out whether this brings real value, or if it’s just noise.
Thanks in advance — blunt feedback welcome 🙂
Hey Indie Hackers 👋
I’m a solo developer and I’ve been working on Ekit, a project-based tool I built after years of rebuilding similar backoffice stacks for different web projects.
After the initial launch a few weeks ago, I’m now in a phase where I really want honest, hands-on feedback from other builders.
What Ekit is (current beta)
Project-based structured data (tables, records, fields)
Multilingual content as a first-class concern
Server-side rendering with custom templates
Public API per project
It’s still early, but usable for real projects.
What I’m looking for
I’m looking for a few developers/makers willing to:
try it on a side project or real use case
stress-test the workflows
give blunt feedback on what’s confusing, over-engineered, or missing
What you get
Free beta access
Direct feedback loop with me
Real influence on what gets improved next
Here’s the beta if you want to try it:
👉 https://ekit.app
Happy to answer questions or go deeper on the technical side in the comments.
Thanks 🙏
I’m building a data-driven SaaS inspired by tools like Airtable.
I’m currently dealing with ~13M records (MongoDB documents) in production, and it forced me to be very explicit about the trade-off between UX expectations and backend reality.
From a UX point of view, users expect to be able to filter and sort on any field, instantly.
From a backend point of view, that assumption breaks pretty fast once data grows.
Here’s what I’m seeing in practice (MongoDB backend):
Small datasets (<10k records):
Filtering + sorting on unindexed fields is basically free (single-digit ms).
Large datasets (millions, up to 13M+ records):
Unindexed filtering can still be acceptable if queries are properly scoped,
but unindexed sorting is where everything collapses.
So I’m leaning toward a very pragmatic rule:
Below ~10k records → open filtering & sorting on all fields (Airtable-like UX)
Above ~10k records → “performance mode”: only indexed fields are filterable/sortable
The goal is to avoid punishing small users, while being honest about what actually scales.
For those of you who’ve built similar products:
Where did you draw the line?
Did you allow unindexed sorting early on?
Any regrets or hard lessons learned as data grew?
Curious to hear real-world experiences.
-
2
Every “Airtable-like” product has this tradeoff in one way or another. ~
What worked for us was drawing the line not by record count alone, but by the visibility of query cost. At first, we allowed a lot, but slowly started introducing friction instead of hard walls.
Some designs that assisted.
It was allowed for unindexed fields for longer than sorting, so you hit this conclusion. A sort is a silent killer.
Instead of merely disabling the field, we explained why it was slow with a message like “this field isn’t indexed yet.” That only dropped complaints.
Due to the cost of using a field, power users self-selected desirable fields for indexing.
The most annoying regret: waiting too long to design the “index as a product”. When the data is large it is hard to retrofit that UX.
It seems reasonable to frame it as "performance mode." as long as that’s the graduation not the restriction.
Inquiring as to whether you’ve utilized soft warnings or delayed execution (“this may take ~X seconds”) before locking down fields? We discovered that shifted behavior without feeling punitive.
-
1
This aligns very closely with how I’m thinking about it.
The UX patterns you describe (soft warnings, cost visibility, delayed execution) are definitely planned.
Right now, before calling this a true v1, my priority is making sure the system holds up under load.I’m intentionally spending time on the fundamentals first — DB-level optimizations, query patterns, indexing strategy, and making sure the core model scales predictably.
Once that foundation is solid, adding UX layers that guide users without feeling punitive becomes much easier (and safer).
I’d much rather ship a slightly stricter product that’s honest about its limits than mask performance issues with UI tricks too early.
Thanks for sharing your experience — the “indexing as a product” point is especially helpful.
-
A developer tested my form builder yesterday and pointed out something obvious in hindsight:
data types made sense to me, but not immediately to someone new.
I added short descriptions under each option to explain what they actually represent.
It’s impressive how a single line of text can remove friction and improve understanding instantly.
Another reminder that UX isn’t about adding more — it’s about making things clearer.
Ran some k6 load tests on Ekit yesterday — p95 ≤ 40ms.
Not chasing massive scale early, just validating fundamentals first.
When do you usually start load testing your products?
I just recorded 3 short demos for Ekit (translation, API usage, SSR output).
I’m a dev, not a video editor, so I kept them under 2 minutes each 🙂
When you look at a new dev tool, what do you usually want to see first?
• the UI
• the API request/response
• or the final rendered output
Curious what actually helps you decide if a tool is worth trying.
-
2
For me, it’s the final output first.
If the result looks right, I’ll then check the API and docs to see how painful it is to get there.UI matters less for dev tools — clarity of input → output matters most.
-
1
I 100% agree. If the final result isn't perfect, the best API in the world won't save it.
That's why I recorded those demos—to show exactly what the multi-language output looks like.
If you have a second to check the 'Final Output' video, I’d love to know if that’s the kind of result you’d expect for your own projects!
-
-
1
Thanks to Carbanak Group for saving my life. I got my PROGRAMMED ATM CARD to withdraw the maximum of $5,000 daily for a maximum of 30 days via . I’m glad I got $150,000 to pay my bills and buy bitcoins.
They can also help you recover all stolen cryptocurrencies and funds from scammers. Contact now for a financial solution.
hatsApp: +1 (639) 526-2440 -
1
I look at whether it clearly addresses a real problem, fits naturally into existing workflows, and delivers practical value. If the solution isn’t effective or doesn’t genuinely improve productivity, features and polish don’t matter much, because a getthespikeapk tool is only as good as the problem it solves.
-
1
Totally agree — solving a real, recurring problem matters far more than polish.
Ekit comes directly from years of hitting the same practical issues in real projects and trying to fit solutions naturally into existing workflows. The demos are just a way to make that concrete.
-
-
1
Nice approach keeping the demos short that already respects dev time 👍
For me, it’s usually API request/response first, then a quick look at the final output to see if it does what I expect. UI matters too, but mostly after I know the core works.Also, once you’re ready to get it in front of more devs, places like Reddit can work really well for quick feedback and early adopters. Happy to chat if you want to compare notes.
-
1
Thanks, really appreciate the thoughtful feedback 🙂
API first, then output makes a lot of sense — that’s exactly why I kept the demos short and focused on the core.
Reddit is a good call too, although my karma is still pretty low since I haven’t been very active on social platforms. I’m learning to use it more intentionally for early feedback rather than promotion.Happy to compare notes sometime.
-
1
That’s a smart way to approach it. Using Reddit intentionally for feedback (not promotion) is what keeps accounts healthy and makes the signal way cleaner. Low karma is fixable once you know where and how to engage first.
Happy to swap notes on that anytime @preshtechsolution on Telegram if useful.
-
-
-
1
Early feedback is crucial for product development. A prototype or landing page can help validate ideas before full development.
-
1
Totally agree — early feedback matters a lot. That’s why I started with a landing page, specs and a few short demos.
Ekit is the result of ~25 years of repeatedly hitting the same problems and rebuilding similar tooling.
Curious what usually helps you most to decide if a dev tool is worth trying?
-
1
What usually makes me try a dev tool is a mix of “time-to-value” and proof that it’ll fit my workflow.
Clear, specific use case: I can tell in 10 seconds what problem it solves (and for whom).
Fast setup: runnable in minutes (Docker/one-liner install, sensible defaults, no account maze).
Small demo that matches reality: a short video or sample repo showing a real workflow, not just a polished UI.
Integration story: works with what I already use (CLI, Git, CI, IDE/editor, Slack/Jira, etc.), and has an easy exit (export/standard formats).
Trust signals: transparent pricing, straightforward docs, and enough details to judge maintenance (changelog, roadmap, responsiveness).
Measurable win: it saves time, reduces bugs, or removes a repeated annoyance I already feel weekly.
-
1
This is a really solid breakdown, thanks for taking the time to write it.
Time-to-value and workflow fit are exactly the kind of things that pushed me to build Ekit in the first place — most of it comes from repeatedly hitting those same frictions in real projects.
The points about demos matching reality and having an easy exit resonate especially hard. Those are things I’ve personally been burned by before, so I’m trying to be very intentional about them this time.
-
-
-
1
This comment was deleted 7 months ago
Update on Ekit
Custom domains are now live.
With this milestone, Ekit now covers the full website creation pipeline:
Multilingual structured data (CMS-style, Airtable-like)
Custom templating with live SSR preview
Built-in editor with Ekit-specific IntelliSense
Deployment-ready output with custom domains
Public read-only API, making Ekit usable as a headless CMS as well
The idea behind Ekit is to give developers a single tool to:
design data, build templates, preview content, and ship to production — without gluing together 5 different services.
Still early, still iterating — but the scope is finally complete.
Happy to answer questions or get feedback
Cursor-based pagination, multilingual data.
Happy to share a short demo video if that’s useful.
Comment