We Didn't Just Build a Website: How the Website Helped Shape the DETai Ecosystem

This post is about how our website was built. About the technical and, probably, partly psychological side of that process.

Although now, after enough time has passed, it is becoming clear that saying “the website was built” is not entirely accurate.

That really is where we started. We wanted to make a modern DETai website: beautiful, fast, multilingual, understandable to people, and technically sound enough that we would not have to rebuild everything from scratch every few months. The task seemed fairly well defined. But the further we went with the website, the more questions appeared that were no longer really about the website.

What exactly belongs to DET, and what belongs to DETai? Where does a direction end and a product begin? Which parts of the ecosystem deserve their own pages? How are research, education, psychotherapy, products, and the technology platform connected? What is public information, and what should remain internal? Which legal documents belong to which surfaces? Who owns the data? Where is the canonical source of a definition, and where is its public interpretation? Then came localization, SEO, GEO, image provenance, page creation and modification dates, identities of people and organizations, relationships between entities, and structured data — that almost invisible layer that helps search engines understand what, exactly, is in front of them.

Who is a person here, and what is an organization. What is a publication, what is a product, and what is a project. When a page first appeared and when it genuinely changed. Where an image came from. How one object relates to another. For an ordinary visitor, almost none of this exists: they open a page and see text, images, and buttons, while underneath it a second website gradually grows — one designed not so much for human eyes as for machine understanding. And somewhere around the third day of yet another deep dive into this layer, a perfectly natural question occurred to me: what if half of this becomes unnecessary in six months? Or even in two weeks.

Google will change its recommendations, AI search will learn to understand websites in some new way, Schema.org will lose some of its current importance, a new standard will appear, or the framework everything runs on will change.

In the digital environment, what counted as best practice yesterday can become a historical footnote tomorrow. Does that mean several days of work could simply be thrown away? The question becomes especially funny when you remember how this whole story began. Because our plan was to just build a website.

When the website was still just a website

At one point, WordPress really was almost a deity.

That sounds slightly ironic now, but at the time it was entirely serious. WordPress let a person without a development team assemble a real website, install a theme, connect plugins, build a blog, forms, analytics — and then open Elementor and suddenly feel almost like a web designer.

For its time, it was an incredibly powerful model: you did not design a separate frontend and backend or think of infrastructure as a set of interacting systems — you assembled a website. If you needed a new capability, there was almost certainly a plugin for it; if you wanted to change the look, there was a theme or a visual builder.

We lived in roughly that mental model for a long time, until the question you have to ask at the beginning of the work gradually changed.

It used to be: “What kind of website do we want to build?” Today, more and more often, the question is: “What kind of system do we want to build — and what part of it will the website be?”

Modern web development became component-based, GitHub turned into a working center for development, Next.js made it possible to combine the properties of a conventional website and an application, and Vercel made deployment feel almost like a natural continuation of changing the code. But the real turning point for us came when AI entered this loop. Before that, the boundary was fairly clear: either you knew how to program yourself, or you worked within the possibilities programmers had prepared for you.

With AI, that boundary became noticeably less rigid. This does not mean programming disappeared or suddenly stopped requiring professional expertise. Rather, it became possible to participate in engineering work at another level: to discuss data structures, ownership, system boundaries, interfaces between systems, canonical sources for particular objects, and the consequences of architectural decisions without necessarily writing every function by hand. Gradually, the work started to sound something like this: this data must not be duplicated; language versions should be independent representations of the same meaning; this layer belongs to the website, this one to Storytelling, and this one to Knowledge Substrate; here we need a provider, here a consumer, and between them a stable contract. And this was the point where everything finally departed from the original plan. Because the plan had been very simple: two more weeks, and the website will be done.

By now, that sentence looks almost like a historical joke 🙂

Why did we spend so long on it?

At some point we had to ask another question, and it turned out to be much more important than the technical ones: why can't we simply stop?

Why not take the already beautiful homepage, a few sections, a decent mobile version, connect analytics, and say: that's it, the website exists? Probably because, little by little, we began to see it in a completely different way. Of course, no particular website exists “forever.” The design will change. The code will be rewritten. Some pages will disappear. Some technologies that look modern today will, in a few years, look roughly the way an old WordPress admin panel with forty-seven plugins looks now — twelve of which nobody can remember the purpose of. But the role of the website lasts much longer than its current implementation.

DETai's technology stack may change, new products, people, research, and ways of working may appear, but the place through which the ecosystem presents itself to the outside world will most likely remain with it for a very long time.

The website is one of the main public representations of the entire system.

And once you look at it that way, the task changes unexpectedly. There is no longer any point in trying to build a website that will never need to change — that is impossible. The real task is to build a foundation that can keep changing with the ecosystem for a long time without losing its identity.

