AI-Built Software, Part 2 of 7: the pros and cons of building on Base44, Lovable, Replit, Bolt and similar platforms when nobody on staff can read code

What these platforms are

Prompt-to-app platforms let anyone, whatever their technical skill, describe an app in plain language. In almost every case the person describes what the app should do and how it should look, not how it should work behind the scenes. The platform then goes to work, and a few hours later there are screens, a login, a database, and a URL you can hand to people. And yes, it really works.

These platforms have only been around for a few years, but in the last year or so they’ve gone from a parlour trick to something capable and usable. Base44, Bolt, Lovable and Replit are the ones you may have heard of, and new ones show up almost monthly. Each has its own strengths and weaknesses, but they share the same basic shape: the AI writes the code, the platform hosts the result, and the person building never has to see either. Making the code invisible is the product.

I should say up front that I don’t build on these platforms. My own work is on the developer path, which is the subject of the next article in this series. The time I’ve spent inside them has been reviewing clients’ apps, so the case in favour below leans on the platforms’ own showcases and on what users report, and the case against leans on my own experience.

The case for

There are plenty of success stories. The vendors’ websites have accounts like Replit’s story of a manager with no engineering background who built an internal dashboard over the company’s ticketing data in about two hours, or Base44’s story of a gift-book business that went from idea to paying customers in about a week, after months with developers had produced nothing. For a less biased view, I also spend time on Reddit reading what users say, and many of the accounts from people who built something to solve a problem of their own are happy ones.

These platforms clearly have a time and a place. They can get an app up and running very quickly, and just as importantly, for less than it would cost to pay a developer. The app is often built by the person who understands the problem best, without a requirements document or a lengthy approval process from IT. For internal tools, form automation, dashboards, or prototypes, the platforms often fit the work very well, and for those uses the honest answer is that you don’t need any help: build it on the platform and get on with your day.

The case against

The main selling point of a prompt-to-app platform is that the code is invisible, and that isn’t entirely true. The platforms give you easy access to the front-end code that builds the screens, and most will let you export it. But the parts that matter most, such as logins, security and database access, typically run on the platform’s own proprietary back end, and you don’t get to see that code at all. So when you build on one of these platforms, you’re tied very tightly to it. If you ever wanted to leave, you’d likely find your app unusable until you had rebuilt the entire back end. The vendors don’t hide this, and it’s understandable that they work this way: building on an existing back end is a large part of what makes it possible to build an app so quickly.

The second issue follows from who uses these platforms. They’re aimed at people without technical training, and nothing in the chat box teaches you how to recognize a security hole or test for a bug. For a utility used by internal staff, that may not matter much. For an app that handles sensitive information or is sold as a subscription, it can expose the business to real legal, professional and reputational consequences.

I saw this first-hand recently. A professional services practice had a client-facing subscription app built on one of these platforms, and it looked great. Once it was in use, though, the problems emerged. The security model had a number of bugs and gaps: when a user exported their data, a failure would sometimes include everyone’s; records meant to be immutable could be edited by going around the front-end forms; and the app’s email feature didn’t check who was calling it, so anyone could use it to relay spam or malicious email. Operational questions had never been asked either. The platform took its own backups, as these platforms do, but there was no way to say “restore this one client’s data,” no tested path to recovering from a failure, and the backups were the platform’s own and usable nowhere else. Nor was there any way to move the app to another platform if circumstances required it.

I don’t blame the person who built the app for any of this. They had no technical training and took the vendor at its word that they could describe an app and the platform would build it, and it really did produce a great-looking app. The front-end code was there for them to look at (although they couldn’t understand it), and the back end wasn’t available to anyone. That’s the question I said I’d keep returning to in this series: can the person responsible read and understand what was written, and do they? Here the answer was no, so nobody knew which questions to ask about security, nobody had the experience to test for the bugs, and nobody could fix them when they surfaced.

Which case is yours, and what comes next

Applied to the right problem, prompt-to-app platforms produce real results that look almost magical. Non-technical people can quickly build usable apps that would never have made economic sense before, and the people with the most domain expertise get to structure and streamline their own manual processes.

I don’t see the platforms as the villains here. The trouble starts when they’re used where they don’t fit. A tool for a dozen staff that replaces a spreadsheet is probably fine, but anything that touches customers, money or personal information has the potential to be a problem. On that side of the line, where a bug or a security failure carries a real price or where legislation such as PIPEDA and CASL applies, someone with technical expertise has to be involved before the app goes live. The app will happily send email in contravention of CASL and handle personal information carelessly in contravention of PIPEDA, and nothing in the tool will warn you.

These platforms also make it easy for apps to spring up alongside the company’s systems without anyone in IT knowing, holding data that nobody reconciles or keeps in sync. Finding what’s already running in your building, and the one-page policy that keeps it from becoming a problem, gets its own article later in the series.

In the next part, I’ll look at companies that have developers available: the tools their technical staff or contractors are using, and where those tools are and aren’t appropriate.