From Wix to Our Own Platform — Why We Rebuilt Our Website

This post is a retrospective. Not a sales pitch, not a "Wix is bad" rant. Wix served us well when we needed a web presence quickly. But at some point, the solution no longer fit the problem. So we rebuilt the website. This is the story of what went well, what went wrong, and what we learned from it.

Why Wix Was the Right Choice at the Start

When Just Tech Solutions GmbH was founded in 2022, we needed a website. Fast. We were a small team that wanted to spend its time on client projects, not on our own homepage. Wix was the obvious choice: drag-and-drop editor, hosting included, SSL certificate included automatically, domain management integrated. Within two days, the site was live. That was exactly what we needed.

And for a while, it worked well. The site was online, it looked decent, and we could focus on what we had been founded to do: build technology for DAOs.

The Problems That Accumulated

The rethinking did not begin with a single event but with a growing list of irritations. Let me list them in the order they became critical.

Problem 1: Performance. We had a simple company website with five subpages. No shop, no CMS, no dynamic content. Yet Wix loaded over 3 MB of JavaScript, CSS, and fonts on the first visit. The Lighthouse performance score was 42 out of 100. For a company that offers professional web development, this was embarrassing. We were telling our clients to care about performance while our own site loaded slower than some web games.

Problem 2: Vendor lock-in. When we wanted to restructure the site's content, we realized how deeply we were locked into Wix. There was no export button. No "here is your HTML, have fun." Everything — text, images, page structure — existed only within the Wix editor. Even a simple text export required manual copy-paste. For a company that talks about decentralization and sovereignty every day, it was rather ironic that our own website was trapped in a proprietary system.

Problem 3: GDPR compliance. This was the point that concerned us the most. Wix loads tracking scripts by default, Google Fonts from external servers, and various third-party resources. Some of this can be turned off, but not all of it. The General Data Protection Regulation requires that personal data only be transferred to third parties with consent. With Wix, we never had full control over what data flowed where. So we needed a cookie banner that asked for consent — for data transfers we did not actually want in the first place.

Problem 4: HTML quality. A look at the source code of a Wix page is instructive — in a negative sense. Nested divs without semantic meaning, inline styles across dozens of layers, auto-generated class names like _2sDMM and _1Q9if. For accessibility, SEO, and maintainability, this is a nightmare. Screen readers struggle with markup that has no semantic structure. Search engines can barely follow the page hierarchy. And when a developer reads the source code, they see nothing that helps them.

The Decision

In November 2025, we made the decision: we would build the site ourselves. The requirements were clear:

First: maximum performance with minimal overhead. The site has static content — it does not need React, Vue, or any framework that interprets JavaScript at runtime. Second: complete control over every byte sent to the browser. No hidden tracking scripts, no external font servers, no third-party cookies. Third: clean, semantic HTML that is accessible, maintainable, and version-controlled. Fourth: GDPR compliance without a cookie banner, because there is simply nothing that requires consent.

The Tech Stack

After an evaluation phase, we settled on the following stack:

Vite as the build tool. Vite offers fast hot module replacement during development and an optimized production build with tree shaking, code splitting, and asset optimization. For a static site, Vite is ideal because it sticks to the essentials without bringing the complexity of a full-stack framework.

TypeScript for the few interactive elements. The website barely needs JavaScript — the mobile navigation menu, a scroll behavior in the header, perhaps a contact form in the future. But even for little code, TypeScript is worth it: type safety prevents errors, IDE support speeds up development, and the code partially documents itself.

Tailwind CSS for styling. Tailwind was a deliberate choice. The utility-first philosophy means that only the CSS classes actually used end up in the production build. No unused CSS ballast, no overriding framework defaults. And the design tokens — colors, spacing, font sizes — enforce consistency without us having to build a custom design system.

Static HTML for the pages themselves. No template engine, no static site generator, no CMS. Every page is a handwritten HTML file. That sounds old-fashioned, and it is. But for a site with fewer than twenty subpages, it is the simplest solution with the lowest complexity. If the site grows, we can always introduce a generator later. But we add complexity only when it is needed — not prophylactically.

