Ady Endre: a CMS built to outlast us
Zagreb's oldest Hungarian cultural society needed its 94-year archive online, in three languages — and a system its own volunteer staff could run without us. This is our one real client project, and the three technical calls that mattered most.
Kiran RamagiriFounder7 min read
Every other post in this journal is about something we built for ourselves — a concept, a demo, a way to show what's possible with nobody to answer to but our own judgment. Ady Endre isn't that. It's a real client: Zagreb's oldest and largest Hungarian cultural society, founded in 1932, nine active sections, and a volunteer staff who needed a website that would still be theirs long after we stopped being in the room.
That changes the brief in a way that's worth being honest about. A concept build answers to taste. A client project with a 94-year institution behind it answers to something heavier: will this still be running correctly in five years, run by people who didn't write a line of it?
The real constraint wasn't the design
The design problem was real — a warm, editorial, paper-and-ink identity with a torn-calendar-page motif drawn from Hungarian folk art, built in Framer Motion so the page transitions felt hand-made rather than templated. But that wasn't the hard part, and I'd be overselling the project if I pretended otherwise.
The hard part was that the society's entire institutional memory — the 1932 founding story, nine sections' worth of activity history, a news archive going back years — had never had a real home, and whoever took over running the site next would need to be a developer just to post a news update or add a board member. A beautiful site that only we could maintain would have solved the wrong problem.
Three technical decisions, and why each one mattered
We chose Vite over Next.js — deliberately, not by default. This isn't an SEO-critical funnel where server rendering earns its complexity. It's an editorial, animation-heavy site where the public pages and the admin CMS share one codebase, and Vite's dev speed mattered more here than machinery this project was never going to use. Reaching for Next.js on every project because it's the default is exactly the kind of decision that looks safe and isn't — the right tool depends on what the site actually has to do.
We built an auto-translation pipeline, with caching and custom handling, not a plugin. The news archive was originally Croatian-only. Bringing it into Hungarian and English automatically is the easy 80% of the problem; the hard 20% is making sure the pipeline never mangles the society's own name, its section titles, or terms specific to the organization — the exact words a generic translation layer gets wrong most often, and the words a cultural society can least afford to see mistranslated on its own website.
We used Supabase with role-scoped row-level security, not a shared admin login. News, activity sections, board members, events and documents all needed real relational structure — and real boundaries. A volunteer editor managing one section shouldn't be able to touch, or even see a path to breaking, anything outside their role. That's not a feature you bolt on later; it has to be the actual shape of the database from the start.
What almost went wrong, quietly
The society runs on a free-tier database, which is the right call for a nonprofit's budget and the wrong call if nobody accounts for what free tiers actually do: they sleep. A visitor hitting a cold database is a multi-second stall on what should be an instant page load — and for an institution whose whole pitch is "come find your community here," that first impression matters more than almost anywhere else. We added a small scheduled job that pings the database on a weekly cadence, just often enough to keep it from fully going cold. Nobody will ever notice this decision. That's exactly the point of it.
Why this one felt different to build
Every other project in this journal, we got to make every call ourselves. Here, every decision had to survive contact with people who aren't developers, won't read documentation, and are volunteering their time to keep a 94-year-old community running. The measure of success wasn't "does this look impressive" — it was "can someone who has never touched a CMS before post next month's news update without calling us."
That's a different kind of hard than anything a concept build asks of us, and it's the kind of project we want more of.

The project behind this post
Ady Endre
Cultural Society Website & CMS
Questions worth answering directly
- Why did you choose Vite instead of Next.js for a client website in 2026?
- Because Next.js's server-rendering machinery solves problems this project didn't have. It's not an SEO-critical e-commerce funnel — it's an editorial, animation-heavy site where the public pages and the admin CMS share one codebase, and Vite's development speed mattered more here than server-side rendering ever would have. Reaching for the same stack on every project regardless of what it actually needs is how you end up with the wrong tool that happens to be the popular one.
- How do you stop an auto-translation pipeline from mangling an organization's own name or terminology?
- With caching and custom handling built specifically for that organization's vocabulary — not a generic translation plugin left to guess. The society's own name, its section titles and its specific terminology get handled explicitly rather than run through the same generic pass as ordinary prose, because those are exactly the words a cultural institution can least afford to see mistranslated on its own website.
- Why does a small nonprofit's CMS need row-level security instead of one shared admin login?
- Because a shared login means every volunteer editor can see and touch everything, whether or not it's theirs to manage — and with nine active sections and rotating volunteer staff, that's a real risk, not a theoretical one. Row-level security enforces who can touch what directly in the database, so an editor managing one section genuinely cannot reach, or accidentally break, content that belongs to another.
Also available in Hrvatski · Magyar

Kiran Ramagiri
Founder
Builds Kyro Studio's products end to end — design, engineering and the automation underneath. Previously built BW International Recruitment and RS Ventures, a seven-brand cloud kitchen group.
Connect on LinkedInHave a project in mind?
More from the Blog
Growth
Reading a Search Console Links report without panicking
A sudden list of unfamiliar domains linking to your site looks alarming in Google Search Console. Most of the time it isn't — but you do need to be able to explain every one of them. Here's how we actually read that report.
Oct 20, 2026 · 6 min read

AI in practice
AI product photography that doesn't look like AI
Most AI product photography looks fake for a specific, fixable reason: the model is allowed to regenerate the product, not just the scene around it. Here's the actual discipline behind doing it properly.
Oct 19, 2026 · 6 min read

Case notes
Rotyi Bistro: a menu that gets out of its own way
Small kitchens live on Instagram, but their websites are often a PDF nobody opens. We wanted to see what happens when the website works as hard as the Instagram feed does.
Oct 16, 2026 · 5 min read