All work

This website

Built by the rules I offer clients: it opens instantly, depends on no third-party services, and its copy and case studies are edited without a programmer.

Why it is in the case studies

A site that promises a client speed has no right to load slowly. The easiest place to show that is the site itself.

How it works

No all-in-one framework and no UI kit. Own styles, own tokens. The site is a case study — it must not look assembled from somebody else’s components.

Both languages are built into the routes. /ru/ and /en/, hreflang on every page, and not one hardcoded string in the components: all text goes through dictionaries, so the English side cannot quietly fall behind.

Only native animation. Scrolling drives CSS scroll-driven animations, page transitions use View Transitions, diagrams draw themselves through stroke-dashoffset. Not one animation library: all the JavaScript on the page is about two kilobytes, and that is the config demo on the home page plus the form submission.

Submissions go to a receiver in Russia. The first collection of Russian citizens’ personal data has to happen on servers in Russia, while the static site lives on my cluster abroad. So the form posts to a separate service, which files the submission into a database, an inbox and Telegram — one channel would be a single point of failure.

How it is built

How this site is built: repository, build, static files abroad and a brief receiver in RussiaRepositorycase studies and notes in markdown · ru and en dictionaries · publishing is a commitAstro build → static filesHTML and CSS, about 2 KB of JS per page · cluster abroad: Helm, ArgoCDVisitor’s browsermotion is CSS scroll-driven and View Transitions, no librariesBrief receivera separate service hosted in Russia · without JS the form sends a plain POSTDatabasenever failsEmailmain channelTelegramfast but unstableHow this site is built: repository, build, static files abroad and a brief receiver in RussiaRepositorycase studies and notes in markdownru and en dictionariespublishing is a commitAstro build → static filesHTML and CSS, about 2 KB of JS per pagecluster abroad: Helm, ArgoCDVisitor’s browsermotion is CSS scroll-driven and ViewTransitions, no librariesBrief receivera separate service hosted in Russiawithout JS the form sends a plain POSTDatabasenever failsEmailmain channelTelegramfast but unstable

Why this way — content in the repository rather than in a CMS

The obvious solution for a site with case studies and a blog is a CMS: an admin panel, a visual editor, publishing without a developer. That is exactly what I usually build for clients.

Here I did the opposite: case studies and notes are markdown files in the repository, and publishing is a commit. This site has one editor and he is a developer; an admin panel would serve one person who is perfectly happy writing in a code editor.

The price is honest: fixing a comma needs git. In exchange — no server side, no security updates, a full history of edits and the ability to roll any of them back.

Other case studies

Case studies and personal projects