A course catalogue that has to work in three languages

The problem

An academy sells one thing: the belief that after this course you will be employable. Everything on the site serves that — twenty-five years, seventy-five thousand graduates, the entry in the education registry, the international certificates, the instructors with their own pages.

The argument is not the hard part. The catalogue is. Dozens of courses, in person and online, and a large part of the students are Ukrainians living in Poland and deciding on a new career — so the catalogue has to exist in Polish, Ukrainian and Russian, and be kept up to date by the academy’s staff, not by a developer.

What I built

Courses and instructors as records, not pages

Counted on the live site in September 2026: 117 course pages — 34 in Polish, 44 in Ukrainian, 39 in Russian — and fifteen instructors, each with a page in up to three languages. A course knows its format, its length, its level and who teaches it; an instructor knows which courses they run. Built as ordinary pages, that is over a hundred hand-kept documents and no way to answer “which online courses does this instructor teach?”

Search first, then two doors

With a catalogue this size, browsing stops working somewhere around item thirty. So the search field sits in the header, and under it the catalogue splits by the first decision a student actually makes: in person, or online. Those are different products with different prices and different logistics, and forcing them into one list was the first thing I changed.

The language a student reads in

Polish, Ukrainian and Russian on one site, switched from the header. The difference between reading a course description in your own language and squinting at a translation is the difference between enrolling and closing the tab.

Enquiries go to a phone, not an inbox

A question from the site lands in a Telegram channel the sales team already keeps open all day. It is the smallest piece of work in the project and probably the highest-leverage one: a student choosing between three academies does not wait six hours for an email reply.

Why the page builder stayed

The site runs on a custom theme with Elementor for the pages. That is a considered choice, and it is the academy’s, not mine. Their staff change the marketing pages constantly and wanted to keep doing it in the tool they knew; taking that away would have turned every landing page into a message to me.

So the split is this. The pages the academy edits by hand live in the builder. The catalogue that carries the business — courses, instructors, languages — is structured records with their own fields underneath, and that is the part a builder cannot do on its own. When a studio brings me a finished design, I build it as a custom theme with no builder at all, because there the design is the point. Here the point was that the academy’s staff stay in charge of their own pages.

What the builder costs is page weight, and the academy knows it.

On mobile

The search field stays first, both course tracks stay reachable, the consultation phone number stays in the top bar. Nothing scrolls sideways.

What I would do next

Move the course pages themselves onto hand-built layouts and leave the builder to the marketing pages. Courses are structured records and do not need a builder to be displayed; taking them out of it is where the load time is hiding.

What the academy gets

One catalogue in three languages instead of three sites. A new course or a new instructor is a record their staff add, in whichever languages it runs. And a student’s question reaches a person’s phone, not an inbox.