Scaling Framer’s help center

When Framer started growing fast, our support workload grew with it. At the time, there was no public documentation, everything lived in our heads and internal notes. That combination doesn’t scale. So we started building a help center.

Building the help center

Writing documentation turned out to be harder than expected. The challenge wasn’t understanding the product, we knew it well. It was explaining it clearly to someone seeing it for the first time.

We ended up defining a strict way of writing: consistent structure, consistent tone, shared rules for how things should be explained. Over time, that became a help center with more than 250 articles. But it also meant that keeping it up to date required following all those rules, every time.

First attempt with GPTs

When OpenAI released custom GPTs, we started using one to help with writing. It worked. We could provide context, generate a draft, and iterate on it, noticeably faster than writing from scratch.

But it still required manual work. Gathering context, guiding the model, reviewing the output, moving everything into the CMS. Even with that setup, getting one article ready could take around 20 minutes. For a small team, that overhead adds up. A lot of things just stayed on the backlog.

Introducing an agent

A few weeks ago, Ivan connected Devin, an AI agent our engineering team uses for coding and PR reviews, to our Framer project through the Server API. That meant I could ask it, directly from Slack, to create or edit help articles.

I was skeptical. We’ve spent a lot of time refining how these articles are written. It wasn’t obvious an agent would follow those conventions without constant correction.

But Devin has access to our existing articles, our writing rules, and the product itself through the codebase. So I decided to test it properly.

Turning a support thread into an article

For the first test, I gave it a real enterprise support thread and asked it to turn it into a help article.

The result was surprisingly good. Structure and tone matched what we already had. It followed our conventions and suggested links to related articles. I reviewed it, approved it, and it was already waiting in the CMS.

Applying it to maintenance

Then I tried something more telling: there were a number of small fixes that had been flagged in Slack over weeks, things that should have been updated but kept getting deprioritized. I asked Devin to apply them.

In under 10 minutes, everything was ready for review in the CMS.

What actually changed

The main difference isn’t speed, though that matters. It’s the friction.

Before, even a small update meant going through the full process: gather context, rewrite, review, publish. That overhead was enough to keep a lot of things from ever getting done.

Now, most of that happens in one step, with a review at the end. The gap between noticing something is off and fixing it is almost gone.

What used to be a task is something you just do as you go.