A couple of years ago, when I was deciding which platform to use for web development projects, I was very keen on the idea of using Webflow. It felt like the perfect bridge between the beginner-friendly page builders I'd been using, like Elementor, and the more professional development tools that followed the genuine web development principles I was learning at the time.
To get started, I used it to build my first portfolio website. There was a slightly steeper learning curve than I was used to, but it quickly became a solid tool to work with. Its component and class systems encouraged a much more structured approach to building websites, and many of those principles have stuck with me ever since.
At the time, I intended it to be a site I would update regularly. I'm sure this will sound familiar to anyone with their own portfolio though, this never really happened as I became too busy with client and freelance work.
As time went on, it became harder to justify Webflow's annual cost of around £300 just to keep a portfolio site online, especially when I wasn't making the most of the platform.
Over the past year, I've predominantly been building websites with WordPress using my own custom starter theme that I learned from my agency work, so rebuilding the site that way seemed like the obvious choice.
However, around the same time, I kept coming across discussions on LinkedIn and Reddit about Astro and the JAMstack approach. The idea of building lightweight, flexible websites that were fast by default and designed around modern development practices really appealed to me.
Rather than simply rebuilding my portfolio, I decided to treat it as a learning exercise. It was the perfect opportunity to explore a new way of working, see whether it lived up to the hype, and find out if it was something I could see myself using for future projects.
Here's what I built with and what I learned along the way.
Why I chose Astro
One of the things that attracted me to Astro was its focus on keeping websites as lightweight as possible. Rather than shipping large amounts of JavaScript to the browser, Astro generates static HTML and only loads JavaScript where it's actually needed.
For a portfolio site, that makes perfect sense. Most of my pages are content with the odd interactive element, so there's no need to send hundreds of kilobytes of JavaScript just to display some text and images.
I also found the developer experience refreshingly simple. The file-based routing is easy to follow, components feel familiar, and because everything is built around static pages, it's surprisingly straightforward to reason about.
I should point out that I wouldn't use Astro for everything. If I were building a highly interactive web application I'd probably look elsewhere. But for marketing websites, portfolios and brochure sites, I can definitely see why it's becoming so popular.
Building a better CMS
Coming from WordPress, I naturally compared Sanity with Advanced Custom Fields. I've used ACF on pretty much every WordPress project I've built. It's an excellent plugin and gives you far more control over your content than WordPress does on its own. But at the end of the day it's still a plugin sitting on top of WordPress.
Sanity approaches things differently. Rather than adapting an existing CMS, you're defining exactly what your CMS should look like.
For this project I've built a simple page builder made up of reusable content blocks. Hero sections, testimonials, card grids, call-to-actions — they're all individual components that can be arranged in whatever order I need. If I want to add another block later, I just build it once and it's available across the whole site.
It feels much closer to building software than configuring a CMS, and I actually found myself enjoying that part more than I expected.
A cleaner workflow
With WordPress my workflow usually involved making changes locally, uploading files over FTP, checking everything on staging and then pushing the changes live. Even then, you're never quite testing exactly what the client is using because so much of WordPress lives in the database.
This setup feels much cleaner. I make my changes locally, commit them to GitHub, and Vercel takes care of the rest. A minute or two later the new version is live.
The same applies to content. When I publish something in Sanity, Vercel automatically rebuilds the site, so there's no manual intervention needed from me. It's one of those things that sounds fairly minor until you've used it for a while, then you wonder why you ever did it differently.
The token system
One part of this rebuild that I'm particularly pleased with is the token system.
If you've not come across design tokens before, they're essentially the values that define a design system - colours, typography, spacing, border radius, shadows and so on. Normally those values live in your CSS, which means the design and the code can slowly drift apart over time.
Instead, I've got a single JSON file that acts as the source for everything. Using Token Studio, those values are pulled straight into Figma, while a small script converts the same file into CSS custom properties for the website.
The result is that Figma and the code are always using exactly the same values. If I change a brand colour, update a font size or tweak the spacing scale, it updates everywhere.
It's a small thing, but it removes a surprising amount of repetition. When I start a new client project, I create a new token file with their brand values, run the script, and the entire theme updates almost instantly.
Would I use this for client work?
What I've built is a solid foundation. Astro, Sanity, a reusable page builder, responsive components and the token system all work well together, and the next step is to build it out as a reusable theme I can offer to future clients. At the moment, however, it's still a personal project rather than something I'd immediately use for every client. There are already parts of it that I prefer over my WordPress starter theme. Sanity gives me much more control over how content is structured, the deployment process is cleaner, and the token system makes setting up a new project much quicker than it used to be.
At the same time, my WordPress theme has been through real client projects. I've run into the awkward edge cases, solved unexpected problems, and gradually refined it into something I know I can rely on. This new stack hasn't had that opportunity yet.
That doesn't put me off using it. If anything, it makes me more interested to see how it performs on a real project. If the right project comes along, a client who's happy to work through a new process with me, then it’s certainly something I’ll consider.
Top comments (1)
I enjoyed the honest comparison. One thing I’d still be curious about is how this stack holds up after 10–20 client projects. It’s easy to love a new stack on a portfolio site; long-term maintenance, client edits, and unexpected requirements are usually where the real strengths and weaknesses show up.