How to Hire a Developer to Finish an AI-Built Website

You can hire a developer to finish a website you started in an AI builder, and you rarely need to start over. A good handoff begins with what already works, what fails, and what customers must be able to do. Share a preview or the code, a short list of blockers, and the accounts involved, then compare proposals on how they verify the work.

Key takeaways

• Send a short brief before asking for a quote. The copyable template below covers what most developers ask for.
• A preview link is enough to start a conversation. Changing the code needs repository access, which you can grant without sharing a password.
• Good proposals name what they will keep, what they will change, how they will test it, and who owns the accounts afterward.
• Be wary of anyone who recommends a full rebuild before looking at the code, or asks for passwords and API keys by email.
• Price and timing depend on access, integrations, and testing, so expect a review before a firm number.

When a developer is worth hiring

AI builders are good at the first version. You can usually keep going on your own when the remaining work is content, layout, and small fixes the builder handles well. A developer becomes worth the cost when:

• The same problem returns after every prompt, or each fix breaks something else.
• The site has to connect to something the builder doesn't support well, such as a CRM, a booking system, or a payment flow with webhooks.
• You need to move hosting, a database, or a domain, and you're not sure what will break.
• Visitors can sign in, and you need to be confident they can only see their own information.
• Search engines aren't finding the pages, and you can't tell why.
• You need someone accountable for the site after launch.

If your project is closer to an app than a website, the AI prototype to production guide has a fuller checklist.

Tasks that often need help

These come up again and again on AI-built websites:

• Connecting a custom domain, redirects from an old site, and email records so messages don't land in spam.
• Forms that appear to submit but never reach anyone, or reach the wrong inbox.
• Page titles, descriptions, canonical tags, and a sitemap, so each page can be found.
• Speed on phones, image sizes, and layout shifts while the page loads.
• Analytics and conversion tracking that record the actions you care about.
• Booking, payment, or CRM connections that need to handle failures.
• Moving the code into a repository you control so another person can work on it.

What to send in the first message

Most of the back-and-forth at the start of a project is a developer asking for information you already have. Copy this brief, fill it in, and send it with your first message. Leave anything blank that you don't know.

Project handoff brief

What the site is for:
  (One sentence. Who visits, and what should they do?)

Tool it was built in:
  (Lovable, Bolt, Replit, v0, Cursor, ChatGPT, other)

Where to see it:
  Preview or live URL:
  Code: (GitHub repository, export, or "only inside the builder")

What works today:
  -
  -

Top three blockers:
  1.
  2.
  3.

Data and connections:
  (Forms, sign-in, database, payments, email, booking, CRM, analytics)

Accounts and who owns them:
  Domain registrar:
  Hosting:
  Database:
  Payments:
  Email sending:

What must work at launch:
  -

Budget range and timing:
  (A range is enough. Include any fixed date and why.)

Do not include passwords, API keys, or customer data in this brief.

When the developer needs access, invite them through the tool itself. GitHub lets you invite a collaborator to a repository, and most builders and hosting providers have their own team invitations. OWASP's secrets management guidance explains why keys should be shared through a secrets store with limited access, never through chat or email.

Can you keep your existing design?

Usually, yes. The design, copy, and page structure are often the most valuable parts of an AI-built website, because they reflect decisions you already made. A developer can keep the look and replace what sits underneath it, or keep the code and fix specific problems.

The design is harder to keep when the builder's code can't be exported, when the layout depends on components that only work inside the builder, or when the site needs a different structure for search, such as separate pages for each service or location. Even then, the visual direction and the content carry over to the new build.

How to compare proposals

Two proposals for the same project can look very different. Put them side by side and check whether each one answers these questions:

A lower price with no testing plan or ownership terms can cost more later. For more on how the number is built, see what drives the cost of finishing an AI-built project.

Red flags to watch

Some signals are worth pausing on:

• A recommendation to rebuild everything before anyone has looked at the code or preview.
• A request for your passwords, API keys, or a copy of your customer data by email or chat.
• A fixed price and date quoted from a link alone, with no assumptions written down.
• Plans to keep the code or accounts under the developer's own login.
• A proposal that mentions features but says nothing about testing.
• Vague answers about who will do the work and how to reach them.

None of these proves bad intent. Each one is a reason to ask a follow-up question before you sign.

Sample project scope

Here is what a short, clear scope can look like for a typical AI-built marketing website. Adjust the items to your own blockers.

In scope:

• Connect the custom domain, set up redirects from the old site, and configure email records.
• Fix the contact and quote forms so submissions reach the shared inbox and send a confirmation to the visitor.
• Give each page a unique title, description, and canonical tag, and publish a sitemap.
• Compress images and fix the layout shift on the home page.
• Install analytics with events for form submissions and phone clicks.
• Move the code into a GitHub repository owned by the business.

Out of scope:

• New pages or rewritten copy.
• Paid advertising setup.

Acceptance criteria:

• A test submission from each form arrives in the shared inbox within five minutes on a phone and on a laptop.
• Every page in the sitemap returns a 200 status and has a unique title.
• The repository is under the business's GitHub account, and the developer is listed as a collaborator.
• The site loads on a phone with no visible layout jump on the home page.

Acceptance criteria like these make the end of the project easy to agree on. Each one can be checked by someone other than the person who did the work.

Costs and timing factors

The same request can be a small job or a large one depending on a few things:

• Whether the code is accessible or only lives inside the builder.
• How many outside systems the site connects to, and how well documented they are.
• Whether there is customer data or payment information involved.
• How much testing the launch needs, and on which devices.
• Whether hosting or the database has to move.
• How quickly you can answer questions and approve changes.

Expect a reviewer to look at the project before giving a firm price. If you'd like Routeless to be one of the reviewers, our page on finishing AI-built projects explains how it works. If the site also handles logins or customer data, run through the vibe coding security checklist first.

Frequently asked questions

What if I only have the preview?

A preview is enough to start. It shows the pages, flows, and behavior, and a developer can tell you what they can assess from it. Making changes needs the code, which most builders let you export or sync to GitHub. Describe what you can share and let the developer explain the safest way to grant access.

Is an unfinished AI app a rewrite?

Usually not. Most unfinished AI-built projects have design, content, and working flows worth keeping. A rewrite makes sense when the code can't leave the builder, the structure can't support what you need, or problems run through every page. A reviewer should explain which of those applies before recommending one.

Can you quote from a link?

A link supports a rough range and a list of questions, not a firm quote. A firm price needs to know how the code is built, which services it connects to, and what has to be tested. Expect a short review first, followed by a written scope with the price, timeline, and assumptions.