Stewart Brand has an extraordinarily precise line for this in How Buildings Learn: What Happens After They're Built:

“A building is not something you finish. A building is something you start.”

Brand wrote about buildings that continue to live after the moment when an architect considers the work finished: people change them, rebuild them, adapt them to new circumstances, and the ability to withstand those changes largely determines the quality of the original architecture. At some point I caught myself thinking that almost the same thing was happening with the website. We are not building a page that we will one day ceremonially declare complete.

We are launching a long-lived digital structure inside which almost everything will change many times over.

When a website forces you to answer everything

And this is where perhaps the most unexpected thing happened: the website stopped merely representing DETai — it began forcing us to define DETai.

As long as an ecosystem exists in conversations, separate documents, repositories, and people's mental models, many boundaries can remain slightly blurred for a long time. Everyone more or less understands what is meant. But try laying all of it out across actual pages.

What belongs in the top navigation? What deserves its own page, and what is part of another entity? If a page says “DETai products,” what exactly are we calling a product? If there is a separate research section, where is the boundary between research activity, the method, and the technology platform? If a project has its own user data, does that data belong to the general ecosystem or to a specific product? If a person opens a legal document, which surface does it belong to? If the same idea exists in Knowledge Substrate, a publication, and the website, where is its canonical definition and where is the adaptation for a particular audience?

At some point it became clear that working on website navigation was almost imperceptibly turning into work on the ontology of the ecosystem itself. We literally had to decide what objects it consists of and how those objects relate to one another. Design unexpectedly pulled architecture behind it, while public user journeys pulled in legal documents and rules for working with data.

And the need to explain all of this to a person in simple language kept sending us back to the architecture with another question: do we ourselves actually understand what we have built here?

A rather interesting loop emerged: we tried to describe the ecosystem through the website, but the need to build a good website forced us to describe the ecosystem itself with increasing precision, and in the end the website became something like an integration test for DETai. If two parts of the system cannot be connected clearly on a public page, perhaps the problem is not the page. If we cannot explain how two entities differ, perhaps we ourselves have not defined their boundaries well enough. And if it is unclear who owns the data or where a definition should come from, a beautiful UI will not solve the problem. That is probably why several months of work on “the website” eventually included design, programming, semantics, SEO, legal architecture, localization, and work on the DETai model itself: one public surface unexpectedly required the whole system behind it to be sufficiently defined.

The website that stopped being only a website

The website itself, of course, did not disappear. Quite the opposite: gradually it became one of DETai's main public surfaces. Through it, a person can enter the method, research, education, products, team, events, publications, and documentation. This role is now explicitly described in the Knowledge Substrate project page “DETai Website”: the website is the ecosystem's public web layer, explaining its structure, showing relationships, and guiding people toward products, knowledge, and participation.

But precisely because of that, it looks less and less like a container into which we simply place finished content. Take an ordinary publication: it may begin as a thought or a voice note, turn into a text, go through editing, receive images, metadata, language versions, and several representations for different channels — and only then appear on the website or in Telegram. The website is no longer the place where the object is born and does not own its entire lifecycle; it becomes one of the forms in which that object is present.

That is why Storytelling gradually grew next to the website — a separate Publication Core responsible for preparing and moving publications; Knowledge Substrate remains the space for stable definitions, architectural boundaries, ownership, policies, and versions; individual products keep their own logic and data; and the website assembles a coherent public view of this entire construction for a person.

And this is probably where the formulation I currently like most appears: the website gradually became a system of presence. DETai needs to exist for a person, a search engine, and an AI agent not as a set of randomly connected URLs, but as a distinguishable structure in which it is clear what this is, why it exists, and how it relates to everything else.

And here the next irony begins: the clearer the architecture becomes, the more clearly you can see how much more there is to improve.

A project with no “done” state

Complex systems have a rather unpleasant property: while they barely exist, they seem very simple. When all you have is the idea of a future website, the task looks finite — build the pages and finish. Then the pages appear, and with them more and more layers. The state of being “done” keeps retreating a few steps farther away.

You can look at this as a wonderful endless project that can never be finished 😅 Or, at some point, notice something else: perhaps the very idea of final readiness was the mistake.

And this brings us back to the question we started with: if a substantial part of today's work will become obsolete anyway, doesn't that mean the effort was wasted?

For some reason, a very simple analogy with training comes to mind.

When a person trains for a long time, the result looks quite tangible: muscle, strength, form. But everyone knows that if you stop training for long enough, a significant part of that result will begin to disappear. So you might ask: what was the point of all those sets if their effect does not remain forever?

