Delivering an AI-Built App to Your Client: What the Agency Owes at the End

A client here is the company that paid an agency to build something, not the client end of a client-server connection, and agency is used here in its software-supplier sense, not a government department and not the sort that represents performers. This page is about the last moment in that arrangement: the invoice is going out, the client is expecting the thing, and somebody has to decide what the word delivered is going to mean.

When the product was typed out by a person, that word was boring. Somebody pushed the code somewhere the client could reach, moved the domain, wrote down the logins and left. When the product was generated inside an AI builder, the same word covers a much wider range of outcomes, and the gap between the best and the worst of them does not show up on the day. It shows up the first time the client wants something changed and the agency is no longer being paid to change it.

The failure has a shape. A copy of the code can come out of the builder in a state that will not turn into anything an ordinary web host will serve, and nobody finds that out until somebody outside the agency tries it. The work is finished. The product is not.

Where the facts below come from: two site builders’ own published pages about what their transfer feature does, read in full and raw on 3 September 2026, navigation included, and the answers currently ranking for this question, read the same day, with the one that would not render named as unreadable rather than guessed at. Nothing was delivered, transferred or built for this page, nothing was set up to test any of it, and no contract was read for it. What one agency owes one client is settled by the agreement between those two companies, and this page neither states nor advises on what that agreement says.

Delivery is a capability, not a paperwork step. An AI-built app is delivered when the client can put a change live from a copy they hold, in accounts billed to them, without the agency’s plan and without the agency’s login. Transferring the project and pointing the domain is the first move in that, not the finish.

Three directions the work can travel, and which one you are in

Three different people arrive at this subject from three different places, and the advice that helps one of them is useless to the other two.

An owner giving a developer enough to work with is a different job from an agency giving a client the product itself, and the packet for that first job is already written out elsewhere. That reader still owns everything and is buying somebody’s time. The question is what to put in front of them on day one.

Where nobody is left to explain the thing, the first week runs in a different order and starts with control rather than with delivery. That reader inherited a running system cold, and the first job is finding out what is switched on.

This page is the third direction. The agency built it, the client paid for it, and the person writing the final message is the person who knows where every switch is. That is the easiest of the three to get wrong, because nothing is missing on the day. Everything works. It works from inside an account the client has never signed in to.

Two more directions sit next to these three and are answered elsewhere on this site: a buyer taking on a stranger’s product under an acquisition clock, and an owner going through their own accounts to work out whose name is on each one. Both come up again below, because the agency’s version of each question is different from the version those readers ask.

What the ranked answers to this question assume

The question is being asked, and it is being answered by pages that were written for a different product.

On 3 September 2026, a page-one pull for the plainest phrasing of this question returned eight organic results and not one editorial page about it. The set was a community thread from about six years ago, two group posts on a social platform, a question-and-answer page from about four years ago, a video from about five years ago, a training publisher’s forum thread dated 3 July 2014, and two site builders’ own published pages about this task. Nothing in the set was about an app, and nothing in it was about a product an AI tool generated.

The demand is not hypothetical: on 3 September 2026, Google Autocomplete returns “how to transfer lovable website to client” as a live suggestion, next to the Wix, Webflow, Framer and Squarespace versions of the same phrase. Nobody on that page of results answers a single one.

As of 3 September 2026, the thread ranked third on that result page does not render a readable body to an automated read: a plain request and a browser-shaped request both returned the same short placeholder whose only readable text is the platform’s own name. Nothing is quoted from it here and nothing is claimed about what it says.

Two of those eight are site builders documenting this exact task on their own properties, and both are worth reading properly. Each is correct about its own product. Between them they show what delivery looks like when a platform designs a feature for it, and where that stops helping.

The Wix page that ranks is a Wix Studio tutorial. The same vendor documents the same feature in more detail in its help centre, and that help-centre article is the page read here. Transferring a premium site to another Wix account, read on 3 September 2026, names two routes on that page and no others: add somebody as a collaborator, which the page recommends where you want to carry on managing the subscription payments, or transfer ownership of the site. The transfer form takes the email address on the new owner’s account and three transfer options the page names by those words: Transfer site plan, Transfer domain & business email, and Transfer premium apps. Two further checkboxes sit under them on the same form, one of them the Co-Owner choice this page comes back to below. Two lines on that page matter more than any of those options. The first: “Your payment information is not transferred, and the new site owner will manage all future subscription payments.” The second: “Some premium subscriptions cannot be transferred”, and one whole class of them is named outright, because “It is not possible to transfer Wix Payments accounts between Wix accounts.” The invite the new owner has to accept “expires in 3 days”.

