Polyarix 5.0

Your own website is the most demanding project there is: the client is picky, there are no deadlines, and everyone sees the result. This is an honest story of how our company’s site went from WordPress through Laravel to a “static Astro front end + headless Laravel CMS” setup - and why the new version loads instantly, lives in four languages and rebuilds itself after every edit in the admin panel.

The site’s history goes back to 2013, and all the early versions ran on WordPress. It was never a “template site”: a unique theme written just for us, three.js effects, custom fields on ACF, multiple languages. Over those years the site went through several redesigns - the look changed, but the platform stayed the same. Languages were added gradually too: until 2020 the site lived in two, then a third one joined.

And WordPress did its job honestly. If anything demanded constant attention, it was security: WordPress is the world’s most popular CMS, which also makes it the most attacked one, so the core and the plugins have to be patched without pause.

Over time another observation accumulated: a site with heavy 3D graphics and several languages kept running into the architecture of a general-purpose CMS. Everything worked, but “works” wasn’t what we were after - we were looking for the most convenient and fastest solution possible. For a company that builds websites for clients, its own site is also a proving ground: we test approaches there before offering them to anyone else.

In 2022 we moved the site to Laravel - the framework we build most client projects on. A classic monolith: Laravel renders pages on the server, the content lives in a database, the admin panel is our own.

• Full control over the code: any feature is a matter of development, not of hunting for the right plugin.
• Order in the data: projects, articles, reviews, job openings and technologies became proper database entities with their own fields and relations.
• Calmer about security: Laravel closes whole classes of attacks out of the box, and the attack surface is noticeably smaller than in a CMS with dozens of third-party plugins.

That version served for four years. But by 2026 we wanted more again.

The new version started not with code but with design. The mood reference was light, “breathing” sites with a wide grid: we chose a 1520-pixel container instead of the usual 1140-1200 to give the work and the typography room. The brand constants stayed: the logo, the brand blue, the Gotham Pro typeface. We added an accent palette - violet, orange, mint, peach.

An important architectural decision: the design system exists not as a PDF guideline but as a living page right inside the site. It is an internal UI kit that renders real tokens and components from production code: the palette, the type scale, spacing, radii, buttons, cards, forms, accordions. Design and code cannot drift apart: if a token changes in the CSS, it changes in the guideline too. This page never ships to production.

All the tokens live in a single CSS file as custom properties:

:root {
  --c-blue: #0204f5;
  --c-purple: #b535fc;
  --c-orange: #ff642c;
  --c-mint: #85f4c4;
  /* ...type scale, spacing, radii, shadows, easing functions */
}

One file - the single source of truth for the entire look of every one of hundreds of pages.

• Astro - the front-end framework. It builds pages into ready-made HTML ahead of time and by default ships zero kilobytes of JavaScript to the visitor. For comparison: a typical React site carries 100-300 KB of scripts just to boot up.
• Vite - the bundler Astro runs on under the hood: an instant dev server and aggressive optimization of production code.
• TypeScript - every content entity is described by a type, and if the API returns something the template doesn’t expect, the error surfaces at build time, not in front of a visitor.
• three.js - the 3D graphics for the home-page animation. We use it “bare”, without wrappers: less code, higher FPS.
• sanitize-html - a filter for HTML from the admin panel: content from the CMS physically cannot bring a vulnerability onto a page.
• sharp - image processing at build time.
• Laravel + Backpack CRUD - the content API and the admin panel: describe an entity and you get a ready interface with lists, filters and access rights.
• Cloudflare Pages - static hosting on a CDN network: a visitor from Warsaw, Kyiv or New York gets the site from the nearest location.
• GitHub Actions - CI/CD: every change runs through the tests and deploys automatically.
• Sentry - error monitoring on both sides: we learn about a problem before a visitor writes to support.

The key idea: a showcase site should be static. The browser receives ready-made HTML from the nearest CDN server - nothing to render, nothing to wait for. A search bot sees a fully finished page, not an empty container that JavaScript will “paint in eventually”. Static files have no database and no sessions - there is literally nothing to attack.

The whole build - 119 pages in four languages in about 2.5 seconds. And that is only the start: pages are being added all the time - the blog, service landing pages, new case studies.

“Zero JS by default” doesn’t mean “boring”. There are animations, but each one is wired in precisely: the “signal field” on the home page loads lazily and stops off screen; the halftone portraits in the reviews are rasterized right in the browser; scroll reveals and counters are hand-written on IntersectionObserver, without a single library.

