Blog

There’s an unspoken hierarchy in software development.

Custom developers — the people writing backends in Go, architecting databases, configuring CI/CD pipelines — occupy a certain tier of technical credibility. And then there are people like me: WordPress developers, no-code builders, AI-assisted developers. The people who, in certain rooms, feel like they need to justify their presence at the table.

I’ve felt that. More than once.

This is the story of a project that changed how I think about that hierarchy — and what happened when a WordPress and AI developer was handed one of the most complex frontend builds of his career.

How It Started

When Monkey & River and Momentum began planning their annual hackathon, they needed a platform. Not a tweaked version of an existing tool. A purpose-built system capable of managing roughly 700 student candidates through registration, team formation, judging, and final results — with an admin team that needed granular control over every stage of the process.

Three separate applications. A custom Go/Gin backend. PostgreSQL. Real infrastructure, real scale, real stakes.

I heard about the project and I was immediately excited. Not nervous — excited. Because I knew exactly what tool could deliver this, and I knew it because I’d been using it for months.

I recommended Lovable.

It was actually my suggestion that led Monkey & River to choose Lovable for the frontend. I believed in what the platform could do, and I was confident I could deliver. The development lead didn’t have the same depth of Lovable experience, which led to a natural split: I would own all three frontend applications, while Thomas and his team built the backend and infrastructure.

It was, on paper, a clean division of responsibility.

In practice, it was about to get considerably more interesting.

Building Three Apps at Once

The scope was significant. Three applications, each with their own authentication flows, their own user roles, their own UX logic — but sharing a design language, a component library, and a consistent experience across all of them.

The Admin Portal was the operational heart of the platform. Eight full phases of functionality: participant management with CSV import and export, a dynamic stage builder that let the MnR team configure the entire hackathon pipeline, team management, judge management, a configurable scoring dashboard with a live leaderboard, a communications module for bulk email, an audit log, and full user management with role-based access control. Dark mode. Notification flows. Scroll restoration. The kind of detail that separates a polished product from a functional one.

The Participant Portal was the student-facing application — the thing 700 candidates would actually use. Mobile-first, responsive, and built around a dynamic stage system that rendered form fields on the fly based on whatever the admin team had configured. No hardcoded forms. No rigid templates. The portal adapted in real time to the shape of the hackathon as the MnR team defined it.

The Bulk Email Tool was a standalone internal application for sending branded bulk emails to applicants. A block-based email composer, CSV recipient management, SendGrid integration via Supabase Edge Function, and full send history. Small in scope relative to the other two, but critical to the communications workflow.

One of the things I’m most proud of from this phase of the project is how I approached the consistency problem. When you’re building three separate applications that need to feel like one coherent system, the temptation is to rebuild everything from scratch in each app. Instead, I leaned into Lovable’s project knowledge — reusing components, navigation patterns, and styling decisions across all three applications. The result was a suite of tools that felt designed together, not assembled separately.

I was building fast. And it looked good.

The Week Everything Got Harder

Then the backend team said they were ready to connect.

This is where I need to be honest about something. My background is in WordPress and AI-assisted development. I am comfortable in that world. I know how it works, I know the tools, and I know my own capabilities within it.

Docker Desktop was not part of that world.

Neither was Bruno, or CORS configuration, or working through authentication pepper mismatches, or debugging port conflicts between a local Go server and a React frontend. These were not things I had done before. And they were now things I needed to do — alone, without a manual, on a timeline.

I genuinely enjoyed it.

I know that might sound strange. But there’s something about being dropped into unfamiliar territory with a real problem to solve that makes the work feel meaningful in a way that familiar tasks don’t. Every obstacle I cleared — getting the backend running locally for the first time, fixing the CORS configuration, working out why the auth flow wasn’t returning the right tokens — was a small proof that I could figure things out I’d never done before.

This is where Claude Code became essential.

I’d been using Claude as a development collaborator for a while at this point. But Claude Code — working directly in the codebase, making changes in context — was a different kind of tool. I used it to integrate the real API into the admin portal: fixing the two-step login and workspace selection flow, unwrapping the response envelopes the backend was returning, mapping between the frontend’s camelCase field names and the backend’s snake_case, configuring the URL prefixes. Changes that, done manually without deep Go and TypeScript experience, would have taken days. Done with Claude Code, they took hours.

I pushed everything to GitHub, coordinated with Thomas on the backend fixes that my integration work had surfaced — CORS headers, role claims, viewmodel refactoring — and kept moving.

The Moment That Mattered

There’s a specific memory from this project that I keep coming back to.

The backend team had been working on their side for weeks. Solid engineers, building real infrastructure, doing genuinely complex work. And then there was me — the WordPress developer, the AI builder — showing up to sprint reviews with fully functional, aesthetically polished applications that were ready to connect.

I don’t say this to diminish what the backend team did. Their work is the foundation everything runs on. But in that room, in those moments, I felt something shift.

