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.
Leave a Reply