Built something with AI that isn't ready yet?
Share what you built, and we'll reply with the next step.
The cost to finish an AI-built website or app depends on what's left, which a screenshot or a demo video can't show. A marketing site that needs forms, speed, and search setup is a small job. An app with accounts, payments, and private data needs more, especially when access rules or integrations have to be rebuilt. Price comes after the scope.
Key takeaways
- A working demo can hide most of the remaining effort, so a credible quote needs a look at the code, data, and accounts.
- A website finish and an app finish differ mainly in data, permissions, and payments.
- Integrations, existing customers, and code quality drive cost more than page count.
- A short review that ends in a written scope is often the cheapest way to get an accurate price.
- Protect yourself with written acceptance criteria and code ownership, whatever the pricing model.
Why an unfinished AI demo is hard to quote
A demo shows the screens that work. It doesn't show whether every user can see every other user's data, whether payments survive a failed card, or whether the code is in a repository you control. Two projects that look the same in a demo can differ widely in how much work is left.
That's why a quote based on screenshots is risky for both sides. A low quote may skip the hidden work, which then shows up as change requests. A high quote may build in a cushion for the unknowns. Either way, you pay for what nobody checked.
Website finish vs app finish
The biggest split is whether real people sign in and store data.
| Marketing website | Customer portal | SaaS product | |
|---|---|---|---|
| Typical goal | Get found and get inquiries | Let existing customers do something themselves | Sell ongoing access to software |
| Accounts | Usually none | Customer and staff roles | Customer, team, and admin roles |
| Data | Form submissions | Customer records and documents | Customer data from many organizations, kept apart |
| Payments | Usually none | Sometimes invoices or deposits | Subscriptions, trials, upgrades, and cancellations |
| Main finishing work | Forms, speed, search setup, analytics, content | Access rules, data import, notifications, staff tools | Access rules, billing, onboarding, admin, monitoring |
| Main risk if skipped | Lost inquiries and weak search visibility | One customer seeing another's records | Billing errors and data exposure across accounts |
Common scope items
Most finishing projects pull from the same list. Mark each item as working, partly working, or missing before asking for quotes:
- Code in a repository you own, with a README another developer can follow
- Sign-in, password reset, and role-based access
- Database access rules tested with two accounts
- Payments, including renewals, failures, refunds, and cancellations
- Email delivery from your own domain
- Integrations with tools like a CRM, calendar, or accounting system
- Forms that reach a person, with spam protection
- Search setup: titles, descriptions, sitemap, and pages that crawlers can read
- Hosting, domain, backups, error alerts, and rollback steps
- Tests for the main journeys, and a handoff to whoever maintains it
The AI prototype to production guide explains what "done" looks like for each of these.
Want a defined scope before a quote?
Share your project, and we'll put the scope and price in writing first.
Complexity drivers
These factors move the cost more than the number of pages or screens.
| Driver | Less work when | More work when |
|---|---|---|
| Code quality | One consistent structure, few duplicated parts | Repeated prompt fixes left several versions of the same logic |
| Data model | A few tables with clear ownership | Many related tables, unclear ownership, or data from many organizations |
| Access rules | One user type | Several roles, teams, or shared records |
| Payments | One-time purchase | Subscriptions, trials, usage billing, or several currencies |
| Integrations | None, or one with a well-documented API | Several systems that must stay in sync |
| Existing users | Not launched yet | Live customers and data that must keep working through changes |
| Platform | Code is exported and runs elsewhere | The app depends on builder features with no clear export path |
| Decisions | One person decides | Several stakeholders with open questions |
Review first, then written estimate
A sensible sequence is a short review, then a written scope, then the build quote. The review answers whether to finish, stabilize, or rebuild parts, and it turns unknowns into named tasks. A developer can then price the build with fewer guesses, and you can compare proposals against the same scope.
Routeless works this way. It reviews the code, data, and accounts first, then puts the scope, timeline, ownership boundary, and price in writing before work begins. The Routeless approach to finishing AI-built projects explains when it recommends finishing and when it recommends a rebuild.
Pricing models and protections
Fixed price works well when the scope is clear and the acceptance criteria are written down. Hourly or capped hourly suits work with real unknowns, such as untangling an unfamiliar codebase. Staged pricing splits the project into a review, then build phases, each priced once the previous one has answered its questions.
Whatever the model, ask for these protections:
- A written scope with acceptance criteria for each item
- A clear rule for how changes to the scope are priced and approved
- Code, accounts, and data in your name from the start
- Credentials removed or rotated when the work ends
- A handoff document and a walkthrough at the end
Remember the running costs too. Lovable, for example, uses one credit balance for building, hosting, its built-in backend, and AI features in the deployed app, according to its plans and credits documentation. A custom domain on Lovable needs a paid plan, as its publishing documentation notes. Ask whoever finishes the project to list what you'll pay each month after launch.
Realistic timeline factors
A finishing project takes longer when:
- Feedback and decisions wait on several people
- Content, product details, or legal text aren't ready
- Third-party approvals are needed, such as a payment account review or an app store submission
- Data has to be imported or cleaned
- Live customers mean changes must be tested and released carefully
Ask for a timeline that names the dates you're responsible for, not only the developer's.
Sample acceptance criteria
Acceptance criteria decide what "done" means, so they protect the budget. Here are examples:
- A new customer can sign up, verify their email, and reach the dashboard on a phone and a laptop.
- A customer signed in as account B can't view, edit, or delete account A's records, including through direct links.
- A failed card payment marks the subscription past due and sends one email to the customer.
- The contact form delivers to the shared inbox and blocks obvious spam.
- A second developer can run the app locally using only the README.
- Rolling back the last release takes one documented step.
Copy this worksheet into a document and fill it in before you ask for quotes:
Project:
Live or preview URL:
Built with:
Who uses it (roles):
Top 3 journeys that must work at launch:
1.
2.
3.
Current blockers:
Payments (none / one-time / subscriptions):
Integrations:
Existing users or data (yes/no, how many):
Where the code lives and who owns the account:
Where the database lives and who owns the account:
Launch date or deadline (and why):
Decision maker:
If you're comparing developers, the guide to hiring a developer to finish an AI-built website shows how to compare proposals line by line. For apps holding private data, the vibe coding security checklist explains what a security review should test.
Frequently asked questions
How much does it cost to hire a Lovable developer?
It depends on what's left to finish. A marketing site that needs search setup and forms is a small job. An app with sign-in, payments, and private data needs more. Ask for a review of the code, data, and accounts first, then a written scope and price based on what was found.
Are paid audits worth it?
Often, if the audit ends in something you can use: a list of risks ranked by severity, a written scope, and a recommendation to finish, stabilize, or rebuild. An audit that only produces a long list of generic issues is less useful. Ask to see what the deliverable looks like before paying.
Can you save an AI prototype?
Usually, at least in part. The screens, flows, and decisions in a prototype carry over even when parts of the code don't. A review shows which parts hold up. Rebuilding usually makes sense only for parts that are unsafe or too tangled to change, such as access rules or billing logic.
Author: Eric Provencio · Reviewed: October 17, 2026
Methodology: Cost drivers and scope items drawn from the work a production launch requires. The guide gives no price ranges, because the cost depends on the specific project. Lovable credit and plan details come from its documentation, checked October 17, 2026.