What do you actually need when you sit down to write?
For a long time, my answer to that question was buried under the tool. I was spending more energy managing my publishing platform than improving the experience it was meant to deliver. This is the story of how I went looking for a simpler answer, and what that search changed.
Where it all started
I have been building and managing websites in one form or another for a long time. My journey started around 2010 with Joomla, moved through WordPress, and eventually landed on Framer, where this personal site began.
Each transition made something easier. Joomla and WordPress gave me content management. Framer gave me much more visual control: I could see changes directly on screen without switching to a browser, and I didn’t have to build everything in code.
But over time, I noticed something...
The tool itself had become the work. A seemingly simple change could mean navigating layers, adjusting containers, thinking through breakpoints, managing CMS collections, or finding a workaround for something that didn’t quite behave the way I wanted.
ConsultAman worked. But managing it was increasingly getting in the way of evolving it. That became the starting point for ConsultAman 2.0.
It wasn’t really a Framer problem
At first, the migration question seemed straightforward: where should I move my site?
I initially considered an AI-first builder, because prompting something, seeing it change, refining it and deploying it felt far more natural to me than working through a traditional visual editor. But that led to a more important question: do I actually need another enhanced website builder?
ConsultAman isn’t a complex enterprise platform. It is primarily a place where I write, share ideas, surface useful resources, document experiments and, increasingly, connect those things together.
So instead of asking which CMS should replace my current one, I started asking:
What publishing experience do I actually need?
That changed the direction completely.
I didn’t want another CMS
This became one of the most important principles behind the redesign.
It would have been easy to recreate everything on a sophisticated content-management system. Collections. Fields. References. Configuration panels. Media libraries. Taxonomies. Settings. Each one makes sense on its own. Together, they would have turned me into someone managing a CMS instead of writing for one.
So I looked at each one and asked the same question: does this help me write with ease and stay focused, without hunting for where things are? The answer came quickly: most of them didn’t.
What I actually need when I decide to write something is much smaller:
Write → Format naturally → Add media → Get quality and SEO guidance → Preview → Publish
That became the design brief. Everything that didn’t contribute meaningfully to that journey could either disappear or move quietly into the background. The resulting authoring experience is much closer to Medium-style writing than to traditional CMS administration, and that simplicity made a surprising difference.
Thinking about the reader, not the article template
I applied the same thinking to the reading experience.
It is easy to think, “I need a blog template.” But readers don’t experience a template. They experience a journey.
Someone arrives through a shared link, a search result, a recommendation or another part of the site. They first need to understand what they’ve landed on. Then they decide whether it’s worth their time, read comfortably, and perhaps discover something useful enough to keep exploring.
So the article experience became:
- Land: understand the topic and context.
- Read: comfortable typography, hierarchy and responsive media.
- Orient: know the approximate reading time and keep context through a longer piece.
- Discover: encounter something relevant rather than merely recent.
- Explore: reveal additional depth only when it’s useful.
- Continue: move into another related thought, framework, resource or experiment.
That is subtly different from creating a blog.
It is designing a reading experience.
The biggest hesitation: Claude Code
This was probably the most interesting part of the journey for me personally.
My background is experience strategy and design, not JavaScript engineering or coding. I’m comfortable thinking about journeys, behaviours, hierarchy, progressive disclosure, design systems and product outcomes.
Opening a terminal and behaving like a software engineer? Not particularly appealing to me.
There was a definite mental barrier: would this become too technical for me?
However, I decided to challenge that assumption. Instead of trying to become a programmer before building anything, I approached implementation using skills I already had. I defined intent. I established product principles. I thought through the architecture. I broke the migration into bounded phases. I inspected outcomes visually, corrected what mattered, and validated before scaling.
My build approach became:
architecture → functional behaviour → visual quality → final polish.
Execution followed another simple rhythm:
define → build → inspect → correct → validate → scale.
Suddenly I wasn’t trying to be an engineer. I was directing implementation.
AI wasn’t only writing code
This is where my understanding of AI-assisted development changed most.
I initially expected AI to help implement what I asked for. What surprised me was how much the assisted process itself exposed.
During the migration, implementation surfaced things I needed to think about more deliberately. Some I had overlooked on Framer simply because nothing nudged me, and I was focused on writing. Here is what came up:
Missing or weak SEO descriptions, title quality, responsive behaviour, content hierarchy, open-source tools to support, authoring options, email services, monitoring, deployment considerations, and opportunities to simplify the system itself.
That changed the relationship from “I specify, AI codes” to something closer to this: I define the direction, AI helps implement and exposes gaps, I evaluate, and the system improves.
That was a much more interesting model. It combined human judgement with implementation assistance.
ConsultAman 2.0 became better, not merely migrated
That was another pleasant surprise.
The success criterion could have been simple: get my existing site out of Framer without breaking anything. But the migration created a chance to improve the underlying experience.
ConsultAman 2.0 now has a much stronger responsive foundation.
SEO requirements are more visible and actionable. Article presentation is more purposeful. Authoring is substantially lighter. Reading-time guidance helps readers understand the commitment upfront. Content can increasingly connect to relevant ideas and resources. Progressive disclosure means information doesn’t need to be dumped onto people immediately. And the site is now owned through an AI-assisted code workflow, source-controlled through GitHub and deployed through Vercel.
But perhaps most importantly: I didn’t solve Framer’s complexity by moving to an even bigger CMS. I took a step back and removed most of the CMS instead. That may be my favourite outcome from the entire exercise.
From content management to content relationships
Another shift happened while I was thinking about what comes next.
Traditional CMS architecture is very good at answering questions like where an article lives, what category it’s in and what tags it has. Those things remain useful. But they don’t answer a more important reader question: what should I explore next?
That led me toward thinking less about pure content management and more about content relationships. An article can lead naturally into another article, a framework or an experiment. Suddenly ConsultAman doesn’t need to behave like a collection of individual pages.
It can behave more like a connected body of thinking.
I’m still working through what that means in practice, but it has already started to take shape, as the related articles below show.
Something else changed: the implementation boundary
For years, there was a reasonably clear boundary between strategy, design and development. I could define an experience deeply, map it, structure it, prototype it, establish principles and document behaviour. But eventually, implementation required a handoff.
AI-assisted development made that boundary much more fluid. I’m not learning code because I want to become a coder. I’m learning enough about modern product implementation that my experience-strategy skills can travel further without a handoff at every step.
That changes my capability model from experience strategy → design → specification → handoff to something closer to experience strategy → systems thinking → experience architecture → AI-assisted implementation → validation → deployment → learning → iteration.
I still care about the same things I always have: intent, clarity, journeys, progressive disclosure, human behaviour, systems, consistency and outcomes.
AI hasn’t made those skills less relevant. It has given them a longer runway.
From Joomla to AI-directed product ownership
Looking back, the evolution is interesting.
Joomla → WordPress → Framer → Claude Code, GitHub and Vercel.
At first glance, it looks like an evolution of tools. For me, it represents something slightly different. With each earlier generation, I was largely learning how to operate a publishing system. This time, I could increasingly define how the publishing system should operate for me.
That is a meaningful change. Not because code is inherently better than low-code. Not because AI should replace designers or developers. And certainly not because everyone needs a custom publishing platform. It matters because AI can dramatically reduce the distance between an experience decision and a working implementation. For someone working in experience strategy, that creates interesting possibilities.
The reflection I would take away
ConsultAman 2.0 isn’t simply a redesigned personal site. It has become a lightweight, connected publishing platform built around how I actually think, write and experiment. And it is also a small experiment in where my own role is heading. Not toward becoming a full-time developer, but toward being comfortable moving across strategy, systems, experience, implementation and outcomes, using AI wherever it meaningfully reduces the distance between them.
If there’s one reflection I take from this migration, it’s this: you don’t need to become an expert in every implementation layer before you can take greater ownership of what gets built.
You need to understand intent. You need judgement. You need enough systems thinking to know what should connect. You need to recognise when complexity is helping and when it is simply getting in the way. And increasingly, AI can help with what sits between those decisions and a working product.
More capability. Less friction. Better connection. And considerably more ownership.
