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 eight kilobytes: page transitions without a reload, the header, the cursor and the typing task list on the home page.

The site collects nothing. There was a brief form here, and it worked: it posted to a receiver in Russia, which filed each submission into a database, an inbox and Telegram. I removed it. Any form or analytics counter makes the site owner a personal data operator under Russian law, with the regulator’s paperwork that comes with it, and for a business-card site that is dead weight. Enquiries arrive by email or Telegram, and the first reply is just as concrete: I ask the brief questions in the conversation.

What it looks like

abrahamden.dev
Home page of this website: the offer, status, an about card and the fork between websites and systems
Home page of this website: the offer, status, an about card and the fork between websites and systems, mobile version
Home page of this website: the offer, status, an about card and the fork between websites and systems

How it is built

How this site is built: repository, build, static files abroad; the brief form is gone, enquiries come by email and TelegramRepositorycase 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 librariesEnquiriesemail and Telegram · no form on the siteEmailmain channelTelegramfast but unstableHow this site is built: repository, build, static files abroad; the brief form is gone, enquiries come by email and TelegramRepositorycase 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 librariesEnquiriesemail and Telegram · no form on the siteEmailmain 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