Skip to content
Olexa Studio.

Case study

Olexa Studio

This site is our own product, which we conceived, wrote, and maintain. It is a showcase of our approaches to development: from architecture to the small details that ensure stability and speed.

The Task: Multilingualism and Speed

We needed a site to represent the studio in three languages—Ukrainian, English, and Hebrew—without compromising loading speed. A separate challenge was the Hebrew version: we had to ensure correct right-to-left (RTL) text display and make sure that price ranges were not read backwards. This is a typical task for projects entering the international market.

Another requirement was that the site had to be static, meaning as fast as possible for the visitor and for search engines. Instead of assembling the page in the browser, the server immediately serves the finished HTML. This is achieved thanks to the Astro framework. Hosting on Cloudflare Pages allows content to be delivered from the server closest to the user, which further speeds up loading.

We also took care of the language switching logic. No language lives at the domain root: the root only determines the language—based on a choice the person has already made, their browser language, or their country. The address with the language is never redirected, so the language switcher does not return the person to where they came from. For search engines, each page clearly indicates its alternative language versions.

The Solution: A Static Site with Server-Side Functions

The site is based on the Astro framework with Tailwind for styles. This allows for the creation of fast static pages that are easy to maintain and expand. All texts are placed in separate language files. This simplifies their translation and editing, and also allows for automatic checks on the completeness of the translation for each of the three languages.

To process submissions from forms, such as the brief, we use Cloudflare serverless functions. When you fill out a form, the data is sent to a function that sends us an email and simultaneously transfers the submission to our internal client portal. The portal is a separate application on Next.js with a PostgreSQL database in Docker. The public site remains static, and everything that requires a database lives in the portal.

The experience of creating multilingual sites, particularly with right-to-left script, is transferable to projects that require several language versions. We know how to structure content, set up page addresses, and ensure correct technical display.

Quality Control and Automation

To prevent errors from reaching the live site, we wrote our own automated checks. A script locally, without network access, checks the built site: whether the headers are in place, whether the canonical addresses and links to language versions are correct, and whether the sitemap is generated correctly. A found error terminates the check with an error code, and we do not deploy such a build.

This set of checks replaced a paid service that would have cost $83 per month to audit just a few pages. This approach to automation allows us to detect problems at an early stage, rather than after they are noticed by users or search engines.

We also control how our content is used. In the robots.txt file, we explicitly forbade training large language models on the site's texts, although we allowed search engines and AI assistants to index and quote it. This is an example of how you can manage access to your content at a technical level.