As a WordPress and AI developer, I’ve often felt like I occupy a secondary tier. Like the “real” developers are the ones writing custom code from scratch, and I’m the person who makes things pretty and functional but isn’t quite in the same category. This project quietly dismantled that feeling.

I delivered three production-quality applications — with authentication, role management, dynamic data rendering, responsive design, dark mode, and a polished UI — in a fraction of the time that a traditional frontend development approach would have required. The tool I used was AI-assisted. The speed was real. The output was real. And the impact was real.

That’s not a shortcut. That’s a different way of working.

What Lovable Actually Is

I want to address something directly, because I think there’s still a lot of misunderstanding about what tools like Lovable are and what they’re not.

Lovable is not a drag-and-drop website builder. It’s not a template platform. It’s not something you hand to someone with no technical background and expect production software to come out the other side.

What it is, in my experience, is a React and TypeScript development environment that collapses the distance between intention and implementation. When I describe a component, a flow, or a feature, Lovable generates the code. When I review it and find something that needs changing, I refine it. When it needs to connect to a real API — as this project eventually did — that’s where Claude Code, GitHub, and genuine development knowledge come in.

The stack is real: React, TypeScript, Tailwind, ShadCN. The code is real. The applications it produces are production-quality. What changes is the speed at which a skilled developer can move from problem to solution.

That speed matters. In a world where development timelines are one of the biggest constraints on what gets built, the ability to deliver in days what used to take weeks is not a minor advantage. It’s a fundamental shift in what’s possible.

What I’m Taking Away

The MnR Hackathon Platform isn’t finished yet. The backend team is still completing the remaining endpoints — teams, scoring, communications, audit log — and once those are ready, the frontend mock data gets replaced with live API responses and the platform goes live for the next annual event.

But the frontend is done. Three applications, built by one developer, using AI tools, delivered at a pace that surprised everyone including me.

Here’s what I know now that I didn’t fully know before this project:

The hierarchy I described at the start of this post — the one where custom developers occupy a tier above AI-assisted developers — is a hierarchy built on assumptions that are becoming less true every month. The question isn’t what tools you use. It’s what you can deliver, and how fast, and how well.

On this project, I recommended the right tool, built the right applications, solved problems I’d never encountered before, and delivered something the whole team could be proud of.

That’s the job. Whatever tools it takes.

There’s a moment in most projects where the scope hits you. Where the thing someone wants collides with the reality of what it costs to build it, and the room goes quiet.

I had that moment not long ago, sitting with a quote for a client who had come to us with an idea for a custom e-learning platform. A full LMS. Live video classes, an interactive whiteboard, scheduling, attendance tracking, multi-role dashboards, multilingual support, resource management, and a mobile app to tie it all together. The kind of product that, done properly, is a serious piece of software.

The development estimate came to 390 hours. The design estimate — research, UX flows, wireframes, branding, a full design system, high-fidelity UI, prototyping, and handoff — added another 120 to 175 hours on top.

We’re talking somewhere north of 500 hours of professional work. At agency rates, that’s a number that makes most clients’ eyes water.

The client couldn’t believe it. They’d had a vision in their head, a problem they wanted to solve, and no real frame of reference for what it would take to build the solution properly. They didn’t accept either quote — not the development one, and not the design one. Not because the quotes were wrong. But the true cost of custom software is something most people have never had to confront before.

They walked away. But they left me with a question I couldn’t stop thinking about.

What if WordPress could do this?

The Premise

I want to be upfront about something: I’m a WordPress developer. I know the platform well. I know what it can do, and I know what it struggles with. And when I looked at the requirements for this client’s platform, my instinct was that a custom WordPress theme — built properly, from scratch — could hit most of the brief at a fraction of the cost and timeline.

But I wanted to test that instinct. Not just sketch something out or throw together a page builder demo. I wanted to actually build it. A production-quality LMS theme, coded by hand, with real functionality — and I wanted to do it using AI as my development partner.

The result was ApexLearn.

What I Actually Built

ApexLearn is a fully custom WordPress LMS theme. No page builder. No starter theme. No plugins doing the heavy lifting. Every line of PHP, CSS, and JavaScript was written deliberately — with Claude as my collaborator throughout.

Here’s what the finished theme includes:

Custom Post Types and Taxonomies — course, instructor, and lesson CPTs registered entirely in code, with course_category and course_level taxonomies powering a dynamic course catalogue.

AJAX Course Filtering — live filtering by category and level with no page reload, a PHP AJAX handler secured with nonces, and GSAP stagger animations on the returned cards.

Dynamic Single Course Template — hero pulled from the featured image, real instructor bio and photo loaded from a linked instructor CPT, related courses queried by matching taxonomy, animated progress indicators, and a sticky enrol sidebar.

Simulated Enrolment Flow — a fully designed multi-step checkout modal with personal details, card fields, and a success state, built to demonstrate the UX without real payment processing.

