Why I moved from Framer to Astro after three years of client sites

For about three years, almost every website I made started on an empty Framer canvas. Client sites, mostly, and the templates I make under Anabios. I’d pick a typeface and push frames around until the page felt right.

These days I start in a terminal. This site is built with Astro, and I make most of it by describing what I want to a coding agent. I didn’t plan the switch, and I still like Framer a lot. What changed was how quickly I can work in code now, and I want to write down how that happened and what it cost me.

What Framer gave me

Most designers know the gap between the file they hand over and the site that actually ships. Spacing drifts, an easing curve gets lost somewhere, and you spend days going back and forth trying to get it back.

Framer closed that gap for me. It let someone who thinks in layouts and type put a real website on the internet, with breakpoints, interactions, a CMS and hosting all coming from the same canvas I was designing on. For client work that mattered a lot. I could send a live link instead of a mockup and change things while we were still talking.

It’s also where Anabios came from. Making templates taught me a lot about structure, because a template has to make sense to a stranger who opens it for the first time and wants to make it theirs. Anabios still makes Framer templates, and I still think Framer is the right tool for a lot of people.

When code caught up with the canvas

I stayed visual for so long because of speed. Writing a site by hand was always possible, but it was slow for me. I could finish a whole section in Framer in the time it took me to look up how grid columns span.

Coding agents changed that. Now I describe a section the way I’d describe it to a developer friend: the layout, the spacing, what it does on a phone, how the hover should feel. Soon after, there’s a component in my project. I check it in the browser, and if something’s off I say so and it gets fixed. The loop feels a lot like working on a canvas, except what comes out is code I can read and keep.

I expected to hit a point where going back to Framer would be quicker. For the kind of sites I make, I mostly haven’t. And once speed stopped being the deciding factor, the other differences started to matter.

The biggest one is ownership. My site has a small design system underneath it: tokens, components built from those tokens, and compositions that arrange the components into pages. It all lives in files in my project, styled with Tailwind CSS 4. When I change a token, the change shows up everywhere it’s used, and I can read exactly what moved. Because it’s all text, it lives in git too, so every change has its own small written history.

Then there’s everything around the pages. I wanted an RSS feed, so the site has one. I wanted a sitemap, so it has that too. If I want to pull something from an API at build time or wire in some odd little tool, there’s no list of supported integrations to check first. A visual builder gives you a very good room to work in, and most of the time the room is enough. Every so often, though, I wanted a door where there wasn’t one, and the answer was a workaround or letting the idea go.

The bill that almost disappeared

The money side surprised me more than I expected. Astro builds the site into static HTML: a folder of pages, styles, fonts and images, with almost no JavaScript. Nothing has to run on a server when someone opens a page, because the file is already sitting there, ready to be sent.

So npm run deploy does two things. Astro builds that folder, and Wrangler (Cloudflare’s command line tool) uploads it to Cloudflare Workers, which serves it as static assets. The hosting part of the config is this short:

{
  "name": "jamik",
  "assets": {
    "directory": "./dist"
  }
}

There’s no database to back up and no server to keep alive. Serving plain files is about the cheapest thing you can ask of a network like Cloudflare’s, and for a personal site or a small one, the cost lands close to nothing.

Framer works differently, and fairly so. You pay per site, and that plan pays for hosting and for a platform that does a lot of work on your behalf. For one important site, that’s a reasonable deal. It gets heavier when you have several sites going at once.

That matters to me because, besides my job as Lead Product Designer at Mutolaa, I build small independent apps and tools, and each one tends to want a page of its own. Now a landing page for a tiny experiment is one more folder and the same deploy command, so I make them without thinking twice about the cost.

What I gave up, and who should stay

I miss the canvas. Describing a layout in words is fast, but it’s a different kind of thinking from grabbing something and nudging it until it sits right. When I’m still figuring out what a page should even be, my hands are better at it than my sentences.

The bigger loss is for clients. With a Framer site, I could hand it over and the client could change a headline or swap a photo on their own. With an Astro site, editing text means editing a file. That’s fine for me. For a bakery owner who just wants to update the opening hours, it’s a bad trade.

The CMS is the other thing. Framer’s is really nice to use: you make a collection, fill it in, and the pages exist. I write my posts in MDX now, which I like a lot, but each one is a text file with a few lines of frontmatter on top. You can connect a headless CMS to Astro, and plenty of people do, but then you’re setting up and looking after something Framer simply gave you.

So if you build sites for clients who’ll edit them on their own, I’d honestly tell you to stay on Framer. Same if you love working visually and your sites fit comfortably within what Framer does well, which is a lot of sites. Code starts to pay off when you want to own every part of the thing, or when you’re running enough small sites that per-site plans begin to add up.

My guess is that the line between these two ways of working will keep getting thinner, and that one day I’ll drag a section around on a canvas and get clean code I own on the other side. Until then, this post is an MDX file sitting in a folder next to the rest of the site, and when it’s ready, publishing it will be the same npm run deploy as everything else.