How we built this website: two days, AI agents and strict rules

In his list of tasks for the website, Konstantin suggested showing not only other people’s case studies but also how we work ourselves. This site is a good example: AI agents built it, while we set the tasks, checked and accepted the work. Below is what happened and when, taken from the repository’s change history, and the technical decisions behind it.

How long did it take?

All dates and times below come from the change history (git), in Moscow time.

From an empty repository to the first working version took an hour and a half. From the first version to a multi-page site with a blog, documents and two design variants took less than two days. The usual timeline for such a site at a contractor is weeks.

Who did what: AI or people?

AI agents wrote the code. A human did what AI cannot replace: decided what the business needs, set the tasks, looked at the result on a phone and on a large screen, and said “yes” or “redo it.”

Requirements came from Konstantin as they were: as a PDF document, voice messages, short messenger messages. The voice messages were transcribed, the requirements were merged into one list, and then the task went to an agent.

Every change went through two checks before publication:

• automated tests — at the time of publishing this post there are 186 of them, they run before every deployment, and the site does not go live if even one fails;
• a critic agent — a separate AI agent that did not write the code. It checks the change for errors, for consistency of style with the rest of the code, and for how it looks on screen, and its remarks go back for fixing.

This is how AI works in our client projects too: the machine prepares a draft, and we leave the decision and the checking to a human.

How is the site built technically?

The site is static HTML pages. A small build script generates them, with no frameworks or third-party libraries: the texts live in separate files, and templates turn them into pages. That is why the site opens quickly, there is no engine on the server that needs updating and protecting, and the site itself is easy to move.

We put several rules in place from day one:

• A strict content security policy (CSP). The browser runs only scripts and styles from our own domain. There are no scripts or styles embedded in the page, and no third-party counters or widgets.
• Our own fonts. The fonts sit on our server rather than being loaded from Google or other services. That means speed and no extra transfer of visitor data.
• No cookies. The site sets no cookies and does not track visitors. The savings calculator computes right in the browser, and the numbers entered are not sent anywhere.
• Images are our own only. Team photos and article covers are stored on our server in webp format, with no links to other sites. A photographer credit appears under every stock cover.
• Thin pages are not published. If a section has fewer than 250 words, the build stops: the page must be filled out or hidden from search engines.

Why two design variants and a view by role?

Konstantin liked two of the five concepts: “Shtab” (dark, with gold) and “Byuro” (light, like a law firm’s website). There was no need to choose right away: the site is built in both variants from the same texts. Visitors see “Shtab,” while administrators can switch to “Byuro” and compare. Tests check that both variants have the same set of pages.

The home page has a “Who are you?” question: builder, developer, lawyer, marketplace seller and other roles. The choice highlights the industries and solutions closer to that visitor. Without JavaScript the site shows everything at once and hides nothing.

How do search engines and AI assistants find the site?

Every page has its own title, description and image for previews in messengers; the article previews are drawn by a separate script. schema.org markup is built into the pages: organization, services, articles with author and date, questions and answers. There is a sitemap, robots.txt and an RSS feed for the blog.

For AI assistants that answer users’ questions, the site publishes llms.txt and llms-full.txt: a short and a full description of the company, services, prices, case studies and articles in plain text. This makes it easier for an assistant to retell correctly what we do.

What from this can you apply in your company?

The same approach works beyond websites: start with one task, release a first version quickly, and then improve in small steps, with a check each time. If you want the same for yourself, take a look at our first projects or tell us about your task; the review is free.