The answer seems fairly obvious precisely because the result of training was never limited to muscle. Along with it came the ability to tolerate load, return after breaks, maintain a routine, do one more set without particularly wanting to, and not depend on inspiration every time. Even if the specific form disappears, the person who once learned how to create it is already somewhat different from the person who is only planning to begin.

Something very similar seems to happen with technology. You can throw away specific code, replace the framework, rewrite deployment, completely change the data model, and one day rebuild the website from scratch — but the ability to make sense of an unfamiliar system, see relationships, tolerate complexity, and bring it to a working state does not disappear together with the repository.

Not very long ago, many things that today have become almost routine were somewhere outside our familiar language. Not because there was a clever plan to master another five professions, but because every next layer of the project required understanding a little more than the previous one. And at some point a rather funny inversion happens: first you are afraid to open the code and accidentally break something; then you become afraid to touch the architecture; and after a while the situation reverses completely — sometimes it becomes much more frightening not to change it when you can already see that the old decision no longer fits the system.

Perhaps this is one of the most important results of working on DETai that cannot be seen on the website at all.

What you cannot see on the website

By the evening of that third day, my head no longer wanted to see JSON-LD, canonical, provenance, dates, identifiers, or relationships between entities. After a full working day there was only ordinary physical tiredness left, and somewhere on the bicycle ride home an unexpectedly calm feeling appeared: something became better today.

Not forever — and that is probably the most important qualification here.

Gradually, the very idea that the meaning of work must necessarily lie in creating something that will never need changing seems to disappear. The website changes, the company changes, the profession changes, the body changes, technology changes, and so does the person doing all of it.

Strangely enough, resilience does not appear when a system stops changing, but when it gains the ability to change without losing itself.

For DETai, this creates a rather natural paradox. We are building a technological ecosystem around a human practice while simultaneously refusing to let technology replace the practice itself; we create fairly strict architectural boundaries precisely so the system can evolve more freely; we fix canonical knowledge in Knowledge Substrate while allowing publications to remain living snapshots of a particular moment; we use AI to move faster while understanding ever more clearly the value of human responsibility for meaning.

So in the end, the story of the website turned out not to be primarily a story about Next.js, Vercel, GitHub, Schema.org, or AI. All of these technologies matter, but each of them remains a tool of a particular time.

The most interesting thing happened at another level.

We started with the desire to build a website and gradually learned to think about a system. We started with separate pages and arrived at relationships between objects. We started with the question “what will a person see?” and now, in parallel, ask “what will a machine understand?” We tried to represent an ecosystem that already existed — and in the process discovered that the need to represent it forces us to understand much more precisely what it actually consists of.

And so the original question — “what if all of this turns out to have been for nothing?” — now sounds a little different.

A specific result really can disappear. Code can be rewritten, a standard replaced, a technology forgotten, a website completely rebuilt — and most likely, one day that is exactly what will happen to it. But if Stewart Brand is right, and a building is not something you finish but something you start, then perhaps digital systems should be treated in much the same way: not by trying to guess their final form, but by building them so they can outlive their own initial architecture.

And maybe that is why, at the end of a very hard working day, a strange and rather pleasant feeling sometimes appears: there is almost no energy left, your head is tired, tomorrow it all continues — and yet inside, it feels good.

Because there is tiredness from meaningless movement. And there is another kind of tiredness entirely — the kind that appears when today you managed to become capable of something slightly more difficult than yesterday.

And perhaps it is in moments like these that one simple thought becomes especially clear:

life is when you're glad you're tired.

Sources and materials

1. Brand, Stewart. How Buildings Learn: What Happens After They're Built. Viking Press, 1994. A book about architecture as a system that continues to change after construction is complete; the quotation “A building is not something you finish. A building is something you start” is cited from it.
   https://www.penguinrandomhouse.com/books/320919/how-buildings-learn-by-stewart-brand/

2. Google Search Central — Introduction to structured data markup in Google Search. Explains how structured data gives search systems explicit information about the meaning and type of content on a page.
   https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data

3. Schema.org. An open vocabulary of types, properties, and relationships for structured data on the web.
   https://schema.org/

4. DETai Knowledge Substrate — “DETai Website.” The canonical description of the website's role as the ecosystem's public web layer, its boundaries, and its relationships with products, knowledge, and Storytelling.
   https://docs.detai-x.com/ru/ecosystem/DETai/Platform_DETai/E2-Brand/sites/

5. DETai Knowledge Substrate — “Storytelling — Publication Core.” The canonical description of DETai's publication layer and the division of responsibility between preparing material and delivering it through channels.
   https://docs.detai-x.com/ru/ecosystem/STORYTELLING/