The home page is a telling example. At first we integrated a spectacular glass 3D sphere: React, a physics engine, a 3D model. Beautiful but heavy - megabytes of code and WebAssembly physics. We replaced it with the “signal field”: pure three.js without React or physics. Visually we lost almost nothing, and in weight and smoothness we won many times over. Sometimes the right engineering decision is to walk away from something beautiful but expensive in time.

A separate word about languages: the site lives in English, Russian, Ukrainian and Polish - four languages for the first time in the project’s history. Every page exists in four versions with proper URLs, and all of them are built from a single set of components - only the translation dictionaries and the CMS content change.

In a classic CMS the admin panel and the site are one whole: the system both stores the content and draws the pages. In the headless approach the CMS is “beheaded”: it only stores content and serves it over an API - as JSON. Someone else draws the pages - in our case, Astro.

We didn’t throw away what the second version had built up: the Laravel back end stayed, but changed professions - from “a server rendering the site” it became a content API and a Backpack admin panel. It holds ten content types: pages, articles, authors, projects, reviews, clients, services, technologies, job openings and site settings.

The API returns translatable fields as a map of all locales with a fallback (if a Polish text isn’t written, English shows instead), hides drafts, caches responses and answers only to the trusted front-end domains.

The content of complex pages - case studies and services - is not a “wall” of text but an array of typed blocks: facts, text, columns, image, gallery, slider, steps, FAQ, call to action. An editor assembles a page from blocks like a construction kit, and on the Astro side a single shared renderer turns each type into its own component:

{blocks.map((block) => {
  switch (block.type) {
    case 'facts':   return <FactsGrid {...block} />;
    case 'gallery': return <Gallery images={block.images} />;
    case 'steps':   return <StepsTimeline {...block} />;
    case 'cta':     return <CtaBanner {...block} />;
    /* ...text, columns, image, slider, faq */
  }
})}

A content manager gets layout freedom but cannot break the design: every block renders strictly by the design system. And all the HTML from the admin panel goes through a sanitizer: potentially dangerous tags are stripped and even the heading hierarchy is leveled out - so an editor physically cannot ruin the page’s SEO structure. By the way, the page you are reading is built from exactly these blocks.

From an edit in the admin panel to the update in production takes 3-4 minutes, with no developer involved. For the times you don’t feel like waiting, the admin panel has a “Rebuild site” button. This is the JAMstack architecture: the speed and invulnerability of static files plus the convenience of a regular CMS.

A reliability detail: snapshots of API responses are committed to the front-end repository. The site can be built and tested with no back end at all, and a dedicated check compares the snapshot structure with the live API - we learn about a format change from the check, not from a broken production.

For this project SEO was requirement number one for the architecture - we designed for it from the very start.

• Instant HTML delivery: static files from a CDN give the best Core Web Vitals - no server “thinking”, and no JS rendering a search engine would have to execute.
• Exactly one h1 on every page and no skipped heading levels - guaranteed even for content coming from the CMS.
• Canonical, title and description - one of each per page, for every one of the 119.
• Multilingual SEO: every page declares its language versions via hreflang, and the sitemap is generated automatically with all the connections.
• Structured data: a Schema.org graph on every page - Organization, WebSite, WebPage, plus Article, JobPosting, FAQPage, Service, BreadcrumbList, Person. This is what Google builds rich snippets from.
• Honest 404s: without a dedicated file Cloudflare Pages answers non-existent URLs with the home page and a 200 code (a soft 404 search engines punish) - we caught this in an audit and fixed it.
• No page links to itself: the logo on the home page, the active menu item and the current language are not links. Link-graph hygiene almost nobody bothers with.

And the main thing: all of the above is checked automatically. Our own audit script runs over every built page, and no SEO regression slips onto the site unnoticed - zero findings, or the build doesn’t go to production.

Static is static, but requests still have to come in. Forms post directly to the Laravel API: server-side validation, spam protection, résumés go to private storage, and every submission records the user’s page and language.

The back end is covered by a suite of 72 automated tests: the API contract (all locales in place, drafts hidden), CORS, forms, rebuilds, content import. A deploy is physically impossible while even one test is red. The front end has its own guards: a structural SEO audit of every page and a contract check against the API. Production errors are caught by Sentry on both sides.