I did not leave Framer because it is a bad product. I left because my website had stopped behaving like a design project and started behaving like a small publishing system.
I wanted bilingual routes, file-backed articles, predictable redirects, complete control over structured data, locally generated audio, tests for the sitemap, and the freedom to change a component without negotiating with a visual editor. Framer could handle parts of that list. The problem was the growing tax around the parts it did not own cleanly.
So I rebuilt the site as a statically exported React project, keep the content in the repository, use AI as a development partner, and deploy the finished files to Vercel. The production site does not need a database or a server process. It is mostly HTML, CSS, JavaScript, images, and MP3 files served from a CDN.
This is not a “Framer is dead” article. It is a record of when a visual builder stopped being the right abstraction for one particular site.
The short version
Framer gave me speed at the beginning. The static site gives me control now.
| Framer model | Current static model |
|---|---|
| Visual editor owns the page structure | Git repository owns the page structure |
| CMS content lives inside the platform | Articles live as versioned files |
| Hosting and editing are bundled | Hosting, content, and tooling are separable |
| Changes happen mainly through a UI | Changes happen through code and reviewed diffs |
| Localization is a paid product feature | Locales are routes and content files |
| Platform conventions define the ceiling | My maintenance capacity defines the ceiling |
The last row is important. Owning the stack does not remove constraints. It replaces product constraints with engineering responsibility.
The cost comparison, without creative accounting
My Framer invoice history shows the real progression: a $90 Basic yearly payment in 2024, a $180 Basic Site yearly payment in 2025, and a separate $168.16 Locale payment in 2026. Using the most recent paid Basic and Locale invoices together, the platform cost was $348.16 before counting the domain.
Framer’s current public pricing also shows why localization changes the calculation: Basic is listed at $10 per month with yearly billing, while additional locales are listed as a $20-per-locale monthly add-on. Pricing changes, regional taxes differ, and my invoice is not a universal quote, so I treat my receipts as the record of what I paid and the official pricing page as the current reference.
My new cash outlay looked like this:
| Item | How I account for it | Cost |
|---|---|---|
| Static hosting on Vercel Hobby | Current recurring hosting | $0 |
| Domain registered with Spaceship | Yearly recurring cost | $8 |
| ChatGPT Plus | One month allocated to the migration | $20 |
| Migration-month outlay | Domain + one allocated ChatGPT month | $28 |
| Recurring website cost after migration | Domain only | $8/year |
That $28 number is the amount I assign to the transition this month, not a new monthly website bill. ChatGPT Plus is $20 per month according to the official ChatGPT pricing page, but I already use that subscription for work beyond this website. I am allocating one month to the migration because that reflects the concentrated build effort; I am not treating the subscription as permanent hosting infrastructure.
After the migration month, the marginal recurring infrastructure cost of this website is therefore $8 per year: the domain. The generated site does not call ChatGPT in production, and visitors do not consume AI credits when they open a page. If I stopped paying for ChatGPT tomorrow, the deployed website would continue working.
| Comparison | Cost |
|---|---|
| Recent Framer Basic + Locale invoices | $348.16/year |
| One-time migration-month allocation | $28 |
| Static site after migration | $8/year |
Against my latest Framer platform invoices, the recurring platform saving is about $340.16 per year. The domain is excluded from that saving because I need it in either setup. The first year also includes the one-off $20 allocation for the AI-assisted migration, bringing the new-model outlay to $28 rather than $8.
The Vercel $0 caveat
Vercel’s Hobby plan is $0 and includes Git deployments, a CDN, HTTPS, preview deployments, and enough included usage for many small static projects. But “free” is not the only condition that matters.
Vercel explicitly describes Hobby as a plan for personal, non-commercial use. Its Hobby documentation and pricing page both make that boundary visible. A portfolio that directly operates as a commercial business site may need Pro, currently listed at $20 per month. Anyone copying this setup should classify their own use honestly instead of treating Hobby as an unconditional free-hosting coupon.
My architecture remains inexpensive even if the hosting plan changes because static delivery uses very little compute. But the accurate claim is: my current Vercel bill is $0 under Hobby, subject to its eligibility and usage limits.
What finally pushed me away from Framer
My content needed to become portable
A CMS is convenient until the CMS becomes the only comfortable place where the content can exist. I wanted every article, translation, redirect, image path, audio path, and metadata field to be inspectable in the repository.
Now each article lives in a predictable folder with front matter and HTML content. Drafts remain versioned but disappear from public routes, RSS, and the sitemap. A platform migration no longer requires rescuing the writing from the platform first.
Localization had become infrastructure
English and Spanish are not cosmetic variants of the same page. They affect routes, metadata, sitemaps, hreflang relationships, editorial review, and publishing workflows. Paying for a locale was only one part of the friction; the larger problem was having less control over how the two content trees behaved.
In the static version, a real Spanish article is an es.md file. If the translation does not exist, the route is not presented to Google as translated content. That rule is simple enough to test automatically.
I wanted boring, inspectable SEO
The site now generates its own sitemap, robots file, RSS feed, canonical metadata, and language alternates. Redirects live in configuration. When an article becomes a draft, it leaves the sitemap during the next build. When several articles overlap, I can merge them and add permanent redirects in the same change.
None of this is visually exciting. That is why I like it.
AI made code ownership practical again
AI did not remove the need to understand the website. It reduced the cost of moving between design intent and implementation. I can describe a layout problem, inspect the proposed diff, run the site, compare screenshots, and iterate without turning every change into a fresh mini-project.
The important distinction is that AI assists the repository; it does not own the repository. The durable assets are still ordinary files, tests, Git history, build commands, and documented decisions.
What I gained
Ownership. The content and interface can move to another static host.
Version history. Every meaningful change can be reviewed and reversed.
Performance. Public routes are rendered during the build instead of assembled on every request.
Custom behavior. Audio, navigation, animation, schema, and editorial layouts are normal code.
Testability. The build verifies public routes, sitemap output, localization, and redirects.
Cost separation. The domain, hosting, AI subscription, and content are no longer one platform decision.
What I gave up
This move would be dishonest if I only described the upside.
The visual canvas. Framer is much faster when the main task is freely composing a marketing page.
Non-technical editing. A repository is not automatically a friendly CMS for a content team.
Managed conventions. I now own dependencies, build failures, accessibility regressions, and deployment configuration.
Instant publishing from a UI. Content changes move through files, Git, and a deployment.
A single support boundary. When something breaks, there is no one product responsible for the whole stack.
For a collaborative marketing team that needs to rearrange pages daily, I might still choose Framer. For a personal portfolio that is becoming an editorial and technical system, I prefer the repository.
The actual stack
The current site uses React 19, Vite, and vinext. Vinext provides an App Router-compatible model on top of Vite, and the project exports every public route as static output. Articles are stored under content/articles. A build script writes robots.txt, sitemap.xml, and rss.xml. Vercel publishes the resulting dist/client directory.
There is no production database for the blog and no text-to-speech API running when someone presses Listen. Audio can be generated locally and deployed as a normal MP3. This keeps the production architecture intentionally boring.
Would I recommend the same move?
Only if the reason is stronger than “code feels more serious.”
Stay with Framer if visual iteration is the main job, several non-developers publish content, or the existing platform already does what you need at a price you accept. Move to a static repository when portability, custom behavior, versioned content, technical SEO, and long-term control matter enough to justify owning the build.
The best tool is not the one with the lowest invoice. It is the one whose constraints match the work.
For this site, that changed. Framer was the right place to discover the design. The repository became the right place to keep building it.
The companion guide, How to Migrate from Framer to a Static Site on Vercel, documents the actual workflow, folder structure, deployment configuration, redirects, metadata, and AI-assisted QA.