From Process Nerd to Next.js: How I Accidentally Became a Web Dev
Four weeks. Five days of actual effort. A Claude Max Pro subscription. Built in the margins of a full-time job as managing partner — here's how bpexperts.de went from a legacy CMS to a fully connected Next.js platform with MCP servers, agentic pipelines, and a knowledge graph backend.
By Russell Gomersall, bpExperts
I am not a web developer. I'm a BPM consultant. I think in process flows, operating models, and governance frameworks. My natural habitat is a Signavio workshop or a Neo4j Cypher query, not a terminal running npm run dev.
And yet — here we are. Four weeks from first idea to published website. Roughly five days of actual effort, spread across evenings and gaps between client calls. A Claude Max Pro subscription. And a lot of learning done at speed.
The rest of the time I was doing my regular job — managing partner at bpExperts, running customer projects, supporting sales, the usual. The website wasn't a dedicated project with protected time. It was something I built in the margins.
That's worth saying up front, because it shapes everything about how this got done.
Why the Old Site Had to Go
The trigger wasn't dissatisfaction with the design. It was Business Flows 2.0.
When we launched the expanded reference content — significantly deeper E2E domain coverage, the AI Accelerator layer, new value flow mappings — it became immediately clear that the website couldn't carry it. In the past, bpExperts had always used the website as a living knowledge surface: regularly updated insights, new framework content pushed as we developed it, the website reflecting our actual thinking in close to real time.
Business Flows 2.0 changed the scale of that. The content volume jumped. The structural complexity jumped. And simultaneously, the pace of our AI engagements — the MCP servers, the agent pipelines, the knowledge graph work — was accelerating in ways that needed to be visible externally.
Our previous CMS simply couldn't keep up. Not technically, not structurally, and not in terms of the effort-to-output ratio. Every update required manual intervention. There was no way to connect it to our internal systems. And the dev-to-production workflow was genuinely painful: two separate environments, a cumbersome merge plugin, and a deployment process that regularly took hours. No version control. No branching. No way to test a change in isolation before it went live.
So I decided to replace it. With no real plan for how. And about five days to spare.
Enter Claude Code
The turning point was getting access to Claude Code — Anthropic's AI coding agent that runs directly in your terminal.
The way it works: you describe what you want, it reads your project files, writes the code, runs commands, catches its own errors, and iterates. It's less like a chatbot and more like a very fast, very focused coding partner who happens to know every framework ever invented and doesn't get tired at 11pm.
My working relationship with Claude Code started small. A component here, a data fetch there. Within a couple of weeks I'd stopped second-guessing it and started just building. The feedback loop is genuinely different — I could go from "I want an admin page where I can review draft signals before they publish" to a working, styled, authenticated page in the time it would previously have taken me to read the Next.js documentation. That compression of learning time is what made the whole project possible alongside everything else.
Falling Down the Next.js Rabbit Hole
The stack is Next.js with an App Router architecture, deployed on Railway from GitHub, with Cloudflare R2 for assets.
The Railway + GitHub combination changed the entire development experience. The cycle — commit, push, Railway builds and deploys, check it live — takes minutes. We run a dev branch that deploys to a staging environment; once we're happy, we merge to main and it goes to production automatically. The whole thing is version-controlled, branchable, and reversible.
Compare that to the old CMS setup: two separate environments, a cumbersome merge plugin, and a deployment process that regularly burned hours. No git history. No branching. No way to roll back cleanly. What now takes minutes used to be an exercise in frustration — and a significant reason why the old site fell behind.
Six months ago I knew Next.js existed. That was about it. What followed was a genuine deep dive — app router vs pages router, server vs client components, use client directives, dynamic routes, API routes, middleware, image optimisation, edge functions. Not learned in sequence from documentation, but picked up under the pressure of building something real, in short bursts, between other commitments.
The moment I knew something had genuinely shifted was when I built the admin layer. Not a simple preview page — a proper internal tooling interface:
- Draft review and approval flows — everything the AI agents queue goes here before it touches the live site
- Asset manager — browse, tag, and inspect everything in R2 without touching the Cloudflare console
- Team profile editor — update photos, bios, and expertise tags directly from the browser
- Signal composer — structured editor for creating and scheduling content
- Live preview — see exact render before publishing
Pushing the Frontend Further
Once the core architecture was solid, I wanted to see how far the frontend could go. Two features in particular pushed into territory I hadn't expected to reach.
The animated Business Flows visualisation on the homepage renders the four-domain universe as a live, interactive graphic — the orbits animated, responding to hover and scroll, with smooth transitions. The tech stack underneath it is leaner than you'd expect: SVG with CSS keyframe animations and Framer Motion for the interaction layer, Tailwind for layout. No canvas, no WebGL — just the browser doing what it's very good at when you push it properly. Claude Code wrote most of the animation logic; I directed the aesthetic and iterated the timing until it felt right. See it live on the homepage →
The news ticker — the live signal feed scrolling across the hero — sounds simple but was surprisingly involved to get right: seamless infinite scroll, correct handling of variable-length content, no layout jank across viewport sizes. It pulls live from the signals database and refreshes automatically. Small detail, but the kind of thing that makes a site feel alive rather than static. Watch it run →
The Part That Actually Excited Me
Here's where my BPM instincts kicked back in properly.
The website isn't a static front-end. It's connected — to our Neo4j knowledge graph, to Cloudflare R2, and to a custom MCP server (Model Context Protocol) that exposes the entire content layer as structured tool calls. AI agents can draft a signal, attach images from R2, tag it with topics and domains, and queue it for review — all through tool calls, no UI required. I review it, approve it, it publishes. The human stays in the loop. The overhead of routine content operations drops dramatically.
If you look at it through a process lens — and I can't help looking at things through a process lens — it's just a well-designed content workflow. Defined inputs and outputs, clear roles, automation handling the repetitive steps, governance at the approval gate.
Agentic Pipelines
The MCP server architecture opened up something more interesting than content publishing — it made it possible to build agentic pipelines that handle entire workflows end to end.
MCP Server pipeline from GitHub: When we publish or update an MCP server to GitHub, an agent pipeline reads the repository — README, code structure, tool definitions — generates a benefit-led marketing description, and automatically creates or updates the corresponding entry in our public MCP registry on the website. No manual copywriting, no stale listings. The pipeline runs on push.
BPM360 Podcast pipeline from YouTube: When a new episode lands on YouTube, an agent picks up the video, extracts the transcript, identifies key topics and guest details, cross-references them against our BPM Pioneer knowledge graph, and generates a structured signal entry — complete with episode summary, topic tags, and graph links to relevant signals and entities. What used to be a manual content task that routinely got deprioritised now happens automatically.
What's Coming
The most significant pipeline in progress is a full Riverside → YouTube → Signal → LinkedIn publishing chain.
The flow: record an episode on Riverside, export to YouTube, the pipeline picks it up, generates the signal, and auto-publishes to LinkedIn — with the right formatting, tags, and links. The goal is zero manual steps between hitting "stop recording" and having the content live across all channels. The individual components exist. The integration is what's being wired together now.
Beyond that:
- AI Accelerator showcase — mapping our AI use cases visually to the Business Flows domains
- Client case studies — structured and searchable, tied to engagement domains and outcomes
- Enhanced team profiles — expertise areas linked directly to the knowledge graph
What I Actually Learned
A few reflections for anyone considering something similar:
You don't need to understand everything before you start. I started knowing almost nothing about Next.js and ended with genuine opinions about caching strategies. The project was the curriculum.
Claude Code changes the learning curve but doesn't eliminate it. You still need to understand what you're building well enough to direct it, review its output, and catch its mistakes. The depth required is lower — but it's not zero.
Five days and a Max Pro subscription goes further than you'd think. The total investment here — if you exclude the learning, which was its own reward — was modest. What it required was focus in short bursts, a willingness to build before fully understanding, and the right AI partner to close the gaps. The cost of not doing it — a website that couldn't reflect what bpExperts had become — was much higher.
The deploy cycle matters more than you think. Going from hours (legacy CMS, no version control, manual merges) to minutes (Railway, git, branch-based staging) changes how you work. You experiment more. You ship faster. You fix things before they become problems.
Process thinking transfers. The habits that make someone good at BPM — thinking in systems, defining inputs and outputs clearly, designing for maintainability, building in governance — turn out to be genuinely useful in software projects. I wasn't a web developer. But I was already a systems thinker. Turns out that's most of the job.
Welcome to the new bpexperts.de.
— Russell
Find me on LinkedIn or reach out via our contact page.