Showit’s help centre article on transferring a design to a client, written by JT Pals and dated 9 April 2024 on the page, read on 3 September 2026, documents the same shape from the other end. A design “must be transferred into it’s own account in order to have a Custom Domain assigned to it”, because “Showit supports 1 custom domain per account so your clients will need their own account”. The media files travel oddly: on transfer they “WILL be included INSIDE the design but they will not populate in your client’s Media library”, so somebody re-uploads them. And the transfer is final in one direction: “Once a design has been transferred, it will no longer reference the original design. All future changes must be made inside of your client’s account.”

Both pages are accurate about their own product, and both describe delivery as a set of switches on a form. They can, because on a site builder the platform keeps serving the site whatever happens to the account underneath it. Nobody has to ask whether the client can put a new version of the thing live, because the platform is the thing that puts it live.

An AI-built app arrives as five separate things: a copy of code, a running deployment, a database, a set of keys and a domain. At least three of the five are tenants inside accounts that somebody is paying for, and a platform’s transfer form can only reach the parts that platform holds. A transfer form that moves one of them and leaves the other four where they are is a real feature that produces an unreal outcome.

The delivery test, in the order it usually fails

Five checks decide whether a client has a product or a souvenir. They are written below as capability tests, because a promise that something is possible and a person having done it once are different states, and only the second one survives the agency leaving.

The production problem an agency hits when it runs client work on one particular builder is described on its own page. This section starts after that, with a thing that works and a client waiting for it.

One: the client holds a copy of the code. Not access to a copy inside the builder. A copy in a place with the client’s name on the account, that stays there if the agency’s subscription lapses tomorrow. How much of a copy any given builder will release, and in what form, is kept as a dated comparison elsewhere on this site, and it is the first thing to settle rather than the last, because it decides how much of the rest of this list is available to you at all. Four of the builders publish four different answers to whether the project itself can move to somebody else, and the buyer’s side of that question is mapped separately.

Two: somebody has turned that copy into something that runs. This is the check that catches the failure at the top of this page. Code that lives happily inside the environment that generated it can be missing the one step that turns it into a thing a web host will serve, and nobody finds that out by looking at the files. Somebody outside the agency has to take the copy, follow the written steps and get a running version. Once. On a laptop is fine. The point is that the copy has been proved to be a product rather than an archive.

Three: the data sits somewhere the client pays for. The database is the part clients assume is theirs and the part that often is not. The test is dull: an invoice arrives at the client for it, somebody at the client can sign in to it, and a restore has been tried rather than assumed to work. A backup nobody has restored is a plan, not a copy.

Four: every key is readable and rotatable by somebody at the client. Payment keys, mail keys, model keys, storage keys. Written down is not the test. The test is that a person at the client can open the account each key came from, issue a new one, put it where the app reads it and revoke the old one, without asking the agency for anything; many keys are shown once, so seeing the old value again is not the test. Keys are where delivery quietly fails long after the invoice, because the first rotation, or the first person leaving, is when the app finds out whose account it was really living in.

Five: a change has gone live from the client’s copy, without the agency’s account. This is the whole test in one move. Someone changes one word, publishes it from the client’s own account, and both sides watch it appear. If that has happened once, checks one and two are proved whether or not anybody wrote them down. It proves nothing about three and four: a page can publish from the client’s account while the app still reads an agency database and agency keys, and no deploy exercises a restore. Those two are checked on their own. If the publish has not happened, the first two are not proved either.

Delivery is proved by a change going live from the client’s own account, not by a transfer confirmation. Everything else on the list is a precondition for that one move.

Whose account is the product actually living in?

The running product is a tenant inside somebody’s account, and which account that is was decided on the first day of the build, usually by whoever was quickest to sign up. Transfer features move the project. They do not always move the subscription that pays for it, and they never move what was never inside it in the first place.

Wix’s help article, read on 3 September 2026, states the shape better than any argument could. The outgoing party chooses whether to keep a Co-Owner role on the site: keep it and, in the page’s own words, “The new site owner can revoke your access at any time”; do not keep it and “You are no longer able to edit or manage the site in any way.” That is a platform documenting, in its own help centre, that continued access after delivery is the client’s to withdraw. It is the right default and it is worth carrying over to work where no form enforces it: after delivery, whatever access the agency still has, it has because the client has not taken it away yet.

