Why we rebuilt our own website, and what it runs on

The site we had

Until this autumn, aviraltrendzpvtltd.com ran on WordPress. Its sitemap listed 300 URLs: 71 pages, 115 posts and 114 portfolio items. Of the 114 portfolio items, 105 were theme demo content, villas for rent and photography galleries that had been installed with the template and never removed. The posts were general pieces about 5G, blockchain and remote work that could have been published by anyone. And the site gave visitors two different founding years and two different project counts, depending on which page they landed on.

It was the normal state of a site added to for years by different hands. But we build websites and software for a living, and a company's own site should be its clearest piece of evidence. So we rebuilt it. Here is what changed, and what it now runs on.

One facts file

The first decision was not about design. It was that every figure on the site, the start year, the outlet count, the website count, the office count, lives in one TypeScript file, with a source and the date it was last confirmed. Pages read from it; nobody types a number into a page. Answer engines repeat whatever they find, so a site that says two things about its own age will be quoted saying both. Now it says one.

Content as typed files

Every service, technology, AI capability, product, industry, case study and location is an entry in a typed content file. The type says what fields a page must have, and the build fails if one is missing or wrong. A page exists only when its entry is marked live.

That has a consequence we like. The mega menu in the header, the footer and the sitemap are all generated from the same files. Adding a page is a content change and nothing else, and the menu cannot drift out of step with what is actually published.

Written to be quoted

Every detail page carries an FAQ. Each answer is written to stand on its own when an AI answer engine quotes it out of context: the answer comes first, it names ATPL or Ethos or the subject so it makes sense alone, and it stays under sixty words. Every page also states at least two things that are true only of its subject.

Real HTML, with the motion on top

The site runs on Next.js 16 with the App Router, React 19 and TypeScript in strict mode. Pages are rendered on the server, so what a crawler or a visitor receives is complete HTML with its metadata, not an empty shell waiting for JavaScript. Pages built from local content files are prerendered when the site is built.

We kept the page transition engine from the previous build. It is a WebGL stage that carries the visitor between pages, and it sits as a layer over real HTML rather than replacing it. Nothing a crawler needs is drawn only on a canvas. The engine is treated as protected: if a new page and the engine disagree, the page changes.

Every image hosted here

Every screenshot and image on the site lives in the site's own public folder. Nothing is hot-linked from a client's domain or a third-party host, which is how images on a site quietly disappear over the years. A small script reads the dimensions of every image and writes them into a manifest, so each one is served with its real size and the layout does not shift while it loads.

Articles as files

This section, Tech Updates, is a set of MDX files in the repository. An article is published by merging it to the main branch. That is a deliberate limit. Next.js is the wrong choice for a content site that a non-technical team must edit daily with no developer on hand, and we say so on our own Next.js page. For a company that ships code every day, it is the right one. If the section finds a rhythm, moving publishing onto Openextcms so that non-developers can post is the next step.

Every old URL still goes somewhere

A rebuild that breaks links throws away years of search history. Every one of the 300 old URLs has a rule. Pages and posts redirect to the closest new page. The real portfolio items redirect to their case studies. The 105 theme demo items return a proper "gone" status rather than a soft 404, so search engines drop them cleanly. Old category, tag and author paths land on this section.

What we did not do

We did not publish performance figures. The site is built to be fast, but a number quoted before it has been measured on real visitors is a guess dressed as a fact, and the point of the rebuild was to stop doing that.

Why this matters to a client

The rebuild is the same work we do for clients: one source of truth for facts, content that is typed and checked, server-rendered HTML that search and answer engines can read, motion that sits on top rather than in the way, and a migration that keeps every old link alive. If you want a site built this way, our Next.js page explains when it is the right choice and when it is not.