Five questions to ask before you let AI build your business software

A few weeks ago I had a call with the managing director of a mid-sized company. Around 80 employees, project business, an ERP system that had grown too tight over twelve years. He had done his homework: processes documented, requirements written down, a clear picture of what the new platform should do. Then he said something I hear more and more often: "With AI, you can build this kind of thing yourself now. I have seen what Lovable can do."

He is not wrong. You can. The question is what you end up with.

#What the Lovable scan found

This week, the German security firm Crissy Field published a study, reported first by Handelsblatt, of 159,041 projects built with Lovable, the AI app builder that promises you do not need coding skills. 24,664 of those sites sent database records to the browser as soon as the page loaded, with no login and no interaction. That alone is not a security issue, the data might be meant for public display. But with a few additional read-only requests, the researchers were able to retrieve more database content. They found 10,560 tables across 7,403 sites containing email addresses.

The examples are the part that sticks. A service provider had exposed more than 1,000 records with identity document details: passport numbers, expiration dates, nationalities. A German lifestyle forum leaked 80,000 user profiles and 200,000 private chat messages. A ticketing platform exposed tens of thousands of transactions with names, phone numbers, addresses and valid ticket codes.

The cause is not an exotic vulnerability. The apps store their data in Supabase, and tables created through migrations or the API have row level security switched off by default. The AI agent writing the app leaves it off, because switching it on breaks the feature it was asked to build. From then on, the public API key that every browser receives is effectively a master key to the database.

Lovable's terms make customers responsible for their apps and their data. Lovable told Handelsblatt the problem is industry-wide. Both statements are true, and neither one helps the company whose customer data is now public.

#This is not an argument against AI

I want to be clear about that, because the easy reading of this story is "AI code is dangerous, hire humans". That is not the lesson, and it would be dishonest coming from us. We build with AI every day. It is the reason custom software for a company with 80 people is affordable today, when five years ago it was not. A good process description can be turned into a working application faster than ever.

The lesson is narrower and more useful: AI has made the first 80 percent of software nearly free. The remaining 20 percent did not get cheaper, and that is the part your company actually runs on. Access rules. Data that cannot be changed after an invoice is printed. Migration from the old system. A login that goes away when an employee leaves. Someone who answers the phone on a Friday afternoon. None of that shows up in the demo. All of it shows up in the second year.

The scan is what it looks like when 7,403 companies skipped the 20 percent.

#Five questions that tell a prototype from a system

If you are comparing offers right now, whether from an agency, a freelancer, or your own team with an AI tool, these are the questions I would ask every one of them. Including us.

1. Who is liable when the numbers are wrong? Invoice numbers must be sequential. A printed invoice must not be editable afterwards. A final invoice after three supplementary orders must add up. These are not features, they are legal requirements in Germany (GoBD), and a tax audit does not care that the AI generated the code. Ask who signs for that.

2. How does my data get in, and who cleans it? Your old system has twelve years of customers, articles, open projects and history. Some of it is wrong, some duplicated, some in formats nobody remembers. Migration is the least glamorous part of any software project and the one most often left out of a 50,000 euro quote. Ask for it explicitly.

3. What happens in two years? Frameworks get updates. AI models get replaced. The person who prompted the app leaves. Ask who maintains the code when the original tool is no longer the current tool, and whether there is documentation and a test suite that a different developer could pick up.

4. Who answers the phone on Friday at 4 pm? When time tracking on the construction site stops working, your 25 field workers write their hours on paper again, and someone types them in on Monday. Ask what the response time is, what it costs, and whether it is written down.

5. Is there a test that proves the invoice is right? Not "we tested it". An automated test that runs every time the code changes and fails if a supplementary order no longer flows into the final invoice correctly. If the answer is a shrug, you are looking at a prototype.

Anyone who can answer these five questions clearly will build you software that holds. Anyone who cannot will build you a demo, and the demo will look great.

#What we do differently, and what we do not

We do not claim to be faster than an AI tool. We use the same tools. What we add is fifteen years of building exactly this kind of system for German mid-sized companies: document chains from quote to final invoice, time tracking for field teams, integration with existing ERPs that keep running in parallel until they are no longer needed.

And we price it the way the market now works: fixed price per module, not hourly rates that punish us for being fast. A document chain, a task module, time tracking with a mobile web app. Each one a defined scope with a defined price, running next to your current system, so you can stop after any step.

If you are in the middle of that comparison right now and want a second opinion on your requirements, send them over. We will tell you what fits into your budget, what does not, and what we would do differently. That costs you nothing, and it is useful whoever you end up choosing.