FramerBot: a CMS bridge that started as a $20 problem
An AI-native dashboard for editing Framer CMS outside the editor, built first for our own team, then opened up to everyone.

- Role
- Designer + builder (solo)
- Timeline
- 2025, present
- Status
- Live ยท public beta
- Team
- Ajay Pawriya (solo)
- Tools
- Framer CMS API, Notion API, Next.js
- Links
TL;DR
FramerBot is an AI-native dashboard that lets a team edit any Framer CMS field, blogs, changelogs, anything, without paying Framer $20 per editor seat. It started as an internal tool I built to solve a problem on my own team, and turned into a product for everyone else with the same problem.
The $20 problem
If you build your marketing site on Framer and want to give your team CMS edit access, every editor needs a paid Framer seat. That's $20 per person per month for what is, in most cases, "let me publish a changelog."
For our team that math didn't work. We had non-designers who needed to push blog posts and updates a few times a month. Paying full editor seats for that was either a budget hit or a permission bottleneck, neither option was right.
v1, internal Notion โ Framer bridge
Most of our team already wrote in Notion. So I used the Framer CMS API to build a one-way bridge: write the blog or changelog in Notion, run the bridge, and the entry shows up in our Framer CMS, ready to publish.
No new tool to learn. No extra seats. Same authoring surface our team already lived in.
v2, public dashboard
Once the internal tool worked, the obvious move was: anyone running a Framer site has this same problem. I rebuilt the bridge into a hosted dashboard:
- a UI layer over the Framer CMS API
- edit any field on any CMS item from a clean web dashboard
- invite unlimited team members
- one paid seat in Framer (yours), every editor uses FramerBot
Why this exists as a product, not just a script
The Framer CMS API has been around. The reason a product like this didn't exist isn't technical, it's that nobody on a small team has the bandwidth to package "the script that solves the seat-pricing problem on my team" into something other teams can use.
I had the bandwidth, because the dogfooding was already done, every feature in FramerBot is one we needed ourselves first.
What I learned
Building FramerBot as a one-person product was the cleanest possible test of the design-engineer model. There's no Figma-to-engineering handoff to coordinate, no JIRA round-trip, no "let me sync with the dev team about this token change." When the design and the implementation live in the same head, the loop is measured in minutes instead of days.
It also proved out the loop I'm now running at Linkrunner: solve a real problem, ship the smallest thing that works, get it in front of users, iterate.