The website you are reading right now

Context

Selling AI-agent development rested on chat threads and retelling: every new conversation with a prospect started with explaining in words what exactly I do and why it works. Case studies existed as files, not as pages you could link to — until the call, the client couldn’t verify anything on their own.

The audience, meanwhile, is twofold: the business owner decides whether to write to me at all, and their technical specialist checks whether I know what I’m talking about. Material that convinces both at once needed a home — and the home itself had to serve as proof of competence.

A separate problem was the price question. The conversation about money was put off until the call, and some contacts dropped off before it ever happened: people had no sense of the order of magnitude and didn’t want to ask.

Constraints

• The design system was approved before development started. Tokens, fonts, spacing and the signature “before → after” element were locked in advance — they can’t be changed “as you go”, only carried over one-to-one. That ruled out any off-the-shelf UI kit
• No external UI libraries or animation packages. Every component is custom, on Tailwind alone. The site must not look like a template
• Cyrillic as a hard requirement. Most “designer” typefaces break on Russian — this drove the choice of fonts and explicit Cyrillic subsets
• Speed over effects. Clients open the site on a phone, on the move: zero JS where it isn’t needed, a single animation across the whole site, and reduced-motion switches movement off
• A server with 2 GB of RAM. Building the image twice pushed the machine to the memory limit
• The hosting provider’s network restrictions. The data center blocks the IPv4 route to the messenger’s API — only IPv6 works, which is off by default in containers
• Secrets only in the server’s environment, nothing in the repository. Plus graceful degradation: without the keys the site must still work, just with those features switched off

Solution

What it delivers

The website turned the conversation about my work into verifiable material: case studies with before → after metrics, two pricing calculators, a live demo of an AI agent right above the fold, and a request form that records the inquiry and delivers it to the owner within seconds. A prospect works out the cost of their own scenario before the call and arrives with a substantive question.

Above the fold sells through mechanics, not words. In a mock messenger window, a dialogue between a customer and an AI agent plays out: the customer writes at night, the agent answers from stock levels and prices, and underneath sits the signature line “3 hours → 40 seconds”. There are thirty scripts covering ten B2B wholesale industries; a random one is shown on every visit. Then the demo comes alive: the visitor types into that window themselves — and a real AI agent answers, with a built-in catalog of a fictional warehouse, calculating totals, quoting stock levels and politely steering the conversation back to business. If the external API is unavailable, the window keeps working on prepared replies — the demo never breaks.

Content is data, not markup. Each case study is a separate MDX file with typed frontmatter: headline, metrics, stack, diagram, card for the home page. The schema is validated at build time — a typo in a new case fails the build with a clear message in Russian rather than quietly breaking the page. The same files generate the cards on the home page, the case list, the sitemap and the OG images: adding a case study requires not a single line of markup.

Calculators instead of “price on request”. The first estimates the implementation and monthly fee for an AI Sales Employee by company size and region; the second assembles an AI Agent Fleet by roles with a bundle discount. The numbers recalculate with a smooth animation in the spirit of the same before → after signature, and the first interaction fires a goal in analytics — you can see that a person was doing the math.

A request never gets lost. The form first records the inquiry, together with the fact of consent to data processing, in the server’s local store and only then sends a notification to the messenger: a failure of the external API doesn’t lose the request. Analytics connects only after consent in the cookie banner; if declined, the counter isn’t loaded at all.

Speed and deployment. Pages are generated statically at build time, and architecture diagrams are rendered to SVG in advance — the diagram library never reaches the visitor’s browser. The site lives in a minimal Docker image behind a reverse proxy that issues and renews the certificate itself. Push to the main branch — and the edit is on the production domain within one to five minutes, with no manual steps and not a single 502 for visitors. The whole journey from a blank page to the production domain took a weekend — and since then the site has been developed through pushes alone.

Architecture

Next.js with static generation — but not pure static. Pages are served pre-built, while the server side remains — for the request form and a future AI assistant with RAG. A static site generator would have required a separate backend.

Design-system tokens in the CSS layer, not in a config. Colors, typography and the spacing scale are carried over one-to-one from the approved mockup and serve as the single source of truth.

Direct MDX compilation instead of an off-the-shelf rendering library. A popular library silently dropped props passed to components inside the content: the table received empty data and crashed the page. Direct compilation removed a whole class of silent failures.

Diagrams are rendered at build time, with the source hash embedded in the SVG. Zero JS diagrams in the browser. A build-time check compares the hash: change the source, forget to re-render — the build fails with instructions on what to run.

The only animation is a block appearing on scroll. Blocks visible on load aren’t animated: otherwise the repaint became the main paint element and hurt the speed scores.

Auto-deploy on the server side, not in cloud CI. A scheduler on the server checks the revision against the repository once a minute and runs the deploy itself: fewer moving parts, no dependence on someone else’s platform.

A reverse proxy with retries during restarts. A one-second container restart doesn’t show the visitor an error — the request waits for the new backend.

Avatar assets are baked by an offline script. Cropping, resizing and two formats are computed once during preparation: the file matches what’s displayed one-to-one, no layout shifts. Source files weigh 11–12 MB; in production, 11–32 KB.

Stack

Outcome

Speed scores come from an audit on the live domain: home page 94 · 96 · 100 · 100, case page 93 · 96 · 100 · 100 (performance · accessibility · best practices · SEO). Layout shift — zero, main-thread blocking — 10 ms, first paint — 1.0 s on mobile simulation.

Size of the showcase: eight case studies, eight architecture diagrams, six pricing pages with calculators, thirty dialogue scripts, a live demo chat and seven analytics goals — all from six production dependencies, without a single UI library.

A separate part of the product is the legal layer: consent to personal-data processing recorded on the server, a cookie banner with an equally prominent decline option, legal details, a non-offer disclaimer on pricing pages and security headers. The site is legally ready for ad traffic.

What I’d do differently

• Check that a library actually passes the data through, not just “renders”. The content rendering library silently dropped component props inside MDX: the table received an empty array and crashed the page. When adding a layer between data and a component, the first thing to write is a “did the value arrive” check, rather than trusting the example in the docs
• Line endings aren’t cosmetic. A deploy script assembled on Windows failed on the server at the very first line: the repository was serving the file with Windows line endings. Line endings need to be pinned in the repository settings from day one — before the first executable file appears
• Check network access to external APIs from the environment where production will run — and from inside the container. The form didn’t work because of a closed IPv4 route to the messenger and IPv6 disabled in containers. The diagnosis took an hour; the check itself takes fifteen seconds. “Works on the server” and “works in the container” are different statements
• A server with 2 GB of memory can’t be used as a build machine without a safety net. Building the image ate the memory and the machine was unresponsive for about eight minutes. Either build the image outside production, or set up a swap file before the first deploy, not after the incident
• Secrets must not end up even in the example file. Real keys turned out to be written into the environment-variable template. They never made it into the repository history — verified by searching every revision — but they had to be reissued anyway. The example holds placeholders only; real values exist only on the server

Where next

People also look at

Want a website where your numbers and processes speak for themselves?

Get in touch — we'll work out what can be automated in your case.

I reply the same day, usually within a couple of hours.