Why I Don't Use Wordpress

When I build websites, I'm not trying to chase trends or prove a point. I just want to create things that are fast, secure, easy to maintain, and feel good to use — both for the people building them, and the people browsing them. That's it.

For me, the best way to do that right now is with Jamstack — specifically, using 11ty (Eleventy) for generating my sites, Pages CMS for editing content, and Netlify for hosting, deployment, and a handful of smart features behind the scenes.

I'm often asked why I use this stack instead of WordPress — which is fair. WordPress is everywhere, and it's done a lot of good for the web. But the tools I choose say a lot about how I work, what I value, and who I'm building for. So I thought I'd take a moment to share, in plain language, why Jamstack makes sense for me — and for the people I build for.

This isn't a takedown of WordPress. It's just an honest look at what works for me, and why.

I Like to Keep Things Simple

There’s a quiet beauty in simplicity — not the flashy kind that gets written about in tech blogs or shared as viral tweets. It’s the kind of simplicity that brings a little calm to your workflow, that reduces the number of tabs you have to keep open, and that makes the tools you use feel like an extension of your thinking — not an obstacle to your progress.

When I build websites using Jamstack tools like 11ty, I feel like I’m finally working with the web, not against it. There’s no dashboard fighting me. No plugin bloat clogging up my process. Just clean files, clear structure, and the comforting certainty that what I write is exactly what gets delivered.

Content lives side-by-side with my code, versioned and structured in a way that’s human-readable and future-proof. There’s no middle layer trying to reinterpret what I mean. No WYSIWYG editor overwriting my choices. What I write is what gets built. What I commit is what gets published. It’s honest. Direct. Peaceful, even.

All of it gets stored in version control — usually Git — which means I can see the full history of my site, line by line, moment by moment. If something breaks, I know where to look. If a client wants to undo a change, I can roll back in seconds. There’s no database to rescue. No server logs to trawl through. No debugging mystery conflicts between five different plugins that all want to do the same thing slightly differently.

The output? Clean, efficient HTML files. Static, fast, secure. No layers of abstraction. No server-side processes running behind the scenes that I have to monitor or secure. Just pages, ready to be served instantly from anywhere in the world via a CDN.

And this isn’t just about developer experience — it’s about content people too. Editors. Marketers. Clients. The people who want to make changes without worrying that one wrong click will break the whole site.

That’s where Pages CMS fits in beautifully. It provides a simple, elegant editing experience that lives right alongside the code, but never gets in the way of it. Non-technical team members can log in and see their content laid out in plain English. They can update headlines, swap out images, change copy — all without ever touching Git or Markdown unless they want to.

Because it’s Git-based, every edit becomes part of the project’s history. There’s no guessing about who changed what, or when. No fear of overwriting each other’s work. No messy “draft” versus “published” status juggling. Just honest collaboration — visible, reversible, and built on trust.

There’s something deeply satisfying about that transparency. It creates a sense of shared ownership. Everyone knows what’s going on. Everyone can contribute safely. And because we’re not depending on a fragile admin panel or a labyrinth of plugin interactions, the whole system feels calmer. More resilient. More grounded.

I don’t use these tools because they’re trendy or because I want to prove some kind of point. I use them because they stay out of my way. They don’t demand constant attention. They don’t interrupt my flow. They don’t add layers of unnecessary abstraction to a process that should be simple.

It’s not about trying to be clever. It’s not about showing off how “modern” or “headless” or “API-driven” the stack is. It’s about choosing tools that support the work instead of complicating it. Tools that empower everyone involved — from the person writing the code to the person publishing the blog post — to get on with their jobs without friction.

In a world where digital tools often feel noisy, demanding, and unpredictable, I’ve found that there’s a quiet, meaningful satisfaction in this kind of simplicity. It lets me focus on what matters: the design, the message, the experience. The stuff that lasts.

That’s why I choose Jamstack. That’s why I use 11ty. That’s why Pages CMS has a permanent place in my toolkit. Because simple isn’t just easier — it’s better.

I Need My Tools to Be Reliable

One of the things I value most in my work — and one of the first things clients notice — is reliability. That quiet confidence that when something goes live, it’s going to stay live. That the site you launch today won’t start throwing errors tomorrow. That your content won’t vanish, your styles won’t break, and your visitors won’t be staring at a spinning wheel wondering if the server’s gone on holiday.

