Article
Finish an AI-Built Website or App
You have a working preview and a list of things that still break. Use this handover guide to buy a defined completion stage, keep useful code, and agree what ready to launch means.
If you built a website or app with Codex, Cursor, Lovable, Bolt or another AI tool and cannot finish it, the next purchase should be a defined engineering stage. Start by showing what works, what fails and what a customer must be able to complete. A developer can then assess the existing code before recommending repairs, a partial rebuild or a new implementation.
The tool name does not tell us whether the code is usable. A working product can include AI-generated code; a polished preview can still be missing its payment handling, permissions or deployment configuration. This guide is about arranging the handover. Our separate AI app readiness guide explains the technical risks in more detail.
Choose the next step from the actual problem
| Your situation | Useful first engagement | What to ask for |
|---|---|---|
| You cannot tell whether the app is safe to launch | Production-readiness audit | Ranked findings, scope boundaries and a repair recommendation |
| The site works but needs a booking or quoting workflow | Feature discovery and implementation scope | Workflow, acceptance examples and a price for the agreed stage |
| A specific step fails reliably | Focused diagnosis | Reproduction, cause, repair and a regression check |
| Nobody can build or deploy the exported source | Repository and hosting handover review | A reproducible build and a decision on what can be retained |
Our Standard Vibe Coding Audit is $200 + GST for one eligible app. It covers all seven published surfaces: auth and secrets; access control and injection; privacy, cookies and residency; payments and billing; technical debt and tests; bugs and reliability; hosting, backups and observability. The output is a ranked report, salvage-versus-rewrite recommendation and itemised follow-on quote, normally within one to two weeks after access. Repairs and new features are separate work.
Prepare a handover a developer can use
A short screen recording is more useful than a long prompt history. Show the customer journey from entry to the point where it fails, explain what should happen, and say whether real customers or payments are already involved.
- Product: preview URL, target customer and the one workflow the first release must support.
- Source: repository or export, build instructions and the last version you know worked.
- Accounts: who owns the domain, hosting, database, email service and payment account. Invite access through each platform; do not send passwords or secret keys in an enquiry.
- Behaviour: numbered bugs with reproduction steps, expected results and screenshots without customer data.
- Constraints: launch date, budget range, tools that must stay and anything you have promised a customer.
- Data: whether production records exist, who can authorise a backup, and whether a separate test environment is available.
Keep an export of the source and agree the version under review. If you keep generating changes in parallel, label those changes and arrange how they will be merged. Otherwise a developer may repair yesterday's code while today's prompt reintroduces the same defect.
Keep the useful code; assess the expensive seams
A sensible review separates the interface, business rules, data model and infrastructure. An attractive frontend may be worth retaining while checkout or access control is replaced. A rewrite needs a reason: an unmaintainable dependency, missing source, a data model that cannot represent the workflow, or repair costs that exceed a better scoped replacement.
Ask the developer to demonstrate the evidence behind that recommendation. GitHub's guidance on reviewing AI-generated code calls for functional checks, review of context and dependencies, and human oversight. A second model saying the code looks fine is not a substitute for exercising the workflow.
For customer-facing products, our Melbourne app development service covers web and mobile delivery. For quoting, approvals, staff dashboards and API connections, custom software development is the more useful starting point.
Write a completion stage you can accept
Replace “finish payments” with observable behaviour. For example: “A customer can pay for the agreed service, see the correct confirmation, and receive access once. Failed or repeated payment notifications do not create a second order.” Follow the same pattern for accounts, bookings and administration.
- List the customer and staff journeys included in this stage.
- Attach examples for successful, declined, cancelled and repeated actions.
- Agree which devices and browsers matter, including a real phone and keyboard-only use.
- Specify the deployment environment, backup and rollback procedure.
- Define handover: code, account ownership, operating notes and the agreed defect-support period.
Our booking system brief and customer portal guide turn two common unfinished features into acceptance examples. The Clean Fridays case study shows our published work on booking, payments, cleaner assignment and operational administration. It demonstrates implementation scope; it is not a promised result for your product.
Hiring help from Melbourne or Sydney
Choose on the quality of the diagnosis and handover, as well as communication. AL Phesda is Melbourne-based and works remotely with businesses in Sydney and across Australia. Agree a shared review time, one decision-maker and a written list of accepted changes. Remote delivery still needs a visible working build and a clear owner for each account.
If the main issue is the marketing site, start with website development in Melbourne or our Sydney website delivery page. If you already have an app, book a Discovery Session with the preview, the failing journey and the outcome you need. We can establish whether an audit or a defined feature stage is the useful next step.
AI build completion FAQs
Can you finish a website built with Codex or Lovable?
We can assess an existing build when source and the necessary account access are available. The review establishes what can be kept and what needs work. The platform used to generate it does not, by itself, decide whether it needs a rebuild.
Does the $200 audit include fixing the app?
No. The published standard covers the seven inspection surfaces and a written report for one eligible app. Repairs, added functionality and deployment work are quoted separately from the findings.
Can I keep improving the app with AI afterwards?
Yes, with a controlled workflow: a separate branch or test environment, focused reviews and checks for important customer journeys. Agree how your changes and the developer's changes will be integrated before both parties start.
What if I only have a hosted preview?
First establish whether the platform allows a usable source export and what backend configuration sits outside it. The standard audit has defined source and access requirements; a preview alone may need a separately scoped review.