You've built an app with AI

Something new has started happening in conversations with clients and prospective clients this year: people arrive having already built something. Founders and business owners who would once have turned up with a requirements document, or a photo of a whiteboard, are now turning up with a working prototype they've made themselves using AI tools. One of our clients did this recently, and it worked brilliantly. We're building a product with him that includes a step-by-step wizard for putting together a role-playing game campaign, and rather than sketching wireframes, or leaving us to have a first stab at the flow, he mocked the whole thing up himself in Lovable, an AI app builder you steer by describing what you want in plain English. What came back was a set of "working" screens - working in the sense that you could click through the wizard and feel how it was meant to behave, even though there was nothing real underneath - and as a way of communicating his vision it was more effective than any document he could have written.

If you're a founder or business owner sitting on an idea, tools like this are a superb way to get it out of your head and onto a screen. The interesting questions start afterwards, when the prototype needs to become a product.

What you've actually built

Tools like Lovable, Bolt and v0 are remarkably good at producing an interface that looks and clicks like a real product, and they are moving fast: these platforms are now genuinely full stack, able to wire in a real database and user accounts and publish your app to a live URL. So people tend to arrive at the next stage in one of two states. Some, like our client, have used the tool as a prototype in the truest sense - a way of pinning down a design and communicating it. Others have gone further and launched: the app is live, real people are using it, and the idea has been tested in the way that actually counts.

Both put you a long way ahead of where a document would. A clickable prototype is a specification that beats any written spec I've ever been handed, because it shows what you want rather than describing it, and far less gets lost between the spec and the build. That's exactly what our client's Lovable build did for us: he never intended it to be the product, it existed to show us what to build, and we're now building the real thing in Laravel and React with his prototype as the reference. A launched app with real users proves something bigger again: not just what the product should be, but that people actually want it.

The gap between a demo and a product

Either way, turning what you have into something a business can run on means facing a set of questions that the tools have quietly answered for you with defaults. How do you make sure one customer can never see another customer's data? Are the API keys and payment credentials somewhere safe, rather than sitting in the code? What happens when something fails, and what will it all cost to run each month as it grows?

AI tools will cheerfully generate answers to all of these, and the answers are confident whether or not they're right - if you don't build systems for a living, you have no reliable way of telling the difference. Security is where that bites hardest: in 2025 a security researcher found more than 170 live apps built with Lovable whose databases could be read by anyone - personal data, API keys and payment details, no login required - because the generated databases shipped with row-level security switched off. If your app is already live, these questions aren't waiting for you somewhere in the future: they're being answered right now by defaults you may never have looked at.

Why move to a bespoke platform

A fair question at this point is why you would move at all, because Lovable and its peers will happily keep hosting your app, and the paid plans go a long way. If the platform is serving you well and nothing is hurting yet, staying put for now is a perfectly reasonable choice - plenty of products should prove themselves a bit further before anyone commissions a build.

When the move does make sense, my honest answer on why is dependency. An app that lives inside an AI app builder depends on that platform's pricing, its roadmap and its choice of underlying services, and none of those are in your control. The platforms will let you export the code they generate, which softens the lock-in, but what comes out is rarely something you'd want to run a business on as it stands. A bespoke platform built on a major cloud provider like AWS is a different kind of commitment: you still depend on the provider, but you own the code, you own the account it runs in, and you keep the freedom to change developer without losing either.

There's also the question of who you call when something breaks. A platform gives you a help centre; a development partner gives you someone who knows your product, picks up the phone, and stays involved after launch - keeping the thing patched, watching the costs, and evolving it as the product grows.

Keep the prototype, bring in help

If this is where you are - a prototype that has done its job, or a live app that's outgrowing the platform it was built on - the design work is already done, pinned down in something clickable rather than a document, and if real users have been in it then the market question has answers too. What comes next doesn't have to mean commissioning a big build on day one. The engagements we take on range across:

A consultation and review - a look over what you've built and where it runs, with straight answers on security, running costs and what would need to change for it to grow.
A development spike - a short, focused piece of work mapping your prototype onto AWS services, so you can see the shape and cost of the real thing before committing to a build.
A phased build - moving the product onto a bespoke platform in stages, keeping everything the prototype got right and putting proper foundations under it. If your app is already live, this includes migrating the data and cutting your users over carefully - migration work of the kind we've been doing for years.

A rebuild is also the moment the design improves, because an experienced team brings things to the table that the AI tools don't. We know how people actually behave in browsers, and the UI and UX patterns we've watched succeed and fail across years of building products. We also know where a design will need to bend to reality - what the data model can support, where an API will struggle to respond quickly, what becomes expensive once real traffic arrives - and it's far better for those constraints to shape the design now than to surface after launch.

This is work we do at Si Novi, and the conversation starts at "here's what we're building" rather than at a blank page. If you've built something with AI and you're wondering how to take it the rest of the way, I'm always happy to take a look and talk it through.