.png)
You describe the app, and by the afternoon it exists: something a friend can open on their phone and use. An AI app builder such as Lovable has made that leap real. A few years ago, getting this far usually meant finding a technical partner or paying a team; now a clear description can become working software. It can include a database and integrations, then be tested and published on its own domain. Current AI builders even check for common security problems. Calling this a throwaway prototype understates what has changed.
It also creates an unfamiliar problem. To turn a description into software, the builder must fill in whatever was left open. It can execute those choices correctly without understanding what they mean for the customer or the business. Because the result looks finished, a plausible default can pass for a decision somebody actually made.
Imagine a founder building a booking app for independent tutors. The generated version lets a student choose a time and pay. Then a tutor cancels after the payment has cleared. Should the app offer another tutor automatically, or return the money? Either answer can be coded correctly, but each creates a different promise to the student. If the prompt never made that promise explicit, the flow will still contain whichever rule seemed plausible.
The same thing happens in quieter parts of a product. An internal tool may give everyone who can sign in access to the same customer records. That is convenient with four colleagues and entirely wrong once contractors join. The missing work is deciding who should see each record, then enforcing it beyond the interface.
This is why Lovable's security guidance separates what happens in the browser from what must be enforced on the server. The platform can flag an overly permissive database rule, but it cannot infer the right permission from four current users. That depends on how the business works. These problems appear as soon as a useful product acquires its first exception.
AI is good at making the path described in a prompt feel complete. A marketplace can take a seller from registration to a live listing, while leaving what happens when two sellers claim the same item unresolved. Before adding a dispute flow, somebody must decide whose mistake the business is willing to absorb and when a person should intervene. Otherwise, the product turns an unresolved policy into faster buttons.
User behaviour introduces a different uncertainty. Suppose a planning app creates a weekly plan, but most people leave before generating another. Analytics can show where they stopped, not whether the first plan was irrelevant or useful enough that they did not need to return yet. Those explanations lead to opposite changes.
This is where a first version becomes especially valuable. Instead of debating an imaginary product, the team can watch someone use the real thing and test a specific explanation. AI brings that conversation forward by making the product available sooner. It does not decide what the behaviour means.
Our work with Simba Sleep began with an ambition to develop a service around better sleep, rather than ending the customer relationship when a mattress was delivered. "Personal sleep coach" sounded like a product, but it was still only a direction. Before choosing features, the team spoke to existing customers about the sleep problems they were trying to solve. That research made tracking the core function because useful advice needed a person's own sleep patterns.
That still left the question of how to track it. Focus groups showed that customers did not want another gadget or anything worn in bed. The response ruled out a route that might have looked perfectly sensible in a generated feature plan, so the team designed around the phone already beside them. The important work was not producing the tracking screen. It was finding the condition under which people would actually keep using it.
An MVP reached beta users three weeks into the project, while there was still time to respond to what they did. Six weeks after launch, the app was in the top 20 for health and fitness, with a 4.8 rating and more than 10,000 downloads. Its data then exposed a gap between the sleep people wanted and what they got: closer to six hours against a goal of around eight. Nothing in the dashboard said "build a campaign around this". The team connected that behaviour to the original ambition, and it eventually informed Simba's TryFor8 campaign.
An AI builder could produce that first tracking experience faster now, and that would be useful. It could not learn which sleep problem mattered by generating more features, or know that six hours was worth acting on until somebody connected the data to the product's purpose.
Once the first version exists, the useful work is to separate decisions from defaults. In the booking app, that means identifying which cancellation promise the flow currently makes and whether the business can honour it. In the planning app, it means finding out why people leave before changing the onboarding. Neither exercise begins with asking the builder for another version.
Nor does this require treating the existing software as disposable. A functioning build is a useful place to investigate the product because the assumptions are no longer hidden in a document. They are visible in what the app allows, what it refuses and what happens when a real person does something the prompt never mentioned.
The order of the work has changed. A first build can now arrive before the product has been fully defined, which gives a team something concrete to learn from much earlier. The risk is treating the builder's ability to complete the interface as evidence that the thinking behind it is equally complete.
Code can behave exactly as instructed while the product does the wrong thing. Finding that difference is what turns a generated first version into something people can rely on.
If you've got a working AI-built product and a real question about what it should do next, bring both to us: https://www.fortnight.studio/contact