Interactive Student Dashboard — five-panel sidebar navigation, animated metric counters, progress bars with CSS transition animations, tabbed course lists, an expandable activity feed, and functional settings toggles.

Performance and Polish — page transition fades, sticky navigation with hide-on-scroll behaviour, button ripple effects, scroll-triggered section reveals via IntersectionObserver, and image lazy loading.

Full Responsive Design — mobile-optimised across three breakpoints, with a hamburger nav, a catalogue filter drawer, and a dashboard sidebar that converts to a horizontal scrollable tab strip on small screens.

Seven-page templates. A complete design system built on CSS custom properties. GSAP animations throughout. And a 404 page, because the details matter.

How the AI Collaboration Actually Worked

I want to be honest about this, because I think there’s a lot of noise right now about what AI can and can’t do in development — and most of it misses the point.

I didn’t type “build me an LMS” and watch a theme appear. That’s not how it works, and that’s not what I wanted anyway.

What I did was bring a clear vision and a structured approach. I communicated how I wanted things to be architected. I worked through design iterations — describing what I wanted, reviewing what came back, refining until it felt right. Once the design direction was locked, the theme file was generated as a starting point. I uploaded it to LocalWP, opened Visual Studio Code, and continued building from there using Claude Code.

The process felt less like using a tool and more like working with a capable developer who happened to be available at 11 pm when I was trying to figure out why a GSAP animation wasn’t firing correctly on scroll. I’d describe the problem, we’d work through it, and I’d implement the fix. When I wanted to add a feature, I’d explain the behaviour I was after, and we’d figure out the cleanest way to build it.

The design system came out of that kind of back-and-forth. Three typefaces — Cormorant Garamond, Source Sans 3, and a mono stack. A teal/green brand palette. Generous whitespace, subtle shadows, a premium corporate feel that was informed by the client brief but elevated by the iteration process.

Where It Pushed Back

I said I’d be honest, so here it is: AI didn’t make everything easy.

There were moments where the generated code needed significant reworking. Where a suggested approach worked in isolation, but broke something else in the theme. Where I had to understand what was happening well enough to fix it, not just copy and paste a solution.

This is the part that I think gets lost in the “AI is going to replace developers” conversation. The AI made me faster. It reduced the friction of getting from idea to implementation. It handled a lot of the manual nuance that used to eat hours — the boilerplate, the syntax checking, the “what’s the WordPress function for this again” moments.

But it didn’t replace the need to think. To the architect. To make decisions about how things should be structured and why. The knowledge I’ve built over years of WordPress development wasn’t made redundant by AI — it was what allowed me to use AI effectively. Without understanding the WordPress template hierarchy, CPT registration, and how AJAX handlers work, I wouldn’t have known whether the generated code was good or just plausible-looking.

AI is a force multiplier. It’s not a substitute.

The Numbers That Matter

Let’s go back to that original quote for a moment.

The custom software estimate was 390 hours of development and up to 175 hours of design. At modest agency rates, that’s a project measured in hundreds of thousands of rands before you’ve written a line of code.

ApexLearn — a theme that covers a substantial portion of the core brief — was built by one developer, working with AI, in a fraction of that time. It’s not a pixel-perfect match to every feature on the spec sheet. Live video integration, real payment processing, and multi-tenant architecture are genuinely hard problems that custom software handles better. But the core experience — the course catalogue, the student dashboard, the enrolment flow, the instructor profiles — all of it works, all of it looks premium, and all of it was built without a team.

That gap is significant. And it’s only going to get more significant as AI tools improve.

My Honest Verdict

I’ll say it plainly: I’m genuinely impressed by what’s possible.

Do I think AI is going to take my job? Not yet. Not soon. The craft of development — the architectural decisions, the client communication, the problem-solving under constraint — still requires a human who knows what they’re doing. What AI has done is compress the timeline between having an idea and having something real. It’s removed a lot of the friction that used to make ambitious solo projects impractical.

For developers who are willing to adapt, that’s not a threat. It’s an enormous advantage.

ApexLearn started as a question: Can WordPress meet these requirements? The answer, built line by line with AI at my side, was a convincing yes.

The client who inspired it never saw the finished product. But the next client who comes to me with an ambitious brief will.

What This Means for the Industry

If you’re a developer reading this, here’s what I’d encourage you to think about: the developers who will struggle in an AI-assisted world aren’t the ones who know too much. They’re the ones who refuse to adapt.

AI doesn’t reward ignorance. It rewards people who understand their craft well enough to direct it, review it, and improve on what it produces. The bar for what one person can build has moved — significantly — and that creates opportunities for developers who are willing to work with the tools rather than against them.

I built a production-quality LMS theme by myself, using AI as a collaborator. That’s not a party trick. That’s a genuine shift in what’s possible.

And I’m just getting started.