Why I moved from Framer to Astro, Sanity, Vercel, and OpenClaw
Intro
A practical story about leaving an all-in-one website builder for a more flexible, lower-cost, agent-friendly stack.
Intro
For a while, Framer was the right tool for my website.
It let me move quickly, publish fast, and stay close to the visual side of the work. As someone with a design background, that mattered a lot. I care deeply about how interfaces feel, and I still get a lot of joy from hand-crafting design details rather than accepting whatever a tool generates by default.
But over time, the trade-offs became more obvious.
I wanted a setup that was cheaper to run, easier to maintain in a more programmatic way, and flexible enough to support a site that could evolve with me. That led me to a stack built around Astro + Sanity + Vercel, with OpenClaw acting as the operational layer that helps me actually build and maintain the site.
This article is the story of that switch: why I made it, what I gained, what became harder, and why I think this setup makes sense for designers and creators who want more control without signing up for unnecessary complexity.
Image note
Placeholder for future image: Hero image comparing Framer vs Astro/Sanity/Vercel, or a screenshot collage of the new site and workflow tools
Why I wanted to leave Framer
Framer is great at reducing friction. That’s exactly why a lot of people love it.
You can design visually, publish without much setup, and avoid a lot of infrastructure decisions. But the same abstraction that makes it convenient can also become the reason you outgrow it.
In my case, there were three main reasons.
1. I wanted hosting costs closer to zero
The first reason was simple: cost.
Paying around $30/month for a personal site is not outrageous, but it starts to feel expensive when your actual needs are relatively lightweight. My site did not need some huge dynamic backend or a heavy app infrastructure. It mainly needed to be fast, stable, content-friendly, and visually polished.
With Astro + Sanity + Vercel, the cost profile changed dramatically. For my use case, it is effectively near zero. That alone made the switch worth seriously considering.
This is one of those decisions that feels small month to month but meaningful over time. If a simpler, more flexible architecture can deliver the same or better outcome at a fraction of the cost, that is not just a technical optimization. It is a better system.
2. I wanted maintenance to work with agents, not against them
The second reason was operational.
I did not just want a site that looked good. I wanted a site that was easy to maintain with the help of AI agents inside OpenClaw.
This is where visual website builders can become awkward. They are often optimized for direct human interaction through a polished UI, not for agent-based workflows that operate on files, components, structured content, and repeatable logic.
Once the site became code-based, OpenClaw became genuinely useful in day-to-day work. An agent can:
- inspect component files
- update content structures
- help refactor layouts
- write documentation
- draft articles
- summarize references into Obsidian
- support publishing workflows
- help maintain consistency across the site
That kind of maintenance is much easier when your site is expressed as code and content models rather than locked behind a visual layer.
3. I wanted Sanity-level flexibility for content
The third reason was flexibility.
Framer is convenient, but I wanted a content system that gave me more control over structure, reuse, and future growth. Sanity gives me that.
Instead of treating content as something attached to a page builder, Sanity lets me model content as structured data. That means I can shape schemas around how I think, publish, and organize—not just around what a template expects.
This matters more over time than it does on day one.
At first, a simpler CMS can feel easier. But as soon as you want richer content relationships, reusable blocks, custom editorial workflows, or a site that may eventually power more than one front end, structured content becomes a major advantage.
Image note
Placeholder for future image: Architecture diagram showing Astro frontend, Sanity CMS, Vercel hosting, and OpenClaw assisting the workflow
Why this stack made sense
The more I thought about it, the more this stack felt like a clean separation of concerns.
- Astro handles the front end and performance
- Sanity handles structured content
- Vercel handles deployment and hosting
- OpenClaw helps me build, maintain, and evolve the system
- Figma remains the source of visual direction and design thinking
That division is important. Instead of one tool doing everything moderately well, each part of the system does one job very well.
Astro: a good fit for a content-heavy site
Astro made sense because my site is fundamentally content-first.
I care about speed, clean markup, and the ability to compose pages from components without carrying unnecessary frontend complexity. Astro is especially strong for sites where most of the value is in content, presentation, and performance rather than heavy client-side interactivity.
A few things I like about Astro:
- it produces very fast static output by default
- it keeps JavaScript lightweight unless you truly need interactivity
- it feels clean and readable when building component-based pages
- it supports a workflow that is easy for both humans and agents to reason about
That last point matters a lot. A codebase that is legible is easier to maintain, easier to extend, and easier to hand off to an agent for focused tasks.
Sanity: the flexibility layer
Sanity is what made the setup feel future-proof.
It gives me control over content modeling in a way that feels much closer to designing a system than filling out a CMS template. I can define document types, fields, relationships, and editorial structures that match how I actually want the site to grow.
That is especially valuable for a personal website that is doing more than one thing. A site might include:
- articles
- case studies
- project pages
- experiments
- homepage modules
- reusable callouts
- references and quotes
As that ecosystem grows, the ability to structure content intentionally becomes a real advantage.
Vercel: simple deployment without distraction
I wanted deployment to be boring in the best possible way.
Vercel gives me that. The integration with modern frontend workflows is smooth, deployment previews are useful, and for a site like mine the hosting cost can remain minimal.
That means I can spend my energy on design, writing, and system quality instead of server maintenance.
OpenClaw changed the practicality of the stack
One of the biggest reasons this setup clicked for me is that OpenClaw makes a code-and-content workflow more usable in daily life.
Without that layer, the stack would still be good. With OpenClaw, it becomes much easier to sustain.
This is the difference between a technically nice setup and an operationally pleasant one.
What OpenClaw helps me do
Because the site lives in files, schemas, and components, an agent can work with me at multiple levels.
For example, OpenClaw can help me:
- draft or revise content
- summarize source material into notes
- generate first-pass components or page sections
- clean up repetitive edits across files
- document decisions and workflows
- inspect the codebase and explain how things are wired
- support maintenance tasks that would otherwise create small but constant friction
This is where the stack becomes more than the sum of its parts.
I am not only choosing tools based on what I can do manually. I am also choosing tools based on how well they collaborate with agents.
That is a meaningful design constraint now, and I think more people will start making similar decisions.
Image note
Placeholder for future image: Screenshot of OpenClaw assisting with site files, content drafting, or repo maintenance
I still use Figma because design is not something I want to outsource completely
This part matters a lot to me.
I did not move away from Framer because I stopped caring about visual design. Quite the opposite. I moved because I wanted a setup where I could keep a strong hand in the design direction while gaining more technical flexibility.
I still use Figma for detailed design thinking.
That is important because my background is in design, and hand-crafted design is still one of the parts of the process I enjoy most. I do not want to become passive and simply react to whatever AI happens to generate. AI is useful, but it should not flatten taste.
For me, the best workflow is:
- use Figma to explore layout, hierarchy, rhythm, and visual direction
- use Astro to implement that direction with precision
- use Sanity to give the design a flexible content foundation
- use OpenClaw to accelerate the parts that benefit from assistance
That keeps me in the driver’s seat where I want to be: making the important design decisions deliberately.
This feels like a healthier relationship with AI.
Instead of asking AI to invent the product for me, I use it to support execution, maintenance, and iteration around a direction I already care about.
The technical journey: what actually changes when you switch
Moving from Framer to Astro/Sanity/Vercel is not just swapping tools. It is changing the shape of your workflow.
That shift has both benefits and costs.
You trade convenience for control
Framer collapses a lot of decisions into one nice interface.
When you move to a composable stack, you have to make more choices yourself:
- project structure
- routing patterns
- content schemas
- deployment setup
- component organization
- data fetching strategy
- content-preview workflow
- naming conventions
That is more work upfront. There is no point pretending otherwise.
But it is also how you get a site that feels like your own system rather than a configuration of somebody else’s product.
You start thinking in systems, not just pages
One subtle but important difference is that you stop thinking only in terms of pages and start thinking in terms of systems.
Questions become:
- What kinds of content do I publish?
- Which parts are reusable?
- What should be modeled in the CMS versus hard-coded in the frontend?
- Which design decisions should remain fixed, and which should become flexible through content?
- How can this structure stay clean when the site doubles in size?
Those are not just technical questions. They are editorial and design questions too.
The handoff between design and implementation becomes more explicit
In Framer, design and implementation live close together by default.
In this stack, I have to translate design more intentionally. That is where Figma becomes useful as the source of detailed direction and where Astro becomes the medium of faithful implementation.
For me, that trade-off is worth it.
The design may take a little more deliberate effort to translate, but the result is a site that is more durable, maintainable, and flexible.
Why Sanity is especially interesting for designers
A lot of designers are comfortable controlling the surface layer but less excited about content infrastructure. I think that is understandable, but Sanity is one of those tools that can make content architecture feel creatively meaningful.
When you define schemas, you are making editorial design decisions.
You are deciding:
- what types of stories your site can tell
- how structured or open-ended your content should be
- which relationships matter between content types
- how flexible the publishing system should become over time
That is not just backend work. It is product design.
For people who care about long-term systems, Sanity opens up a different kind of authorship.
Image note
Placeholder for future image: Sanity schema or studio screenshot showing structured content for articles/case studies/projects
The real payoff: lower cost, higher agency
What I gained from this move is not only a cheaper hosting bill.
I gained agency.
I now have a site stack that:
- costs dramatically less to run
- fits better with agent-assisted workflows
- gives me more control over content structure
- supports handcrafted design instead of replacing it
- can grow with me instead of boxing me in
That combination matters.
A lot of modern tools are optimized for immediate convenience. But if your site matters to you—if it is part portfolio, part publishing system, part evolving digital home—then long-term flexibility starts to matter more than short-term ease.
Who this setup is for
I do not think everyone should leave Framer.
If you need the fastest possible path to a polished site and you do not care much about code-level control, Framer can still be a very good choice.
But I think Astro + Sanity + Vercel + OpenClaw is a compelling setup for people who:
- care about cost efficiency
- want more control over site architecture
- value structured content
- like designing with intention
- want to collaborate with AI agents in a more practical way
- see their website as something they will keep evolving over time
In other words, this stack is especially attractive for designers, creators, and technical generalists who want both polish and flexibility.
Final thoughts
This switch was not really about abandoning one tool for another. It was about choosing a system that better matches how I want to work.
I want the economics to make sense. I want the maintenance workflow to benefit from agents. I want the content model to be flexible. I want the design to remain intentional.
Framer helped me move quickly at one stage. But Astro, Sanity, Vercel, and OpenClaw feel more aligned with the next stage.
Not because they automate everything.
But because they give me more control over what should be automated, what should remain handcrafted, and how the whole system should evolve.
And for me, that is the bigger win.
Practical appendix: what each tool is doing
If you are evaluating a similar setup, here is the simplest way I would describe the roles:
- Figma: design direction, exploration, detailed UI decisions
- Astro: frontend implementation, page composition, performance-focused rendering
- Sanity: structured content management and editorial flexibility
- Vercel: deployment, previews, and low-friction hosting
- OpenClaw: agent-assisted development, maintenance, writing support, and workflow automation
Questions worth asking before you switch
Before moving away from a visual site builder, I think it is worth asking:
- Do I want lower cost badly enough to trade some convenience?
- Will I benefit from having my site expressed as code and structured content?
- Do I want AI agents to help maintain the system directly?
- Is handcrafted design still important enough that I want tighter implementation control?
- Am I building a one-page site, or an evolving content system?
Your answers will tell you whether this move is worth it.
If your site is growing into something more serious than a landing page, there is a good chance the answer is yes.