Hlib.me portfolio site

Product direction, design & build · 2026 · Personal

Here's how and why I built my own portfolio using a self-hosted design system, and not using a website builder.

This site is the case study

Here's how and why I built my own portfolio without using a website builder.

I build online stores for a living, so when it came to my own portfolio, I didn't want to do what I often advise clients against: handing the whole project to a website builder and being limited by its options.

Website builders work well for many people, but they weren't right for me. I wanted full control over each page, including the ability to add a working, clickable version of a solution instead of just a screenshot. The only way to do that is to build and manage everything myself, without a platform setting limits on what a page can be.

So that's what I did. I'll talk about the costs to run it at the end, since that's a fair question for any project like this.

What it had to get right

I made a list of things the site had to do well. The same standards I use for any commercial project. It needed to load in under a second on a phone, show the right preview wherever the link is shared (LinkedIn, Slack, WhatsApp, Telegram, or search results), allow me to publish updates quickly without editing code, display my work and services, make it easy for people to contact me, and host my ecommerce blog.

One rule guided everything: I didn't want any limits. The site's design and features shouldn't be restricted by a tool I don't control.

The design

I created the visual design myself, using Material 3 as a base instead of a template. I followed the same UX principles I use for storefronts and built from there. The site has both dark and light themes, with a color palette that looks good and stays consistent in both, so neither feels like an afterthought.

The site works just as well on phones as it does on desktops, across all common screen sizes. One detail I focused on: on mobile, the navigation sits at the bottom of the screen, within easy reach of your thumb. Top menus look tidy in mockups but are less practical on real devices. Here, the menu is right where your hand naturally is.

Under the hood

The front end uses React, Vite, and TypeScript. For styling, I used Tailwind CSS with my own design system, not a rented or patched theme. When you create your own design language, the tools don't get in the way when you want something specific.

Everything runs on Cloudflare. Pages handles hosting, serverless functions take care of quick server tasks, and there's a database and admin panel behind it all. I won't go into too much detail here. What matters is that these parts are in place. Visitors see fast, static pages, but there's a real application running behind them, not just a standalone front end.

I publish it myself

Every word on the site, including this article, is stored as plain content in a Git repository and edited through the admin panel. The panel is a custom build on Decap, set up to do exactly what I need and nothing I don't. Because the content is in my own repository, I'm not limited by a vendor's dashboard. This means I can publish updates myself in minutes, and every edit is saved and versioned, so the content is always mine and easy to move elsewhere.

Fast on purpose

Speed was a goal from the start, not something I hoped to add later. The whole site is rendered to static HTML ahead of time, so the first thing your phone receives is a finished page rather than a blank frame waiting to fill in. Around that are the things you'd expect when done properly: code splitting so each page only pulls what it needs, anything below the fold loaded lazily, and the hero image preloaded so what you are meant to see first actually appears first.

Images are handled automatically. Anything I upload is processed into different sizes and saved in several formats, including modern WebP. This way, each device gets an image that fits its screen and loads quickly without losing quality.

Fonts and icons are self-hosted in small subsets. This makes loading faster and keeps everything on my own domain. The site performs well: Core Web Vitals scores are strong, and Google's PageSpeed Insights rates it at or near 100 in performance, accessibility, best practices, and SEO.

Correct wherever it's shared

Portfolio links get shared often, so the preview needs to be accurate. Each route is pre-rendered as its own static HTML file at build time, with the title, description, canonical tag, Open Graph data, and JSON-LD included. This finished HTML is what both people and bots receive first. Crawlers use it to build previews, and visitors see the same HTML right away. Then React takes over to make the page interactive and handle navigation, so it works like a normal app without full reloads. The static HTML is the foundation for everyone, and wherever the link is shared: messenger, Slack, or search results. The preview is always correct without anything needing to run first.

The parts you don't see

A handful of outside services quietly do their jobs. Resend handles email, so anything sent through the contact form reaches me immediately; that submission is also kept in the database, and the form is shielded from spam to keep the channel usable. Sentry monitors the visitor's side for errors as they happen, so if something breaks for someone reading the site, I find out immediately what it was and where, and can fix it before the next person encounters it. UptimeRobot watches the site around the clock and pings me the moment it can't reach it. GA4 is wired in as well, so I can see how much traffic comes through, how people move around once here, and where they arrived from. There is also a consent banner that complies with GDPR, so all of that happens as it should.

What it's actually for

Take the engineering away, and the site does three things. It shows the work I've done and the services I offer. It gives anyone who wants to talk an easy way to reach me. And it carries my ecommerce writing, which is the part I keep coming back to add to.

The site's architecture is what makes this possible. Since I own the stack instead of using a builder, my case studies aren't just screenshots and captions. When I redesign an interface or rebuild a flow, I can add a live, clickable version for you to try. That's why I chose this approach. It only works because nothing is limited by a platform.

What it cost

From start to finish, I built and launched the site in about a week.

And the cost, since I promised. For paid services, getting it live and keeping it running, the figure is zero pounds. That number doesn't come from cutting corners. It is a full site, fast, entirely mine, with a real back end, a design system, and a proper way to publish updates, and there is nothing I had to leave out to achieve it.

That's the same approach I use for commercial platforms: figure out what it really needs to do, then build that, and build it well.