Vibe coding
Use Lovable Plan mode to review a business change before it is built
Turn a request such as adding deposits into a plan with clear decisions, affected journeys and acceptance checks.
Zocri · 2 min read · Sources checked
Make the change concrete
Lovable documents Plan mode as a planning step that leaves code unchanged until the plan is approved and the product switches to Build mode. Use that boundary when a request changes money, access or an existing customer promise. Adding a deposit to a consultation app is a good example: the button is the smallest part of the decision.
Write the current journey first. A customer requests a consultation, the owner approves it, and payment happens later. Then describe the proposed journey and identify the exact point at which money becomes due. Keep optional redesign work outside this change.
Ask for the affected journeys
Request a plan covering the customer, the owner and an existing booking. Ask what happens when payment fails, the owner declines a request or the customer reschedules. Require the plan to explain whether old bookings keep their original terms.
Review the words customers will see. A request received message should not imply the appointment is confirmed if approval is still pending. Decide whether a deposit holds a slot, pays for work already done or simply records an intention. Those are different business rules.
Approve decisions you can test
Convert each important decision into an example. A customer with an unpaid deposit should see the agreed pending state. A customer who has already paid should not be asked twice. An owner should find the payment status alongside the correct booking.
Ask the plan to identify external setup and unresolved questions. Treat a listed payment connection as a dependency until the relevant account and test journey have been checked. If the plan cannot explain what happens to a cancelled deposit, settle that policy before implementation.
Keep approval separate from acceptance
Save the approved decisions in a short change note. After implementation, run the examples on the new version and recheck the original booking journey. Record what was observed, which account was used and whether you tested a preview or the published app.
If the result differs from the plan, describe the difference directly and ask for a focused correction. Avoid adding a new feature to the same request. A useful plan becomes a reference for judging the finished change, and a record for the next person maintaining it.