The same page is equally clear about the part that does not travel. The payment information does not move with the site, and one class of account is named as untransferable outright. The lesson generalises. A transfer feature moves the object the platform knows about. The billing relationship, the third-party accounts, the domain registrar login and every service that was connected with somebody’s personal email are outside the object, and none of them is covered by a form the platform wrote.

One builder writes the whole exit down in its own documentation, including who keeps a seat afterwards and who pays the plan from that day, and that platform’s version is set out on its own page. Another builder documents moving a finished app into the client’s own workspace as a feature of its partner arrangement, and what that arrangement does and does not settle is covered where that directory is mapped. Reading either one is more useful than any general principle, because the general principle is only this: find out what the transfer feature moves, then write down everything it leaves behind, then decide who is doing that part and when.

Whether to buy a rebrandable product or build the multi-client version yourself is decided before any of this, and it has its own page. It matters here because the answer changes what delivery can even mean: a client who bought a seat in somebody else’s product is never going to hold a copy of it, and saying so at the start is a much shorter conversation than saying it at the end.

The uncomfortable version of this section is that the account question was answered on day one, by accident, and the delivery conversation is where the agency finds out what it answered. An agency that opens every account in the client’s name at the start has no account-transfer problem at the end. It still has to prove the copy runs, the data restores and the accounts reconnect, which is where the technical work sits.

The accounts that have to change name, and when the agency opened them

Which accounts have to end up in the client’s name, and the one-minute test that settles each of them, is a list somebody else on this site already keeps. It is written for an owner checking their own app, and it is the right list to work through. This section is about the agency’s version of the same question, which that list does not ask: which of those accounts did the agency open in its own name at the start, and what does moving each one take now rather than then?

The answer is usually that the agency opened most of them, for good reasons. The client was not ready. The build needed a mail sender that afternoon. Somebody used the agency’s card because the client’s finance process moved slower than the build did. Every one of those decisions was correct at the time and every one of them is now a small job with the client’s involvement in it, at exactly the point in a project where the client’s attention is hardest to get.

Three things make the difference between a morning and a mess.

The first is which accounts are transferable at all, as against which have to be created fresh and reconnected. Payment providers are the usual example: platforms that let a site move between accounts often say plainly that the payment account does not move with it. Left until the end it becomes an unwelcome surprise for the client; settled at the start it is a single signup.

The second is which accounts carry history the client will want. Analytics, mail reputation, store listings and a payment record are worth more the longer they have been running, and a fresh account is not a copy of an old one. Where the old account cannot move, the honest sentence to the client is that they are starting that one again, said early rather than discovered later.

The third is who is named on the domain. Not who bought it. Who is the registrant on the record and who can sign in to the registrar. A domain in an agency’s registrar account with the client’s brand on it is a delivered product that is not delivered, and it is also one of the easiest things to check before anybody claims anything.

What to settle before the last invoice

None of this is legal advice and none of it is a duty. It is a list of decisions that are cheap to make in writing at the start of a piece of work and expensive to discover at the end of it.

Somebody leaving for a new job said the two automation projects they had built for a client needed a person to take them on, and went looking for that person in public. That is the ordinary end of a working arrangement, and it is a good picture to hold while writing the four sentences below, because it is the moment they get read.

Who opens each account, and when. The best version of this is a line per account written before the first commit, naming which side signs up and on which day. It takes a few minutes then and it removes the whole of the previous section later.

What “delivered” means, in capability terms. Write down the five checks, or your own version of them, as the condition. A client who has agreed that delivered means a change going live from their own account has agreed to something both sides can look at. A client who has agreed to “the finished website” has agreed to a word.

What happens to the agency’s access afterwards. Keep it, lose it, or keep it for a stated period, decided rather than defaulted. One platform’s help centre makes the shape of that decision explicit, and there is no reason a piece of software work cannot be equally explicit without one.

Who is asked first when it breaks. Not a duty and not an arrangement, just a name. The alternative is a client emailing whoever they last spoke to, long afterwards, about a system nobody is being paid to watch.

What the agreement between the two firms actually contains, and which of them the client is invoiced by, is the mechanics page rather than this one, and it matters if there was a third company writing the code under the agency’s name. The other half of this arrangement, the agency choosing who builds under its name in the first place, is the checklist that sits at the head of this group.

What the agency is still on the hook for

Three things outlive the last invoice, and none of them is a duty this page is in a position to assign.

