Reality CMS

How did this start, did you set out to build a CMS?

It's funny because I didn't originally set out to build a CMS, I explored other options first. I looked at Payload, but felt the interface a bit too intimidating for the audience I was working with. Sanity was trickier to set up, and just as tricky to navigate. I genuinely put myself in their shoes and kept thinking, this is just WordPress all over again, with more control over the code at least.

So the frame was fear?

I don't think fear was the frame, I really think it was more “confidence”. I wanted them to feel confident publishing a page, reverting a draft, making an edit. For me, the experience had to feel familiar in order for them to have that confidence in the platform.

What did Mann Partners actually say that defined the problem?

They wanted “something where we won't feel like we broke anything.” They're an experienced team, older, I would say very busy, and felt like they needed something that would just work. From the first call I realized that they hadn't looked at their WordPress site in ages and needed something that would let them go in and quickly make a change without 1. breaking anything, and 2. having to call a developer.

Familiar to them specifically. What did you borrow?

I knew from the first few calls that they enjoyed using Canva, Google Docs, and really the whole G Suite. Clicking to edit, dragging and dropping to upload, these all seem like primitive interactions, that felt harder to do in existing CMS platforms. They weren't as predictable, and could be confusing at times. I looked for parallels and popular applications their team would use. Need a media library, look at Dropbox and Google Drive. Need history preview and rewinding, look at Notion. Same for analytics, and blog editing. It had to be predictable, and easy to navigate.

Most CMS platforms pride themselves on flexibility. You went the other way.

The issue with the other CMS platforms is that they were un-opinionated. I wanted the opposite. I have beliefs about what people should be allowed to edit, and the only time they would ever really need to get in the code is if they have to update the schema, or create a completely new page. Everything else should be possible and easy to do on the CMS. There's no schema editing, no blocks, no new page templates, no styling edits either. For me a CMS should really honor that; content. Every key schema and design decision would have been made beforehand, and if they ever need to make a change to either of those, that's when you call a developer. Not when you want to add a sentence at 8pm.

Has a client hit that wall yet?

No, not yet at least. I made it clear from the beginning what the limitations would be, and framed it instead to emphasize what they could do, not what was forbidden.

The core interaction is clicking the live page to edit it. You chose a side-panel inspector over typing directly in place. Why not the more “magical” version?

I couldn't decide on whether I should allow them to edit directly in the preview, similar to Squarespace or Google Slides, or if I should use a hybrid approach. The hybrid approach made it the easiest and most predictable to work with. A side panel would dynamically render the input field or button depending on the element you clicked. It was more technically challenging to build in the amount of time, fewer than 2 months to launch. And I think it seems magical in practice, but it becomes frustrating very quickly. If I start typing, it would cause the component to re-render each time. I would also have to conditionally render an inline input field for each editable string. What about images? Those aren't inline, so what would I show instead? Deliberately splitting the two operations meant the interaction and the side panel was more predictable, and from a development perspective, easier to maintain. It felt like editing a Keynote on Mac. I would click a title, or a chart, and the controls on the inspector would change. And I could see that.

First time someone from Mann Partners used it without you driving, what surprised you?

They tried editing the navigation and realized they couldn't find it. I didn't expect it because it didn't seem like content to me initially, but then I realized that the footer links were important to them, so I added that functionality.

You also audited your own work for security. What did you find?

I realized I forgot to update the Firebase rules from experimental to prod. It also allowed any authenticated user to perform write or delete operations on the db, which is bad because in the CMS we could create users with specific roles and restrictions.

This is a huge surface area for three months solo. What did you delegate to Claude Code, and what did you refuse to?

I would write out the user stories and a descriptive paragraph, in simple English, on how a feature should work. I then used a Claude Code session to draft a plan, I would make suggestions, and then delegate the plan for building. What I focused really was architecting the project; I chose the libraries, packages, folder structure, naming conventions, etc. Claude would take my direction and build from there. I would also go in Cursor and make CSS edits myself.

What's actually changed since it shipped?

Surprisingly, yes they have edited it themselves. Since launch they've created 3 new blog posts. I also imagined for a site of their scale, it was going to require very little maintenance, and as a result, very little updates to the core pages, about 5.

What did this project teach you that you've carried since?

This project in particular really forced me to think through a user flow in totality, and for a practical audience. From start to finish, how do I edit a page, what could I be thinking in that moment, what am I trying to do, etc. Very goal oriented approach, where the goal is also in a way more abstract. I want to feel confident that my edit was saved without breaking anything. I have the reassurance that I can rollback a version and continue making edits.