To me, reliability isn’t a feature — it’s a mindset. It’s baked into the way I choose tools, structure projects, and build websites from the ground up. It’s not about trying to impress anyone with bells and whistles. It’s about making something that works when it needs to, over and over again, without drama.

That’s why the Jamstack approach makes so much sense.

When I build a site with Jamstack tools like 11ty, what I’m doing is generating static files — good old HTML, CSS, and JavaScript — ahead of time. The site is built once, deployed, and then served to every visitor exactly as intended. There’s no backend system trying to piece things together on the fly. No live rendering that could fail under load. No database calls that might hang, timeout, or break due to a malformed query.

What you see is what you get — literally.

That simplicity at runtime is a huge deal. Because when someone visits the site — whether it’s one person in a quiet moment or ten thousand people during a sudden spike — they’re all getting the exact same thing: a fully rendered, pre-built page served instantly from the nearest edge server. It doesn’t matter if you’re in London, Estepona, or Montego Bay — it loads the same, looks the same, and works the same.

There’s no waiting on a database. No spinning up processes on the server. No hidden dependencies that could bring the whole thing down. And that’s incredibly reassuring — both for me, and for the people I work with.

I host all my projects on Netlify, which adds another layer of confidence to the mix. Netlify doesn’t just serve the site — it manages the entire deployment workflow. Every time I push a change to Git, Netlify spins up a clean environment, builds the site from scratch, and serves it from a global CDN.

That might sound technical, but here’s what it really means: every build is fresh. Every deploy is predictable. There’s no chance of old data lingering in a cache, no risk of two parts of the site getting out of sync. It’s a clean slate each time — and that makes troubleshooting almost nonexistent.

And if something does go wrong (because let’s face it, occasionally something always does), Netlify gives me the power to roll back to a previous deploy instantly. No panicked server restores. No FTP hacks or last-minute database imports. Just one click, and I’m back to the last known good state.

That kind of stability gives clients peace of mind. It gives me space to breathe. I don’t spend weekends wondering if a plugin update will break someone’s homepage. I don’t get urgent messages asking why the contact form stopped working or why the blog looks “different today for some reason.”

It’s not exciting — and honestly, that’s the point.

Reliability isn’t supposed to be thrilling. It’s supposed to be invisible. It’s the feeling of not having to double-check everything before you go to bed. It’s the ability to hand over a site and know — really know — that it’ll still be ticking along beautifully months down the line, whether I’m actively maintaining it or not.

When you work with tools that are predictable and stable, you get to shift your energy away from firefighting and toward creating. You stop building systems just to protect other systems. You start building websites that quietly do their job, day after day.

And in a world that often moves too fast and breaks too much, there’s something incredibly refreshing about that.

So yes — reliability might not get the spotlight in most tech conversations. But for me, it’s everything. It’s the reason I build the way I do, and it’s one of the biggest reasons I’ve chosen the Jamstack path.

Because when things just work, you get to focus on what really matters: the message, the story, the experience — and the people on the other side of the screen.

It's Fast — Like, Really Fast

Performance matters. It’s easy to treat it like a technical metric — something to measure in milliseconds or grade with a Lighthouse score — but at its core, performance is about respect.

When someone clicks on your website, they’re giving you their time. And time is the one thing nobody ever has enough of. If your site loads slowly — if it lags, stutters, or makes people wait — you’re telling them, without meaning to, that their time isn’t worth much. That’s not the message I want to send.

A fast website, on the other hand, shows up ready. It loads quickly, responds smoothly, and invites people in without friction. It feels like a warm, open door. It says: “Come on in — we were expecting you.”

That’s why I care so much about performance. Not because I want to win benchmarks or squeeze milliseconds for sport, but because it really makes a difference.

And that’s one of the biggest reasons I lean into Jamstack — because speed is baked in.

When I build a site using tools like 11ty and host it on Netlify, I’m creating something that’s static by default. That means all the pages are pre-rendered ahead of time — they’re not waiting to be assembled in real time by a backend server. There’s no queue, no delays, no hidden processes trying to cobble together a page from templates and databases.

Instead, everything is built once — cleanly, predictably — and served instantly from a global network of edge servers. No matter where your visitors are in the world, they get the content from the closest point possible. There’s no “sorry, the server is under heavy load right now.” There’s just fast, consistent delivery.

And speed at this level has real-world impact. It means a student in a rural area with limited bandwidth can still access the site quickly. It means someone checking your site on the bus with patchy 4G doesn’t bounce out of frustration. It means people using older devices aren’t excluded because your site chokes on bloated scripts and unoptimised assets.