The first is access. After delivery, whatever the agency can still reach, it can reach because nobody has removed it. That is worth saying to the client in the message itself, because an agency that names its own remaining access looks like an agency that counted it, and an agency that mentions it for the first time during an incident looks like something else.

The second is what stops working when a plan lapses. Products built on builders and hosts have parts that keep running only while somebody’s subscription is current, and the failure is rarely loud: a form stops sending, a scheduled job stops firing, a preview URL goes cold while the live domain looks fine. Whoever holds each plan should know which parts of the product they are holding up.

The third is whether anybody is keeping the thing running at all. Somebody else described shipping software their clients actually run their operations on, built on a builder, carrying real monthly volume. Products in that position do not sit still after delivery. Whether anybody keeps the thing running after the work is delivered is a separate arrangement between the client and whoever they ask, decided on its own terms and not settled by this page.

Proof that a person has genuinely picked an app up, rather than said they would, is a short set of checks that hold no matter who wrote the thing, and they read just as well from the client’s side of the table as from the agency’s. A shop taking on somebody else’s builder app is buying a different problem from a shop giving its own work away, and the buyer’s side of that is written up separately.

The good news at the end of all this is that most of the fix is administrative. Nothing in the five checks requires rewriting the product, though an export that will not run, a service coupled to the builder or a restore that fails can each turn into technical work. It requires somebody to spend a morning proving each one, longer where something fails, and to do it while both sides still care.

Common questions about delivering an app to a client

What does delivered mean when an AI builder generated the app?

It means the client can put a change live from a copy they hold, in accounts billed to them, without the agency’s plan or login. A transfer confirmation from a builder is a step towards that, not proof of it, because most AI-built products are five things in four accounts and a transfer feature usually moves one of them. The practical test is a single change published from the client’s own account, watched by both sides, before the final invoice is paid.

What should an agency send the client when the work goes across?

The addresses of every account with the client’s name now on it, the written steps for turning the copy of the code into a running version, the name of the person at the client who signed in to each account, and a note of anything that had to be created fresh rather than moved. Sending a document is not the point. The point is that every line in it has already been tested by someone outside the agency.

Can the client run the product if the agency stops paying for its plan?

Only if the plans the product depends on are in the client’s name. Builders, hosts and mail senders each carry parts of a running product, and a plan lapsing usually breaks something quiet rather than the whole site: a form, a scheduled job, an image store. The useful check is narrower than whether a copy exists: it is whether every subscription the running version depends on is invoiced to the client.

Which parts stop working when a seller’s plan lapses is mapped in detail from the buyer’s side of an acquisition, where the same question decides what somebody is actually buying.

Who should open the accounts, the agency or the client?

The client, where the client can be persuaded to do it on day one, with the agency added as a collaborator. It is slower at the start and it removes the account-transfer part of the delivery problem at the end. Where speed wins and the agency opens an account itself, the useful habit is to write that down as a debt with a date on it, rather than as a decision.

The full list of accounts that have to end up in an owner’s name, with a one-minute test for each, is kept separately on this site and is the right thing to work through line by line.

What if everything was built inside the agency’s own workspace?

Then the workspace is the product’s home and the first job is finding out what the builder’s own transfer feature moves out of it. The builders differ, and their own documentation is the only reliable answer for each one. Whichever it is, the feature moves what the platform knows about, and every account outside the platform has to be moved on its own.

Should the agency keep access after the work is delivered?

That is a decision, not a default, and it is better made in writing before delivery than assumed afterwards. Keeping access is often what the client wants, because it means somebody can help. What matters is that both sides know it exists and that the client knows they can end it. One platform’s own help centre states that outright for its own product: keep the role and the new owner can withdraw it at any time.

What does the agency still owe once the work is delivered?

Whatever the two companies agreed, which this page cannot tell you, plus one thing that is not an obligation at all: an accurate account of what is still connected to the agency. Keys issued from the agency’s accounts, plans on the agency’s card, domains in the agency’s registrar, personal email addresses on service logins. Naming them is not a liability. Not naming them is how an agency ends up in an incident it was not being paid to be in.

Is delivering to a client the same as giving the app to a new developer?

No, and the difference is who ends up holding the thing. Giving a developer enough to work with leaves the owner in place and passes on context. Delivering to a client moves the product itself, including the accounts, the plans and the ability to publish. The third case, a developer inheriting a system cold with nobody left to explain it, is a third order of work again.

Both of the other two directions are written up separately: the packet an owner gives a developer covers the first, and the week that follows inheriting a codebase cold covers the third.