The Results

The numbers speak clearly.

Total size of the deployed site: 444 KB. That is the complete website — HTML, CSS, JavaScript, fonts, everything. For comparison: the Wix version loaded over 3 MB on the first page view of the homepage alone. That is a reduction by a factor of seven.

Lighthouse score: 100 in Performance, 100 in Accessibility, 100 in Best Practices, 100 in SEO. Not because we optimized for Lighthouse scores, but because a clean, semantic site without bloat delivers these scores as a byproduct.

External requests: Zero. The site loads no external fonts, no analytics scripts, no third-party resources. Everything is served from our own server. And that is why we do not need a cookie banner: there are no cookies that require consent.

First Contentful Paint: Under 0.5 seconds on an average mobile connection. The Wix version was over 2 seconds.

What Was Harder Than Expected

Honesty is part of a good retrospective. So here is what cost us more time than planned.

Bilingual support. The website exists in German and English. On Wix, this was a feature — press a button, done. Without a CMS, we had to maintain every page twice. The hreflang tags, the canonical URLs, the language switchers — none of this is rocket science, but it is manual work that repeats with every new page. In retrospect, a minimal templating approach would have saved time here.

Self-hosted fonts. Loading Google Fonts from external servers is problematic from a GDPR perspective. So we self-hosted the fonts. The subsetting — including only the glyphs we actually need — and optimizing the font loading strategy required surprisingly much research and testing. The result is good: fonts load quickly and without layout shift. But the path there was more involved than "download font and include it."

Content migration. Since Wix offers no structured export, we manually copied every text, converted it to clean HTML, and revised it at the same time. This was the right decision — the content needed revision anyway — but it pushed the timeline by about a week.

What Was Easier Than Expected

Deployment. The site is deployed via a simple CI/CD pipeline: push to the main branch, build is triggered, static files are copied to the server. No container orchestration, no Kubernetes, no serverless. A static site needs none of that. The entire deployment process takes under thirty seconds.

Accessibility. We had feared that accessibility requirements would cause a lot of extra work. In practice, the opposite was the case. Semantic HTML — that is, <nav>, <main>, <article>, <header> instead of <div class="_2sDMM"> — is already the biggest step toward accessibility. ARIA labels in the right places, a skip link, sufficient color contrast — this is craftsmanship, not rocket science. The effort was minimal, the result a perfect accessibility score.

Maintainability. The entire source code of the website lives in a Git repository. Every change is traceable, every version is recoverable. Code reviews for content changes sound excessive but are very valuable in practice: typos, broken links, and inconsistent phrasing are caught in review before they go live.

Lessons Learned

First: start with a website builder if you must. Wix, Squarespace, Webflow — these tools have their place. If you need a website in two days and your core business lies elsewhere, a builder is the right choice. We do not regret our time on Wix.

Second: know when the builder is no longer enough. Performance, privacy, control — when these points become relevant to your business, the time to switch has come. Do not wait until there is a crisis.

Third: the simplest solution is often the best. Static HTML with Tailwind and Vite is not an exciting architecture. There is no conference talk you can give about it. But it works, it is fast, it is maintainable, and it solves the problem. Technology should serve the purpose, not the resume.

Fourth: GDPR compliance is easier without third parties. The easiest way to get rid of a cookie banner is to not set any cookies that require consent. And the easiest way to get there is to not load any third-party scripts. This is not a technical trick — it is a design decision.

And fifth: measure the result. 444 KB instead of 3+ MB. Lighthouse 100 instead of 42. Zero external requests instead of dozens. No cookie banner instead of one that annoys visitors. These numbers are not an end in themselves, but they are a good indicator that the decision was right.

The website you are reading this on is the result. It is not perfect — the manual bilingual maintenance is a compromise we will resolve eventually. But it is fast, it is clean, it is ours, and it does exactly what it is supposed to do. Sometimes that is enough.