With 11ty specifically, I get to start with a clean slate. It doesn’t force anything onto my pages. It doesn’t assume I want animation libraries or UI frameworks or JavaScript for every interaction. I decide what goes in, and if I don’t add it, it’s not there. That simplicity is powerful — it means the baseline experience is fast, and any enhancements I include are intentional.

If I want to optimise further — and I usually do — I’ve got complete control. I can lazy-load images, compress assets, structure content responsively, and fine-tune the delivery of every element. And because I know what’s running where, I don’t have to second-guess whether a plugin is injecting scripts or slowing things down behind the scenes.

There’s no guessing with Jamstack. The performance is predictable, measurable, and within my reach.

And here’s the thing: when your site is fast, it’s not just a better experience for your visitors. It’s also easier to support. Fewer things go wrong. You don’t get emails about the site freezing or forms failing to load. You don’t have to explain why things seem fine on your machine but slow on theirs.

It’s not only user experience — it’s developer experience, too. Less firefighting. Fewer support tickets. More time spent building, refining, and improving rather than fixing.

Fast websites are also great for SEO. Google rewards quick-loading pages, and so do your users. But honestly, even if search rankings weren’t affected at all, I’d still care. Because speed is a quality people can feel — even if they don’t have the words for it. A quick site just feels better. It makes a good first impression, and a lasting one.

And in a world full of distractions, popups, autoplaying videos, and sluggish mobile experiences, being the site that just works — instantly and smoothly — is powerful.

So yes, performance matters. It matters because it makes your work more accessible, more inclusive, and more enjoyable. It matters because it reflects how much care you’ve put into the experience. And it matters because people notice — even if they don’t consciously realise why your site feels better than the last one they visited.

That’s why I use Jamstack. Because it lets me build sites that aren’t just fast — they’re thoughtfully fast. And that kind of speed is a form of kindness.

It's a Breeze to Maintain

For anyone who’s ever spent a weekend elbow-deep in a WordPress site — updating plugins, checking changelogs, testing compatibility, and nervously wondering whether clicking “Update” will crash the homepage — I see you.

I’ve been there too. Logging in to find red warning banners, critical update alerts, and plugins that haven’t been touched by their creators in three years. Wondering whether the site’s going to break if I ignore the updates… or break even faster if I apply them. Crossing fingers before hitting the refresh button. Taking backups. Rolling back when something doesn’t play nicely with something else.

It’s exhausting.

And the thing is — it doesn’t feel like building anymore. It feels like babysitting.

There’s this creeping sense that you’re spending more time managing the system than actually improving the site. That instead of growing, creating, refining — you’re locked in an endless loop of maintenance mode. And if you’ve ever had to explain to a non-technical client why updating one plugin crashed a completely unrelated feature, you’ll know just how confusing and frustrating it can be for everyone involved.

That’s exactly why I now build using Jamstack.

Because with Jamstack, the idea of “maintenance” looks completely different. The sites I build are made up of static files — pre-rendered pages that don’t depend on a server runtime or a database. There’s no backend logic executing on every page load, no fragile stack that can fall over with a version mismatch. No plugin soup. No ticking time bombs.

If there’s a bug, it’s in the codebase — not buried in someone else’s plugin. That means I can track it, test it, and fix it like any other part of a clean code project. I don’t need to guess where it came from or rely on a plugin developer’s roadmap to sort it out. The responsibility — and the power — is in my hands.

When clients need to update content, they use Pages CMS, which connects directly to the Git repo behind the scenes. They never touch code. They don’t have to worry about formatting issues or breaking the layout. They click “save,” and Netlify handles the rebuild automatically — in a fresh, isolated environment, with a clean deploy every single time.

No manual uploads. No FTP. No “well, it looked fine on staging…” headaches.

And because the entire project lives in version control, everything is tracked. Every change has a timestamp. Every update can be reviewed. Every mistake can be undone with confidence. There’s no fear. No mess.

What this all adds up to is a radically lower-maintenance workflow — one that frees up hours of time, reduces cognitive overhead, and eliminates a whole category of stress that used to be considered “just part of the job.”

Instead of chasing issues and patching holes, I get to spend my time doing work that actually matters: improving performance, refining UX, enhancing accessibility, adding meaningful features. I get to focus on making the site better — not just keeping it afloat.

