cortexit.ru: from content strategy to our own deployment, no site builders

TL;DR. The site you are reading. Not assembled in a builder: audience research and content strategy first, then a design system, a Next.js front end with TypeScript in strict mode, Schema.org markup aimed at AI search engines, and deployment to our own Ubuntu VPS via Docker and Caddy.

Situation: a contractor gets checked before the first conversation

After the first touch, the decision-maker goes and searches for the contractor. If there is no site, or it was thrown together in a builder one evening, the odds of making the shortlist drop — especially when the thing being discussed is software development.

For a company selling engineering work, a no-code site creates a contradiction: deep development is claimed, and the first piece of evidence was assembled with a mouse in someone else's editor.

Task

1. Make the site proof of competence rather than a shop window.
2. Go through the full cycle in-house, from audience research to the server.
3. Build in markup that language models can parse, not just search crawlers.
4. Depend on no platform: code and server under our own control.

What we built

The work ran in phases, each with its own artefact.

Research. Personas, voice of customer, positioning, an inventory of evidence — separate documents rather than guesses made along the way. A master plan for the page structure was built on top of them.

Copy. Full body copy, interface microcopy and the FAQ section were written before any markup, so the page structure follows the content rather than the other way round.

Design system. Colour, typography and spacing tokens live in one file. Light and dark themes from day one, with a toggle that remembers the choice.

Front end and engineering. Next.js with React, TypeScript in strict mode, Tailwind, shadcn/ui components. Case studies live in MDX. Forms use react-hook-form and zod with server-side validation and explicit consent to data processing. Heavy sections load lazily.

Search and AI visibility. Schema.org markup for the organisation, the person and the case articles, a sitemap, robots rules that explicitly admit AI search crawlers, and generated social preview images.

Deployment. Docker, systemd and Caddy on an Ubuntu VPS. Our own infrastructure, not a hosting platform.

Result

• A live site on our own code and our own server — not a builder, not a one-shot generation from a prompt.
• The full cycle done in-house: research, copy, design system, front end, infrastructure.
• Schema.org markup and robots rules let AI search engines parse the site, not just classic search.
• The design changes by editing one token file; markup is not rewritten when the look changes.

Key technical decisions

1. Tokens instead of literals in components. Not a single colour or spacing value written as a number inside the markup. Changing the look means editing the token file, not walking every component. That decision has to be made before the markup, or it doesn't hold.
2. Design deferred until a working URL existed. Pages were first assembled on default tokens and deployed, and the styling was locked afterwards. Discussing design on a live page beats discussing it on abstract examples.
3. Case studies in MDX, not in a database. A case study is text that gets edited. It sits as a file in the repository, goes through review in a pull request, and is versioned alongside the code.
4. Strict TypeScript and server-side form validation. Client-side checks are a convenience for the user, not a defence. Form data is validated on the server, and consent to processing is mandatory.

FAQ

Why not build the site in a website builder?

For a company selling development, the site is the first piece of evidence of competence, and a builder can't assemble that. There's a practical reason too: the code and the server stay under our control, and page behaviour isn't capped by what the platform allows.

What does Schema.org markup do for AI search?

The markup describes the page's entities in machine-readable form: who the author is, what the organisation is, what the case is about. It doesn't guarantee being cited in AI answers, but it removes ambiguity when a page is parsed, and it remains the basis for rich results in classic search.

What would come next

The natural continuation is publishing source data and analyses that give AI search engines something to cite, measuring visibility in AI answers, and extending the case section as projects ship.

If what you need is process automation rather than a website, let's talk it through in 30 minutes.