Authoring

The Framer problem

The previous portfolio lived in Framer with a CMS. The structure was clean, the components were polished, and updating it was genuinely painful. Every new case study had to fit the same slots – the same section order, the same image ratios, the same word counts. The CMS was built to enforce consistency, and it did exactly that: it enforced it on the content too.

Adding a project meant hours of copy-pasting, resizing images, and trimming writing to fit fields that weren't designed for the story you were trying to tell. The system was protecting the design. The design was not serving the work.

Content forced to fit structure

Every portfolio system I had seen – Framer, Webflow, Notion galleries – starts with a template. You fill in the blanks. The problem is that good case study writing doesn't work in blanks. Some projects have deep research. Some are mostly visual. Some turn on a single decision. A fixed structure flattens all of them into the same shape.

The constraint wasn't technical – Framer is capable. The constraint was structural. When you define the container first and pour content in, you are already making editorial decisions before you've read a word. The interesting parts get cut. The thin parts get padded. The story gets managed instead of told.

Three principles, not one template

The new portfolio is built in plain HTML and CSS – no framework, no CMS, no build step. Every case study is a single file. What makes it a system isn't the technology. It's the set of rules that hold everything together while leaving the structure of each page open.

How a case study gets built

A new case study starts with a folder of materials and a paste of the raw story. From there, the system takes over. The design decisions – which sections to use, which components fit the content, how to pace the narrative – are made fresh each time, guided by the content and the design rules, not by a pre-existing layout.