And that’s better for me. It’s better for the people I support. And it’s better for the long-term health of the site.

Because at the end of the day, I want to build things that are resilient, thoughtful, and calm. Not fragile machines that need constant handholding just to stay online.

So yes, I’ve chosen Jamstack for a lot of reasons — but this one is a biggie. Because websites shouldn’t need constant supervision to stay useful.

And because I believe maintenance shouldn’t feel like holding your breath.

Netlify Makes Everything Easier

Netlify doesn’t just serve static files — it handles all the things I used to juggle across multiple services, plugins, and late-night Googling. And it does it all in a way that feels… effortless.

When I push my code to Git, Netlify is already listening. It picks up the change, builds the site in a clean environment, and deploys it to a global CDN without me lifting a finger. No SSH into a server. No SFTP file zipping. No breaking out into a sweat wondering if I’ve uploaded the correct .env file or set the right permissions. It just works — calmly, consistently, every single time.

One of the things I appreciate most is the free, automatic SSL. There’s no need to request a certificate, verify ownership, or renew anything manually. HTTPS is simply there. Enabled. Done. And that means I never have to explain to a client why the browser is showing a “Not Secure” warning on their contact page. It’s taken care of before it’s even a question.

Then there’s the preview deployments — and honestly, this alone has saved me hours of awkward back-and-forth. Every time I open a pull request or push to a branch, Netlify spins up a unique preview URL. That means I can send a client a link and say, “Here’s what the change will look like. What do you think?” before anything ever hits the live site.

No staging server to sync. No version confusion. No guessing.

When something goes wrong (because life happens), Netlify gives me instant rollbacks. Not a “restore from backup” situation that takes half an hour. I mean click a button, and the whole site is back to its previous working state. It’s like having an undo button for production — and there’s real peace of mind in that.

Need to build a contact form? Netlify Forms has me covered. I can write a standard HTML <form>, slap on a netlify attribute, and I’ve got submissions streaming into my dashboard without writing a single line of backend code. No WordPress plugins. No third-party JavaScript. Just simple, semantic markup doing its job.

And when I do need something a little more dynamic — like processing a payment or sending data to an API — I can use Netlify Functions. These are little bits of serverless logic that live right next to my site, deploy with it, and scale automatically. They don’t require setting up a full Node server or provisioning anything manually. Just drop in a file, write the function, and it’s live.

It’s all there, quietly running in the background, like the infrastructure equivalent of a well-packed toolbox. Not flashy. Not loud. Just reliable, thoughtful, and helpful.

And that’s what I love most about Netlify. It’s not trying to be a walled garden. It’s not reinventing workflows just for the sake of it. It’s built to work the way I already work — with Git, with modern tooling, with sane defaults and smart automation that make my life easier without asking me to change everything.

It respects my process. It respects my time. And most of all, it gives me the confidence that I’m handing over sites that aren’t just built well — they’re deployed and supported on infrastructure that’s just as solid.

So yes, there are other ways to host static sites. But once you’ve used Netlify, you realise it’s not about hosting at all. It’s about removing friction, giving you superpowers you didn’t know you needed, and making your work — and your clients’ experience — better in dozens of quiet, meaningful ways.

It Feels Good to Use

This might sound soft, but it matters: I genuinely enjoy working with this stack.

Not in a flashy, over-engineered, “look how clever this is” way — but in a way that feels honest. Grounded. Capable. Like working with a set of tools that respect my time and help me do my best work, quietly and reliably. Tools that I can rely on, that I can take pride in handing over. Tools that let me focus on the craft — not the chaos.

There’s a kind of quiet confidence that comes from using technology that’s transparent and well-behaved. When I build a site with 11ty, hook it into Pages CMS, and deploy with Netlify, I’m not bracing for a surprise. I’m not second-guessing whether a plugin conflict will appear overnight or whether something obscure in the backend is going to cause an issue three months down the line. I’m working in a stack that gives me room to think, space to create, and control over the outcome.

And it’s not just me who feels that difference — clients do too. Whether they’re tech-savvy or not, they notice the change in energy. They can update content without fear of “breaking something.” They don’t feel intimidated when they log in. The interface is clean. The workflow is clear. Their changes go live quickly, without needing to schedule a call or open a support ticket.

There’s no convoluted dashboard with layers of settings. No confusing roles or permission walls. No frustration at having to click through six menu items just to edit a headline. Just a straightforward way to manage their content, backed by a workflow that’s designed for clarity, not control.

