I built my own site in AI-native development mode — designing the code and the positioning at the same time, inside a single conversation with a language model. AI-native development is a way of building a product in live dialogue with an AI: the model generates and rewrites code, while the architect drives the logic and makes the structural calls. The core lesson of this case: if you sell the architecture of AI systems, your own site has to be built on that exact architecture — otherwise everything you tell clients stays words.
Why was the code the easy part?
The hardest part of building the site was not the code — it was deciding what the site had to say. Writing code in dialogue with a language model is the fast part. Working out the meaning the site exists to prove is the slow one.
The thesis I arrived at, and should have started with, is one line: I don't deploy agents or chatbots — I design the architecture of your revenue. A site for someone who sells that method can't be a brochure about it; it has to be the first proof the method works. Below is how the code and the brand were born together, in the same conversation with AI — not "Tilda vs. Webflow."
What actually blocked the start?
What blocked me was not motivation or positioning, but the method of assembly. Without a site I was losing potential clients and couldn't scale — the need was obvious. The positioning was roughly in place too: seventeen years across consulting, sales, and AI.
What didn't click was how to build it. The standard route — hand a finished offer to a copywriter, a designer, a developer — assumes the offer already exists in compressed form. Mine didn't. The offer had to come into being together with the site, because the site itself is the method, not a showroom for it. I'm an architect, and I needed to design meaning and code at once — otherwise the site becomes a pretty box indistinguishable from another three thousand "AI consultants."
How do you design the brand and the code in parallel?
You design them in the same sessions, letting each correct the other, instead of running "strategy first, build second." In one message the AI helps build out a React/TypeScript architecture — components, routing, language layers. In the next, the same AI is a sparring partner on what to call the services section and how an "AI Salesperson" differs from an "AI Producer." When the page architecture demanded clean service segments, the services themselves changed; when the offer compressed to one line, the homepage architecture shifted to match.
Out of those parallel passes a short, accurate role emerged: AI Architect of Revenue — not "chatbot installer," not "AI consultant," not "prompt engineer," but an architect who designs how AI sits inside a company's money loop. Parallel assembly shakes out the language that can't survive contact with actual sections and buttons.
The initial build took about 4 weeks. The first version of the site — 17 pages — shipped in late February 2026, and I immediately translated the entire site into English as the primary language. After that I steadily added new services and refined the structure, and in May 2026 I ran the GEO optimization — a separate case (see below).
Sequential build vs. parallel AI-native build
| Sequential (copywriter → designer → developer) | Parallel AI-native build | |
|---|---|---|
| Order | Strategy first, build second | Meaning and code designed together |
| Where the offer is born | Up front, detached from the product | In the process, on contact with real sections |
| Main risk | Smooth but "laboratory" wording | Wording stress-tested by structure |
| Author's role | Hands a brief to executors | Architect drives meaning and code directly |
| Typical result | Polished wrapper or trapped message | Meaning and structure stitched as one |
Three artifacts that prove the method
Three things on the site prove the method rather than decorate the page: a Telegram CRM instead of a contact form, a "supermarket of meanings" instead of a services list, and demonstration through built work instead of an "about me" wall.
A Telegram CRM instead of a contact form
The site has no "leave a request, we'll reply within three business days." When a visitor submits a form or hits a contact button, a card lands in my Telegram in seconds with full context: UTM tag, the page they came from, the contact, and what specifically they reacted to. I know the context before the conversation starts.
This is a small but honest demonstration of the principle. AI architecture isn't "add a chatbot to a site" — it's wiring the points correctly: site → qualification → CRM → response channel → a specific human. A chatbot without that loop is decoration.
A "supermarket of meanings" instead of a services page
Most consultants' services page is one comma-separated list: "strategy, audit, implementation, training." Mine is split across separate cards and pages: AI Salesperson, AI Producer, GEO Optimization, and separately Music with AI. Each is a standalone page a client with a concrete task can read and immediately tell whether it's for them.
It works like shelves in a supermarket: you don't pick "food," you pick bread or cheese. A client arriving with "we need to auto-filter inbound requests" doesn't need a paragraph on "comprehensive AI implementation" — they need the AI Salesperson page, and now it exists.
Demonstration through action, not "about me"
The site shows fluency with AI through results you can touch, not through "ten years in AI." There's a Music with AI section — original songs produced with AI tools in five languages — and examples of the agent dialogues I build for clients.
It works like an architect's portfolio that shows built houses, not diplomas. In the era of AI-generated bios, "about me" text is worth roughly nothing. A song in five languages either exists and works, or it doesn't.
Why is the site a Proof of Concept?
The site is a Proof of Concept because it is built through AI and structured as an AI system, not merely written nicely about AI. A Proof of Concept is a working example that proves a method is real and applicable, not just described.
The logic is simple. When a serious buyer decides whether to trust you with something load-bearing in their revenue loop, they don't read your copy — they look at how your storefront is assembled. If the storefront is a standard drag-and-drop builder with a "contact us" form, they draw a fair conclusion: everything you say about AI architecture, you say with other people's money. So the site isn't a business card or a marketing channel — it's the proof the method exists. Without that proof, everything else is words.
What did it give me in practice?
In practice the site changed how the first conversation starts, even though I deliberately publish no "conversion up Nx" — there was no measured baseline before, so there is nothing honest to compare against. What I do see clearly:
- The conversation starts with the task, not my background. Anyone who reaches out via the site already knows who I am and what I do — the first twenty minutes go straight into the work.
- The client picks the service, instead of me offering the whole menu. The "supermarket" cards do that work — the client has already chosen a shelf.
- There's a technical foundation for the next steps. Without the site built on the right technology, GEO optimization would have had nothing to optimize.
GEO as the next layer
Once the site was built, one problem remained: AI search engines couldn't see it. I'd open ChatGPT, ask about myself, and get back a namesake. That became the next case. Architecture is one layer; visibility to AI is the layer on top. The two cases are a pair and read best together.
Case 2 of 2: How I Made My Site Visible to AI Search →Want the same for your business?
If you want your site to work as an AI system, start by checking whether AI can even see it. I run a GEO audit of your site — a short report with the main barriers to your visibility in AI search and a prioritized fix list. The first audit is free.
