If dopamine hits are what you're after, watching a working web app appear in front of you in minutes beats doom-scrolling, especially if, like me, you can't code.

More than the speed, it hit me that tools like this could reinvigorate the culture of innovation inside businesses. Not because everyone suddenly becomes an engineer, but because more people can contribute ideas in a form others can test.

Much of my career has revolved around developing digital products during the massive transformation the media industry has seen over the last twenty years. I’ve worked closely with product teams and developers and developed a deep, practical understanding of how digital products get built inside businesses.

But I’ve never been a coder. In fact, about ten years ago I consciously chose not to go down that road. My logic was simple: if we can describe something clearly enough, eventually we’ll be able to build it. Just look at voice-activated tech like Alexa, and now chat-based large language models.

That moment has now arrived. Non-coders like me can build working software without writing code.

The emerging term for this is vibe coding, using a chatbot to describe what you want to build, then letting the software write the code and assemble the application for you. Just like writing with an LLM, you start with a structured prompt and iterate your way towards the result.

Now before I enrage a whole coding community, I should be very clear that I know perfectly well that this doesn't mean I'm a developer by any stretch, but it does allow me to deepen my understanding of digital product. I think vibe coders need to maintain a certain degree of humility with respect to what's going on under the hood and behind the chat window.

For vibe coding to work well, your initial prompt needs at least two ingredients: a detailed product requirements document and some wireframes.

Recently I’ve been using Replit as my coding environment, starting with an introductory course in vibe coding from DeepLearning.AI. I’m also halfway through IBM’s free Python-for-Data-Engineering course, which has given me enough foundational understanding to feel confident working with code, even if I’m not the one writing it.

There are other good vibe-coding platforms like Loveable but Replit has been my home so far.

So far I’ve built several prototypes, all in hours rather than days:

• A simple scorekeeper for our sales training webinars, collecting voted scores from participants and showing totals in a league table

• A simple CRM to track my pipeline and record interactions

• A performance dashboard for a sales team

• A prototype app for warehouse pickers that finds the quickest route around a warehouse to collect the items on an order list

This opens up a whole world of rapid prototyping, experimentation, and faster innovation. But the deeper shift is cultural: you can normalise building small things, trying them, learning fast, and improving them in public, rather than debating them to death in meetings.

So how do you do it? The steps are surprisingly simple.

Step one: start with a real problem worth solving

First, you need a hypothesis: a business problem you can solve, or a process you can simplify or accelerate with a piece of software. This step matters because there’s no point building something you don’t need. Make sure the problem actually requires software rather than, say, fixing a process or removing a step.

The beauty of vibe coding is the low cost of exploration. You can build a working prototype in hours rather than days. That makes it easier for teams to run more experiments, and to learn by doing, rather than waiting for the perfect answer.

But even then, ask yourself: why build anything at all if you don’t need to?

Step two: write your product requirements document (PRD)

This is where you capture exactly what you want your app to do and how it should behave. If you’ve never written a PRD before, an LLM can be a great partner. I used Gemini on a day when ChatGPT was down.

As with article writing, I’d recommend using voice mode and asking the LLM to act as a product coach, someone who asks smart questions and then synthesises your answers into a first draft.

One important thing to remember: your vibe-coding environment doesn’t have the same context as your favourite GPT. For instance, we use the term “C2C” at Positive Momentum for a client meeting (“coffee to cash”). ChatGPT now understands that. Replit won’t. So your documentation must not rely on assumptions. If needed, add a paragraph of context at the top.

It’s also worth checking technical feasibility. I explicitly asked Gemini to ensure the approach in the PRD aligned with how Replit prefers to work.

Finally, be ruthless about V1. With my CRM I had all sorts of grand ideas, latest news stories, conversation tactics, suggested next moves, but I kept almost all of that out of the first version. I’ve since added the news feature, and recommendations will follow soon.

Build layer by layer. Make sure each layer is stable before adding the next. Otherwise you risk creating problems in all directions. You’re building a prototype, not boiling the ocean. And culturally, that discipline matters too: small releases, clear learning, steady momentum.

Step three: produce your wireframes

Wireframes are simple low-fidelity sketches showing what each page should look like. LLMs can generate text-based wireframes, but they’re not brilliant visually. Any product person will tell you to use Figma, but ChatGPT was able to generate decent ASCII wireframes, like drawing pictures on a ZX80 in the 1980s.

For my first app, I sketched the wireframes by hand on my iPad and exported them as a PDF. For the second, I simply screengrabbed the ASCII diagrams.

A crucial part of steps two and three is reviewing everything to make sure it makes sense. Even as a non-technologist, I spotted and corrected a couple of odd assumptions.

Step four: upload everything and start vibe coding

Now you’re ready. Upload your PRD and wireframes into Replit, start a chat, and off you go. The magic is seeing the first version of your app appear in the preview pane within minutes. As with any prompting, the quality of the output depends on the quality of your inputs. That’s why the earlier steps matter.

From there, it’s continuous iteration. Your app evolves inside a development environment until you choose to publish it. Publishing is the moment your app goes live on the web at a URL. You can keep iterating in the dev environment and publish again when you’re happy.

Avoid pushing too many updates at once. That’s when things break.

Replit also creates fallback points, which is incredibly helpful. If something goes wrong, roll back to the most recent stable version and try again.

Once you’ve got a functioning prototype, put it in the hands of actual users and gather feedback. If you’re serious about innovation culture, this is the moment that counts - getting real users to give real feedback, which you can really learn from.

A note on tech teams and organisational reality

It’s worth saying this out loud: your tech team needs to be aware of and comfortable with what you’re doing. Innovation cultures collapse quickly if people feel bypassed or exposed.

At ITV News, we once built a working prototype of a possible future ITV News website. Journalists used it in real time in the newsroom with real stories, but crucially it didn’t touch any of ITV or ITN’s systems. No integration, so no risk.

If your prototype takes off, meaning it works and people actually like using it, then comes the adult conversation about building the real version: secure, scalable, production-ready. Who builds it, and how it fits into your wider technology architecture, are items on the agenda now.

If you’re trying to kickstart innovation, one practical move might be to run short, tightly-scoped prototyping days. Pick one pain point, build a V1, test it with users, and treat the output as a learning tool, not a product. It’s a way of turning “we should do something about this” into something concrete, quickly, without pretending you’ve solved the whole thing.

The point is this: vibe coding gives businesses a powerful new capability. Rapid prototyping, fast learning and accelerated innovation. But it also gives leaders a practical way to shift culture, towards curiosity, experimentation, and shared ownership of improvement.

And as someone who’s spent most of his career in digital transformation, I’d argue this is a capability worth adopting.