That kind of simplicity breeds confidence. And when clients feel confident in their tools, something shifts. They start publishing more. Updating more. Experimenting without hesitation. They become more invested in the site because they trust it — and that trust builds a stronger partnership between us.

It also reduces stress across the board. I’m not spending my time fixing things that shouldn’t be broken. They’re not spending their time trying to learn a system that was never designed for them in the first place. Instead, we’re focused on what matters — content, design, strategy, growth.

When the tools support the people using them — instead of becoming obstacles — everyone wins.

This stack has changed how I feel about building for the web. It’s taken the friction out of development, removed the anxiety from handover, and replaced all that hidden complexity with something lean, clear, and human.

It’s not the most “popular” setup. It’s not filled with hype. But it works. It feels good to use. And to me, that’s one of the strongest signs I’m on the right path.

Because when something is genuinely enjoyable to build with — when the experience of making it is as solid as the thing you’re making — you can feel it in the final result. And so can everyone who uses it.

It’s Not New — It’s Just Sensible

One of the things I sometimes hear when I talk about Jamstack or tools like 11ty is:
“Isn’t that a bit... new?”
Or: “Is this stable enough for production?”
Or my favourite: “It sounds cool, but I’d rather wait until it’s more proven.”

And I get it. The tech world is full of shiny, short-lived distractions. There's always another framework, another "game-changer", another stack promising to reinvent everything — and then quietly disappearing six months later. It's perfectly healthy to be sceptical.

But here's the thing: Jamstack is not new.

It's not experimental. It's not a startup in beta. It's not some bleeding-edge gamble that only early adopters understand.

Jamstack is an evolution of proven, well-established web development practices — not a revolution. It takes what’s always worked about the web (HTML, CSS, JS, static files, version control) and repackages it into something that is faster, safer, and simpler to maintain. That’s not hype. That’s progress with perspective.

The core principles behind Jamstack — pre-rendering, decoupling front-end from back-end, serving static assets from a CDN — have been around for decades.

In fact, before WordPress and dynamic CMSs took over, this was how websites were built. You’d write HTML and CSS by hand, upload it via FTP, and it would just… work. What Jamstack does is bring modern tooling, automation, and scalability to that old-school reliability.

There’s nothing exotic here. No proprietary engines. No black box platforms. Tools like 11ty generate plain, readable HTML. Git-based CMSs like Pages CMS integrate cleanly with your workflow. Hosting on Netlify means using standard protocols, open formats, and well-documented APIs.

And when I say these tools are mature, I mean it. 11ty is backed by a thriving open-source community and maintained by people who care deeply about accessibility, performance, and transparency. Netlify is a well-funded, established platform used by hundreds of thousands of developers globally. Pages CMS builds on open standards — it’s not building its own walled garden.

This isn’t a fragile ecosystem. It’s rooted in the open web.

It’s Trusted by Major Brands

Let’s look at who’s using it — not just indie developers or portfolio sites, but household names:

• Unilever, one of the largest consumer goods companies in the world, uses Jamstack architecture across brand sites to simplify infrastructure and improve performance at scale.
• Nike and other retail giants use static-first builds for product campaigns and high-volume landing pages where reliability and speed are non-negotiable.
• Stack Overflow — a site that knows a thing or two about developer needs — uses Jamstack principles for its documentation and microsites, because versioned, Git-based content is easier to trust and track.
• Smashing Magazine moved from WordPress to Jamstack with Hugo, Netlify, and headless CMS — and publicly reported lower costs, better uptime, and dramatically improved loading speeds.
• Lego, Louis Vuitton, Peloton, Figma, and even government organisations now use Jamstack architectures — often behind the scenes — to power key digital properties.

This isn’t a movement stuck in the startup or side-project phase. It’s powering enterprise-scale digital experiences. Why? Because the architecture scales gracefully, is less prone to downtime, and supports better developer workflows than monolithic CMSs.

Another reason I trust this stack: it’s open.

The tools I use aren’t locked behind paywalls or tied to one vendor’s whims. 11ty is MIT licensed. Pages CMS is open source. Even Netlify has transparent pricing and integrates with anything that speaks Git.

And because everything lives in version control, there’s no hidden configuration, no “mystery sauce” making things work. What you see is what you get — in the most literal and empowering sense. That means:

• I can export or migrate a project at any time.
• I can audit every change.
• I can deploy to a different host if needed (Cloudflare, Vercel, AWS S3 — all options).
• I’m not locked in.

