Build with AI · Chapter 10 of 13
Lovable’s early launches: why a clever demo was not enough
Why applause did not finish the job: turn Lovable’s early setbacks into a three-state first-use test, a small budget and a clear decision about what to build next.
About 8 minutes · school-level background
Edition 2026-10-28.1 · Checked 2026-10-28
What you will understand
Separate an impressive demo, a first useful result and repeated use, then design a small product test around a real job.
In this lesson
- Someone says “wow”. What happens tomorrow?
- What Lovable says it learned
- Turn the promise into one complete job
- Make the first minute useful without a user history
- Set a time budget before building the clever part
- Count a useful first result and a return separately
- Find the smallest next test
- Make the next version easier to trust
Build the idea
Someone says “wow”. What happens tomorrow?
You show a friend an app made from a sentence. Buttons appear, colours match and a page opens. They say it is amazing. The next day they return to the spreadsheet they already use. What went wrong? Perhaps nothing went wrong with the demonstration. It answered whether a page could be generated. Your friend needed an answer to a different question: whether they could rely on this thing to finish an ordinary job again next week.
For an AI project, applause can arrive before usefulness. That makes the early stage exciting and confusing. A short video can reveal a real capability while leaving out the parts that make a service dependable: saved work, corrections, permissions and a clear next step. You can learn from that gap without having a company or paying for an advertisement. Start by describing the job someone wanted finished before they saw your demo.
A page looks convincing
Someone tries a real job
They can correct and save it
They choose to use it again
A simplified reading aid. Follow the article for sources, conditions and limits.
What the source reports
What Lovable says it learned
In its company account published on 22 January 2025, Lovable described two early GPT Engineer launches that struggled to gain traction. Some people saw a fun prototype tool while intended users wanted usable products. The team described changes to the product, positioning and distribution together. This retrospective cannot isolate which change caused later success or establish audited profit.
In a Chinese design essay dated 17 April 2026, Tian Pan discusses the cold-start problem: newcomers need value before a service has their interaction history. His discussion of usable defaults and explicit choices is an author’s design argument, not a measured result from Lovable. It suggests a practical question: what works for your first visitor?
Original report: Lovable: two failed launches and product-led growth · Tian Pan: the cold-start trap in AI products
Worked teaching example
Turn the promise into one complete job
Imagine a fictional school club that lends cameras. An attractive prototype displays three camera cards and a Reserve button. The actual job is harder: a member needs to know which camera is available on Friday, reserve it without a double booking and see the reservation tomorrow. These are still small requirements, but they connect the screen to a result. If the page forgets the booking when refreshed, the demonstration works while the intended job fails.
Write the first acceptance check in plain language: reserve a fictional camera for a chosen date, refresh the page and confirm that the reservation remains; then try a conflicting reservation and check that it is refused. Use invented names and dates. Ask your assistant to explain where the reservation is stored and what happens when storage is unavailable. The assistant can generate a prototype, while you inspect whether the promised behaviour actually occurs. You do not need to build a whole marketplace to learn this.
Use the idea
Make the first minute useful without a user history
An empty page that says Tell us everything about your club gives a newcomer homework before showing a benefit. Try a more concrete start for our fictional camera club: two buttons labelled Try a fictional reservation and Start an empty real form. The first opens invented cameras, dates and members. The second starts with blank fields. Label the demonstration clearly and keep its data separate. A sample booking must never appear as a real reservation just because somebody pressed a button.
Give your assistant this brief: build a local camera-booking mockup with three visible states. Available means the fictional camera can be reserved for the selected date. Reserved means the page shows the saved choice and the same camera cannot be booked again for that date. Unavailable means the page cannot confirm a booking and says what the user should do next. A click animation is not evidence that a reservation was saved. Ask the assistant to explain its storage choice before trusting the mockup with real work.
Now predict what should happen after each action. Reserve Camera A for 12 November, refresh, and look for the same camera and date. Attempt Camera A again for that date; it should refuse the conflict. Try Camera B on the same date; that booking should remain possible. Then test a missing date: the page should ask for it without silently selecting today. Run these checks with fictional data. A local mockup can explore these behaviours without proving that two different browsers would share reliable booking state.
If confirmation fails, a useful fallback is a draft booking request that the user can copy and take to the organiser. It must say that no reservation has been confirmed. The page can still help someone gather the needed facts while being clear about what remains undone. This is the first-visitor question made concrete: can a person reach a useful, correctly labelled result before the tool knows their preferences? Adding recommendations would not repair a missing date or a false confirmation.
Worked teaching example
Set a time budget before building the clever part
For this invented exercise, cap the first pass at 90 minutes: 15 to write the booking brief, 30 to ask an assistant for a mockup and inspect it, 30 to run the checks, and 15 to record a decision. The four parts add to 90. If a check is still failing when time runs out, save that state and describe the failure. Completing the exercise means learning what works and what needs repair; it does not require a public launch. Use a document or an existing local tool, with no new purchases.
Suppose the attempt uses an imagined £0.80 of model service. Value your own time at an illustrative £12 per hour. Ninety minutes is one and a half hours, so time is valued at £18; the combined planning cost is £18.80. Of that total, only £0.80 would be cash paid for model use in this invented scenario. If you use an existing subscription with no extra charge, the marginal cash cost could be zero while your time still matters. These numbers are not Lovable’s costs or a current provider quotation.
Assume you define four checks before starting: saved booking after refresh, conflict refusal, a second camera still bookable, and a clear missing-date request. If three pass and one fails, the finite test pass fraction is three divided by four, or 75%. That does not mean the product is 75% reliable. If the failed check allows double bookings, it blocks the promised job. Keep the individual outcome and its consequence beside the fraction; a convenient average cannot repair a critical failure.
Ask an assistant to play a confused first visitor and it may reveal unclear wording or a missing step. That is useful rehearsal. Record it as a simulated walkthrough, not evidence that a real customer wants the tool. A sensible decision might be to repair storage before adding features, stop because an existing calendar already does the job, or later ask a willing organiser to compare the mockup with their current process. The small project pays off when its next decision is better informed, even if the right decision is to stop.
Worked teaching example
Count a useful first result and a return separately
Suppose, in a fictional trial, 100 people try your tool. Forty finish a first useful booking, and 12 of those 40 return during the following week to do another relevant job. First-use completion is 40 out of 100, or 40%. Return among those first successful users is 12 out of 40, or 30%. Return among everyone who tried is 12%. The three numbers describe different denominators. None of these numbers comes from Lovable, and none proves that a user would pay.
Before calling a return meaningful, define the job and the observation window. Opening a tab by accident is different from completing the next booking. A weekly club task should not be judged by whether people return every hour. Equally, someone returning because the first output was broken is not the same as someone returning because it was useful. Keep the reason alongside the count. This helps you choose a repair instead of celebrating a number whose meaning has changed.
Use the idea
Find the smallest next test
If people never reach a first useful result, watch where the path becomes confusing. Perhaps the landing page promises too many things, the example uses unfamiliar data or the first step asks for an unnecessary account. Choose one obstruction and test a clearer path. If the first result works but nobody has a reason to return, inspect the frequency of the need. A one-off task can be valuable; it simply supports a different product from a tool used every week.
When product, message and distribution change at the same time, a later improvement cannot tell you which change caused it. For your own small trial, keep a dated record of what changed and why. Where practical, change one major assumption at a time. Where that is impractical, preserve the uncertainty. The useful question is which next observation would change your decision. It might be a successful repeated task, a clear rejection or evidence that your intended user already solves the problem easily.
Use the idea
Make the next version easier to trust
A beginner can produce a useful product brief without writing production software. Include the intended user, the recurring problem, one input example, one accepted output and one failure that must be visible. Add who checks the result and what the person does when the tool cannot complete it. Your assistant can help turn that brief into a mockup or test script. Keep the exercise local until you understand what information the tool stores and which actions it performs.
For a public contribution, a well-explained failure can help another builder as much as a polished screenshot. Save the exact example and the smallest steps that reproduce the problem. Explain what still works and what would need checking before real use. This turns a disappointing first version into reusable knowledge. The most helpful ending to an early product experiment is a clear decision: improve one demonstrated bottleneck, try a different need, or stop because the proposed job is already served well.
Words you can now use
- Acceptance check
- A concrete test of whether the promised job was completed.
- Activation
- Reaching a defined first useful result; the definition depends on the product.
- Retention
- Continued use over a stated period, measured for a clearly identified starting group.
- Cold start
- The first-use situation where a service has little or no history about a new user or item.
Check your understanding
Three of four booking checks pass. Why might the product still fail its promised job, and what could a simulated visitor actually establish?
Show the explanation
If the failing check permits two people to reserve the same camera and date, it defeats the booking promise despite a 75% test pass fraction. Save the failed input and repair that behaviour before adding features. A simulated visitor can expose a confusing path, but cannot establish real customer demand, retention or willingness to pay. The 90-minute, £18.80 plan is a fictional bounded exercise, not a measured startup outcome.
Read the original sources
- Lovable: two failed launches and product-led growthCompany retrospective · Published 2025-01-22 · Checked 2026-10-28
- Tian Pan: the cold-start trap in AI productsChinese author design essay; not a measured case study · Published 2026-04-17 · Checked 2026-10-28
Try it with your own assistant
Select and copy this bounded exercise. A normal chat assistant is enough to start.
In at most 90 minutes, specify a local fictional camera-booking mockup with available, reserved and unavailable states. Check saved state after refresh, refusal of a conflicting booking, another camera on the same date and a missing date. Keep demonstration data separate and make unconfirmed bookings explicit. Use existing tools without purchases or private information. Keep failed checks and a repair-or-stop decision; a simulated visitor is rehearsal, not proof of customer demand.
Keep the task brief, supplied inputs, checked output and unresolved questions together. Using this exercise does not submit anything to WRS.