To take an AI-built product to real customers, first verify one complete journey: from the user’s entry to a saved result and its subsequent handling. Then address problems in data, access and integrations, and prepare deployment and recovery. Using AI to build the prototype does not, by itself, justify a rewrite.
Lovable, another builder or an agent in your editor may have helped clarify the offer and produce a useful foundation. The question now is which parts are usable, which are known only from the demo, and which failures are unacceptable for customers. This is a review of an existing product; the broader question of building a product entirely with AI belongs to an earlier decision.
Keep what already solves the problem
Before requesting more changes from an agent, preserve the current version: source code, data structure, environment configuration and connected services. Record which screens use real data, which use samples and which actions are simulated. This makes the remaining work assessable without losing what you have built.
The interface, offer wording and a clear user journey may already be suitable for the first release. An access problem in one table does not prove that the entire stack needs replacing. Redesign needs a specific reason, such as a data model that cannot separate customers belonging to different organisations. Our guide to improving a product or rebuilding it explains the criteria.
Test the main journey beyond the demonstration
Suppose you have built a consultation booking service. A visitor chooses a time, submits contact details and sees a confirmation; a staff member receives the booking. This is a hypothetical example. Its operational result is a saved booking in an available slot that staff can handle and the customer can find on their next visit.
Test it with a fresh account under conditions close to those customers encounter. Repeat the journey after refreshing the page and signing out. Then exercise paths that a demonstration often leaves out:
- Two customers select the same time simultaneously.
- A user presses the confirmation button repeatedly.
- The connection drops while a booking is being saved.
- A customer returns after their session has expired.
- A staff member reschedules or cancels an existing booking.
Define the correct outcome for each path in advance. A repeated click should not create a second booking, and unavailable time should produce a clear response. If the desired behaviour has not been decided, it is a product-owner question that a code fix alone cannot settle.
Verify data rules and access boundaries
Interface checks need enforceable system rules
A disabled button and browser-side field validation help the user. Critical conditions—available time, permitted actions and the right to perform them—must be enforced where data is stored. Otherwise an altered request can bypass the interface. Lovable’s recommendations describe server-side validation and the division of responsibilities between browser, server and database.
In the booking example, checking availability and reserving the time must work together: two concurrent requests should not both receive the same slot. The implementation depends on storage. Acceptance should verify a repeatable outcome rather than the name of the chosen technical mechanism.
Check access with different accounts
In a test environment, create two customers and a staff member. Each customer should see their own bookings and be unable to retrieve someone else’s by requesting data directly. Staff need only the permissions appropriate to their job. Hiding a menu section does not restrict access to the underlying records.
With Supabase, row-level security, or RLS, defines access to individual records. Privileged server access can bypass these rules, so server operations also need permission checks. The Supabase documentation explains this distinction. Working sign-in does not verify every access rule in your application.
Keep secret credentials outside the public application
Secret keys for payments, email or an AI service belong in protected configuration and should be used by server-side code. Also review API responses and logs for accidental exposure. Not every key is secret: use the provider’s documentation to distinguish public identifiers and keys from privileged credentials.
Our OpenAI image integration case study illustrates server-side separation: provider calls, validation and limits run outside the browser. Your product needs the same examination of boundaries, adapted to its particular integrations.
Verify payments and external event handling
A confirmed payment must reach the order state
If the consultation requires prepayment, a “Paid” screen alone is insufficient for accounting. Connect the order, confirmed payment and the action made available to the customer. Someone can pay and close the tab before returning to your website. For example, Stripe recommends server notifications for order fulfilment rather than relying only on the post-payment page.
Test success, rejection, cancellation and delayed confirmation for the selected payment method. Make the condition for changing state explicit. If the first release has no online payments, do not build them in advance: define how staff record settlement and what the customer sees.
A repeated notification must not repeat the action
An external service may deliver the same event more than once. The handler needs to verify authenticity and recognise an action already performed. Stripe’s webhook documentation covers signature verification and duplicate delivery. Apply the rule so a repeat neither creates another booking nor grants access twice.
Decide separately what happens when email or the CRM is unavailable. A saved booking should remain visible to staff, and a notification failure should be detectable. Where retrying could create a duplicate in another system, establish the first request’s outcome before retrying. Unconditionally repeating the entire operation can make the problem worse.
Prepare deployment, observation and recovery
Test and customer-facing environments need clear boundaries between their addresses, configuration, data and access. Before release, verify registration, email, integrations and the main journey in the intended environment. Review backup capabilities and plan limits too; these are among the checks in the Supabase production checklist.
Record how to deploy again and recover. Rolling code back does not necessarily restore the previous database structure: data changes need separate consideration. For important storage, test restoring a backup in another environment. The existence of a backup file does not show that it can restore an operational service.
After launch, someone needs to learn about missing bookings or payment failures. Define the events to observe, error alerts and a way to relate a problem to a particular operation. Full customer messages and secret values should not be copied into logs for diagnostics.
Use the platform’s built-in checks. Lovable provides Quick scan, triggered during publishing, and the more detailed Deep scan. These tools help find issues, but its own documentation does not treat them as a substitute for a thorough security review. A successful scan also does not establish that two customers cannot receive the same slot or that staff will notice a missing enquiry.
Turn the findings into a readiness table
“Ready” requires a verified result. “Needs verification” means evidence is missing; “Blocks launch” means an observed problem is unacceptable for the chosen journey. The table below is a booking-service template, not a report about a client application. Adapt the checks to your product.
| Check | Ready | Needs verification | Blocks launch |
|---|---|---|---|
| Main journey | Customer and staff receive the intended result. | Only the owner’s demo has been tested. | A booking is lost or never reaches staff. |
| Data persistence | The result survives signing in again. | The location of actual data is unknown. | The core result exists only in the browser. |
| Access | Roles view and change only what is permitted. | Roles have not been tested separately. | A customer can retrieve another’s private data. |
| Retries and concurrency | A slot and an action are handled consistently. | Only a single successful request was tested. | Duplicate bookings or repeated fulfilment occur. |
| Payment, when needed | State is tied to provider confirmation. | Only a test button has been checked. | Access is granted without confirmed payment. |
| External services | Failures are visible and retries controlled. | Only an available service was tested. | A failure silently destroys the customer’s result. |
| Deployment and recovery | Deployment and recovery procedures are tested. | Backups and procedures exist but are untested. | Required data cannot be restored by the chosen method. |
An unknown in a critical row also needs a decision before launch. Complete the check, leave the unverified feature out, or restrict the release to a journey already verified. “We will improve it later” does not explain what happens to the customer when it fails.
Commission one improvement stage with a verifiable result
A useful brief starts with the prototype URL, code, roles and one main journey. Share credentials securely; do not put secrets in a public task description. Include known failures, connected services and an acceptance criterion for the first operational release.
For the hypothetical service, the first stage could deliver reliable booking: persistence, protection against double allocation, access boundaries and a result visible to staff. Include payments when they are essential to completing that journey. Choose redesigns, additional sections and new channels after resolving obstacles to the main outcome.
Before making changes, agree the scope, acceptance checks and release procedure. If actual business logic is still missing and you only have a screen demo, the work may fit building a first product version. Where the foundation already works, the product improvement service helps select and implement a contained stage. This follows the approach of AI development owned by a specialist.
Before the first customers arrive, establish a verified path from their action to a durable result. The readiness table separates the working foundation from the unknowns and helps you commission the changes that are necessary to complete that path.
Practical decision checklist
- Preserve the current version and identify simulated behaviour.
- Test one customer journey across normal and failure paths.
- Record evidence, unknowns and launch blockers.
- Agree and verify one complete improvement stage before release.
Sources and methodology
The following references support the facts and technical details in this article:
Prepare your existing product for real customers
We review the main journey, identify priorities and agree a first improvement stage with a result you can verify.
Discuss improving the prototype