That’s the kind of technical freedom and long-term peace of mind that proprietary CMS platforms just can’t offer. With Jamstack, I’m building on solid, transferable skills. It’s not a walled garden; it’s a foundation.

So, Why Don't I Use WordPress?

It’s not that I have anything against WordPress. In fact, I have a lot of respect for it.

WordPress has done an enormous amount of good for the web. It’s helped millions of people get online — people who might never have launched a site otherwise. Bloggers. Non-profits. Artists. Startups. Teachers. Local businesses. It opened the door and said, “You don’t need to know how to code to have a voice online.” And that’s powerful.

It’s been around for a long time, and for good reason. The ecosystem is vast. There are plugins for everything. The themes market is rich. It powers publications, stores, communities — even entire businesses. And for some situations — WordPress still makes sense. It’s built to handle that world, and with the right people maintaining it, it can absolutely shine.

But for the kinds of sites I build — marketing sites, portfolios, campaign pages, small business websites— that level of complexity feels unnecessary. More than that, it feels heavy. It slows things down. It introduces a level of fragility that I don’t want to carry forward into a handover, or support long-term.

I’m not managing a newsroom or building an eCommerce empire. I’m helping clients communicate clearly, publish confidently, and grow without fear of their website becoming a liability. And for that, WordPress often gives me more moving parts than I need.

There’s the regular plugin updates, the background maintenance, the reliance on a database, the risk of conflicts, the vulnerability footprint. There’s the learning curve for clients. The stress of staging and live environments. The uncertainty that creeps in when you know a single unchecked plugin could quietly break the whole thing next week.

I’m not saying that can’t be managed. It absolutely can — and many developers do it beautifully. But I’ve asked myself: Is this really the best tool for the job I’m doing? And for me, the answer is no.

Jamstack is the better fit.

It’s lighter. It’s cleaner. It removes the layers of abstraction and lets me work directly with the essentials: code, content, and creativity. There’s no backend to babysit. No CMS interface to debug. No plugin labyrinth to navigate.

It’s dependable in the best way — the kind of dependable that lets me hand a site over and know, deep down, that it’s going to keep running without drama. It doesn’t require my constant attention to stay healthy. It just works.

And it’s empowering — not just for me, but for the people I work with. Content editors can update pages through Pages CMS without fear. Clients can see changes live without waiting. Teams can collaborate via Git without stepping on each other’s toes.

Most importantly, Jamstack lets me focus on the work itself. The writing. The layout. The experience. The message. The craft.

I’m not trying to wrestle a system into submission. I’m just building the best site I can, with tools that support that process instead of complicating it.

So no — this isn’t about choosing sides. It’s not WordPress vs. Jamstack. It’s about recognising the kind of work I do, the way I like to work, and the experience I want to deliver — and picking the tools that align with that.

Jamstack fits the way I think. The way I create. The way I care for the things I build as a freelancer.

And that’s what matters most.

You're Welcome Here

If you’re reading this because you’re curious — wondering whether there’s another way to build for the web, or whether there’s a simpler, calmer approach to doing the work you do — then I’m really glad you’re here.

You don’t need to be a developer. You don’t need to know Git commands or write JavaScript in your sleep. You don’t need to explain why the tech you’ve used in the past didn’t quite work for you.

There’s no gatekeeping here. No jargon. No judgement. Just real-world tools that are built to be understandable, sustainable, and friendly — for creators, marketers, small teams, freelancers, and anyone else who’s just trying to make something that works.

Jamstack isn’t some elite club. It’s not about being clever or doing things the “cool” way. It’s about removing the unnecessary friction from publishing online. It’s about giving you control without overwhelming you with configuration. It’s about creating websites that feel strong, clear, and honest — not because they’re packed with features, but because they’re built with intention.

For me, Jamstack has made the web feel like home again. A place where I can build freely, ship confidently, and collaborate without hassle. A place where the tools support the work instead of becoming the work.

If you want to see what that looks like in practice, I’d be happy to show you. If you have questions — about tools, setup, workflows, or whether this stack would work for your next project — I’d love to talk it through with you.

There’s no hard sell. No pressure. Just real conversation. And honest answers.

This way of working isn’t just about faster sites or cleaner code. It’s about building digital things in a way that feels better — for you, for your team, for your clients, and for your visitors.

I use Jamstack because it makes sense — and because it helps me as a freelance web designer build websites that do, too.