The prototype is the brief
How we built our client platform with AI – and why not one line of vibe-coded output has ever shipped.
By Emelia Gatley, Director of Operations, Websure
There’s a genre of article about AI and software development, and it comes in two flavours. One says AI will replace developers. The other says AI-generated code is unmaintainable trash and everyone using it will regret it.
We’ve spent the last year building and running a client-facing platform – the Websure Dashboard (we are in the market for a catchy name, feel free to let us know if you think of one) – using AI at the centre of the process, and neither flavour describes what actually happened. So this is the third version of the story: the one where the prototype never ships, the developers were never replaced, and we build faster than we thought possible precisely because we kept the engineering discipline.
I run operations at Websure. John Phillips, Al Amin Mohammed and Shamimul Haque built the Dashboard. Sophie Evans takes the lead on Design and Brand. This is how the five of us actually work, including the parts that don’t work.
Before the first line of code: fifteen years of process
The Dashboard didn’t start as a product idea. It started as a process, one that’s been honed over fifteen years of agency delivery, through many owners, many managers and many hands.
Monthly retainer reporting. Hour tracking and rollover arithmetic. Project status. Support tickets. Incident classification. Every one of those already existed as a working discipline inside the agency long before anyone opened an editor. The Dashboard is that operating model made visible to clients – which meant the scoping question was never “what should we build?” It was “which parts of what we already do should clients see?”
That distinction matters more than any tooling decision in this article. AI lets you build fast. It cannot tell you what’s worth building. A vibe-coded prototype of a process you don’t run is a very fast route to a product nobody needs. Ours worked because the process came first, by about fifteen years.
The tooling arc: Lovable, Figma Make, Claude, then by hand
We didn’t arrive at our current workflow deliberately. We arrived at it by exhausting the alternatives.
Lovable got us a working prototype in days. It was genuinely impressive as a proof of concept. I presented it to the team at our annual Summer Summit and everyone put their hand up to be the one to lead the build. I was thrilled.
I thought we’d go from Lovable to live within a matter of weeks. But as we teased out the product and needed it to do things specific to our business logic, we found ourselves fighting the tool’s assumptions instead of building. Good for proving an idea exists. Not a foundation.
Figma Make moved us closer to design fidelity, and taught us the second lesson: a beautiful screen and a working product are different artefacts, and tools that promise both tend to shortchange one.
Plus, Figma Make was essentially free at the time. No credit usage, no credit limits, just unlimited playtime. I spent countless hours into the early morning finessing and tweaking and ideating new features. It got out of hand.
I got carried away, and I ended up with Frankenstein’s monster: everything but the kitchen sink thrown in.
Having worked in the agency world for some time, I knew from experience that this is the pitfall every one of my clients falls into. And I could see exactly how they got there. I don’t blame them, this process made me more empathetic, for sure.
That’s the tricky thing with AI builds. You can scope and prototype and mock up and vibe code to your heart’s content. But none of it is based on a real data structure, the logic isn’t fully thought through, you start to lose sight of the use case and the user journey, and before long you’ve built a three-headed dragon with no idea how the wings connect.
That’s when you take a breath, apply your expertise, and go back to pen and paper.
What are the MVP features? Each one needs a justification that would stand up in court. Everything else goes in the backlog and the pipeline.
It’s hard. Everyone had a strong idea to add this feature and that feature; my production team made the case for more. But we had to focus on shipping – else we’d be just as bad as everyone else.
Hand-built is where the Dashboard lives now – Next.js, React, a proper database, real authentication, staged environments, automated checks before anything ships. Built by developers, in a codebase they own end to end.
The arc taught us what AI tooling in this workflow is actually for. It isn’t construction. It’s communication.
The workflow now
When I want a new feature, I don’t write a specification document. I open Claude and build one.
I’ve got a Claude project that now holds the full context – the whole history of the product in one place. Bear in mind, this was backed up by hours upon hours of scoping chats in ChatGPT to shape the PRD in the first plac. Several iterations of that PRD went into Claude before a single prototype did.
(I’m evidently a fickle creature and will jump ship to the latest software that serves me, i’m AI agnostic but we’re pretty settled with Claude … for now)
Within an hour or two I have a working HTML prototype – clickable, styled, populated with realistic data. It expresses exactly what I mean: where things sit, how states change, what the empty case looks like, what happens on click. Then I send the HTML to Al Amin and Shamimul, alongside the task in Zoho Projects with a short written scope.
They don’t use my code. They read it, interrogate it, and rebuild the feature properly inside the real codebase – with the actual data model, the actual permissions, the actual business logic.
The speed gain isn’t in the building. It’s in what we stopped doing: the interpretation loop. A written brief crossing a timezone boundary gets read overnight, interpreted, built, reviewed the next UK morning, corrected, rebuilt. Each round trip costs a day. A working prototype is unambiguous in a way prose never is – most of those round trips simply disappear. Features that used to take three to five days from idea to staging now take less than one.
The interview
I asked Al Amin and Shamimul to be honest about what this workflow is like from the receiving end. They were.
What’s the first thing you do when one of my HTML prototypes lands?
Shamimul: The first thing I do is understand the overall flow and compare it with our application. I identify what is purely UI and what requires backend coding, new APIs, database changes, permissions, or third-party integrations. Then I break it into parts before writing any code.
What does a Claude HTML prototype most often get wrong?
Shamimul: The prototypes are usually very good for visual direction, but they don’t know our application’s architecture. They often assume data already exists, don’t always account for user permissions, loading/error states, API limitations, responsive behaviour in edge cases, or how features integrate with our existing components and design system. Those are the things that need to be adapted during implementation.
What would happen if we just shipped the prototype?
Shamimul: It would look correct visually, but it wouldn’t be production-ready. It would likely have hardcoded data, no real backend integration, no authentication or permission handling, no validation, limited accessibility, and wouldn’t fit our application’s architecture or coding standards. Most importantly it would not be maintainable and scalable for further features to come.
What do you now refuse to start without?
Shamimul: I prefer not to start until I understand the complete scope of the feature. That includes the expected user flow, where the data comes from, any backend or third-party dependencies, permissions, and success criteria. Having that clarity early prevents unwanted bug and repetitive work later.
And what could I do better?
Shamimul: The HTML prototypes are already very helpful. The one thing that would make implementation even smoother is having a short technical note alongside the prototype explaining the accepted criteria, where each metric comes from, any third-party services involved, and whether something is static, calculated, or editable. That reduces assumptions and speeds up development.
What could you do better?
Shamimul: I could spend more time reviewing the entire feature before implementation and communicate before starting building any features. I also want to ask architecture and data-flow questions earlier, identify potential technical risks upfront, and provide more accurate estimates before starting development. That should reduce surprises during implementation.
What we’ve learned
The prototype replaces the specification, not the developer. That’s the whole model in one sentence. AI compressed the distance between an idea and an unambiguous expression of it. Engineering still turns that expression into something clients can rely on.
Context is the multiplier. The single biggest quality lever on the prototypes isn’t the tool – it’s how much of our business logic the AI is given before generating. We now maintain that context deliberately, the way we’d maintain any other delivery asset.
Finished-looking is not finished. The polish of a prototype says nothing about the engineering behind the feature. Estimates come from the people building the real thing.
The codebase has one set of authors. Every production line was written by the team that maintains it. Nothing in the app is a mystery to the people responsible for it – which is the difference between building fast and building debt.
Timezones stopped being a tax. A prototype built in UK hours becomes engineered work overnight in Bangladesh and a review the next UK morning. The workflow turned our geography into a feature.
We don’t ship AI-generated code. We ship AI-accelerated decisions – built properly, by people who understand every line.
If you’re wrestling with where AI fits in your own delivery process, we’re happy to open the hood. Get in touch.
Emelia Gatley is Director of Operations at Websure, where she runs delivery across the agency’s UK and Bangladesh teams. The Websure Dashboard is the client platform built for our clients and offered to everyone with an MSA with Websure.