Who Maintains My AI Built App? The Four Real Options

The app works. People sign up, the payments land, and nothing has needed touching for a month. Then a phone operating system updates, or a certificate expires, or a customer sends a screenshot of an error you have never seen, and one question arrives with it: whose job is that?

If you built the app by describing it to an AI tool, the honest answer is that it is nobody’s job yet. The tool wrote the code. It never agreed to keep the code working. That is not a complaint about the tool, and you do not have to take anybody’s word for it, because all three of the big builders write it down in the terms you accepted.

This page does two things. It shows you, in three platforms’ own words, where the responsibility actually landed. Then it sets out the four arrangements that cover the work instead, what each one is really buying, and the point at which each one stops making sense.

Nobody maintains an AI built app by default. The platform that wrote the code does not undertake to keep it running, and its own terms say so. Four arrangements cover the work instead: you keep prompting it, you buy one repair at a time, you pay somebody monthly, or somebody takes it on.

Nobody is looking after it right now, and the platforms say so in writing

Start with the documents, because they settle the question faster than any argument about them.

Lovable’s terms of service, version 28 August 2026 with an effective date of 15 August 2026, put it in a section called Your Responsibilities: “You are responsible for your Customer Data and for the applications and projects you build, deploy, and make available using the Services”. A separate section on AI Output goes further about the code itself: “You are solely responsible for reviewing, validating, and using any AI Output”. The warranty section, set entirely in capitals in the original, states that the services, the platform, and all AI output are provided as is and as available, with no warranty that they will be uninterrupted or free of harmful code.

Replit’s terms of service, in the version stated as last updated on 3 August 2026, say the same thing in fewer words. In the section covering your content, the sentence is: “You remain responsible and accept liability for your content, apps, and projects, and for managing access permissions.” Its warranty disclaimer opens, again in capitals, by saying that your use of the service is at your sole risk.

Base44’s terms of service are the most specific of the three, and section 2.3, headed Customer Infrastructure, is worth reading slowly:

Customer is solely responsible for obtaining, maintaining and operating (and ensuring its Users maintain and operate) Customer’s applications, accounts, third-party services, integrations, cloud environments, development and runtime environments, credentials, security controls, and internet connectivity necessary to access and use the Platform …

The same section adds that the customer “is also responsible for its own data backups and for the security and compliance of any Customer-managed environments in which the Generated Output is hosted or used”, and section 12 provides the platform, the website and any generated outputs as is, as available and with all faults. Those terms are stated as last updated 22 June 2026.

Read together, the three documents say one thing: the accounts, the backups, the integrations, the security settings and the running application are yours to keep working. The platform sells you the ability to produce and host software. It does not sell you an undertaking that the software stays correct next quarter.

Owning the app and being the one who has to look after it are the same person under these terms, and the second half is the part nobody reads. The ownership half is settled and mostly settles your way. Every account underneath the app that has to carry your name before any of this matters is a list somebody has already written down, and it is not the list on this page.

None of that means you are the person who has to do the work. It means you are the person who has to arrange it. Plenty of people arrange it by doing it themselves, including people who would never call themselves technical. One of them, writing publicly about the site their firm runs, described the arrangement in a sentence:

I’m a lawyer, not a developer… I built and have continued developing the entire site in Lovable …

They are not a developer, and they are the maintainer. That is answer number one, and it is a real answer, with real costs that this page gets to further down.

Three builder platforms’ terms of service were read in the page source on 1 September 2026, alongside one seller’s own published tier table, and every clause and figure below carries the date it was read; no account was opened and no app was run for this page.

What “looking after it” turns out to mean

The word covers four different kinds of work, and confusing them is why people underestimate the whole thing.

The first kind arrives on somebody else’s calendar. Phone operating systems ship new versions, app stores set deadlines, certificates expire, and the packages your app is built from get security releases that stop being optional. None of it is caused by you. All of it lands whether the app changed or not.

The second kind is the customer’s. Somebody hits an error, a payment does not go through, an email lands in spam, and the report reaches you through a person rather than through the app.

The third kind is yours. You want the app to do something it does not do yet, and every change to a working application costs more than the same change did during the build. Why the same change costs more in the second year than it did in the first is answered on its own terms elsewhere.

The fourth kind is the part nobody sees, which is checking that the protections you believe you have are actually connected to something. Across the 21 third-party apps whose findings went into the ledger for June and July 2026, out of 26 real applications audited in that window, one finding kept repeating: a control that exists in the code and is joined to nothing. A limit on how often a request can be made, sitting in a file that no request travels through. Error handling written and then never placed anywhere it would catch anything. A written set of safety rules for the assistant that no running code opens. Nothing about the app looks wrong from the outside, and nothing about it is protected either. That kind of finding is invisible until a person goes looking.

The individual jobs behind the word, and which of them arrive whether or not you touch the app, are listed apart from this decision. What follows here is the decision itself.

The four arrangements that actually keep an app alive

There are four, and a one-app owner is always choosing between them, whether or not the choice is ever made out loud. Three cost money. One costs your evenings.

The columns worth arguing about are the last two. Almost every page written about this subject compares prices, which is the wrong axis. Four different things are being sold here: credits, finished results, availability, and somebody else carrying the app. Comparing their prices puts four unlike purchases in one column and hides what each one actually gets you.

Four arrangements, four different purchases: credits, finished results, availability, and not being the person who gets called.

Keeping it going yourself

This is the arrangement almost everybody starts with, because it is the arrangement you are already in. Something breaks, you open the builder, you describe what is wrong, and often enough it comes back fixed.

It works better than people who write about it admit. Somebody two years into running a paid product this way described the arrangement without any drama:

Two years into running a real SaaS that I now build primarily by directing AI coding tools …

Two years is the horizon that settles whether an arrangement held, and theirs held. When this option does fail, it fails in a specific way. The failure is that a working application has parts sitting outside anything the builder can reach from a chat window: the database holding real customer rows, the payment account, the mail sender, the settings that decide who can read what. When the thing that broke lives there, more prompting moves the code around underneath a problem that is not in the code. The other failure is smaller and more common, which is the next prompt breaking something that worked while it fixes the thing you asked about.

The honest cost has two parts and only one of them is on a bill. The bill is credits, and the comparison between spending your next dollar on the meter and spending it on an hour of a person has been worked out elsewhere with real numbers rather than guessed at here. The other part is your attention, which is harder to price and is the part that runs out. Somebody who ended up as the maintainer of a tool their colleagues rely on described how they got there:

Night shift brain plus a product backlog that never shrinks led me to just… build the thing myself.

Nobody assigned that job. It is what happens by default when a tool gets used, and it is still an arrangement, with a person in it who did not plan on being there.

There is a separate bill underneath all of this that no arrangement removes. What the machines under the app charge every month is counted separately and is not part of this decision. Hosting, the database, the mail sender and the metered services keep charging whether the app is maintained, neglected or perfect.

This option is the right one when the app is small, the changes are cosmetic, and an hour of it being down costs you nothing but annoyance. It stops being the right one the first time you cannot fix something and cannot tell why.

Paying for one repair when something breaks

This is the arrangement most one-app owners actually need, and the one they are least often offered, because it is the hardest for a seller to build a business on.

The unit is one named problem, rather than the app or a list of things about it. One thing that is failing, that you could explain to a friend over coffee, and where you will know for yourself the moment it is put right. The signup email goes to spam. The export button does nothing. The report page times out for one customer and not for others. Each of those is a job somebody can price, do, and prove.

Buying one is also the cheapest way to find out whether somebody is any good, which matters more than the price of the job. A month of a seller’s time costs far more than a single repair and tells you less, because you find out how they work only after the money is committed. One repair puts a small amount of money against a visible result, and the answer arrives in days.

What it does not cover is the work that has no edges. Moving the app off its builder, rebuilding it, finishing a half-built section, or being available for whatever happens next are all different purchases, and pricing them like a repair is how both sides end up unhappy. The going rates for a single job on an app that already runs are collected in ranges elsewhere.

I work this way, which is why this arrangement gets a paragraph rather than a mention.

Buying somebody’s time by the month

A monthly arrangement is the option people jump to when the one-repair route starts feeling repetitive, and it is bought on a misunderstanding often enough to be worth stating plainly: you are buying availability and a place in a queue, not a promised quantity of finished work.

The published tiers make this visible. Cleveroad’s app maintenance cost guide, a page marked Updated 09 Jun 2026, publishes three of its own tiers sized by monthly hours. Its entry tier, which the page calls Light maintenance, is listed at 20 to 40 hours a month for $1,000 to $3,200 a month, in a table whose heading names the hourly rate band those tiers are priced from. That is one seller’s own published entry tier, read on 1 September 2026, and it is not a market rate. It is useful for one reason only, which is that it shows what the money is measured in: hours of somebody’s attention, reserved in advance, whether or not the month needs them. Cleveroad sells what I sell, so that page is named here and not linked, at cleveroad.com/blog/app-maintenance-cost/.

The guide those tiers come from answers the money question a second way as well, by tying a year of upkeep to a fraction of what the app cost to build. For an app that came out of a month of credits, that starting number is nearly nothing, so the answer it produces is nearly nothing, and no number on this page is derived that way.

The real question about a monthly arrangement is whether your app generates enough work to fill it. One owner who built the whole thing themselves has since brought in somebody paid to look after it, which is the honest version of this move: the app did not get harder, the owner ran out of appetite for being the one who answers. That is a good reason to buy a month. Buying one for the reassurance of a standing line item, on an app that changed twice last year, is money going to a queue nobody joins.

The contents of a standing monthly package, and the lines a single-application owner can strike out without regretting it later, are set out as their own list. Whether a monthly arrangement is worth it for one app, and what belongs in the written terms once you say yes, has its own rules, and the terms are where most of the value sits: how many hours, whether unused hours carry over, how fast somebody answers, and what falls outside the monthly figure entirely.

This option is the right one when the app changes often, when somebody being unavailable for a week would cost you real money, or when a person other than you now depends on the app to do their job. It is the wrong one when three of the last six months had nothing in them.

Somebody takes it on ongoing

The fourth arrangement comes in two shapes, and they are worth separating because they cost differently and they feel completely different.

The first shape is a person you keep. Somebody who knows the app, who is there next quarter, and whose knowledge of your particular application is the thing you are paying to keep. It sits next to the monthly arrangement above and often starts as one. Choosing the person, and judging when a month of somebody’s time is worth buying, is the step after this one.

The second shape is a full transfer, where somebody else runs it from then on and you stop being the one who gets called at all. That move comes with four checks of its own, and the checks matter more than the price, because a transfer where you are still the person paging somebody at midnight has not moved anything.

Owners often buy these two as one thing without noticing. One owner described what they were shopping for as a single job: get the thing finished and running, and be the person who keeps it running afterwards. Those are two purchases with two different shapes, and the second one is decided better after the first one has landed and you have seen how the person works.

This option is the right one when the app has stopped being a side project, when it holds money or customer records that somebody has to be answerable for, or when you genuinely do not want to think about it again. It is the wrong one while the app is still cheap enough to fix one piece at a time.

Two questions that pick the arrangement for you

App size decides nothing here, and neither does how complicated somebody says the code is. Two questions do, and you can answer both of them this afternoon.

The first: how often does the app need to change? Count the last six months honestly. Changes you wanted and did not make still count. If the answer is once or twice, you are looking at the first two arrangements. If it is most weeks, you are looking at the last two.

The second: what does an hour of the app being down actually cost you? Finish this sentence with a number. “If nobody could sign up or pay between nine and ten tomorrow morning, it would cost me ______.” For a lot of small apps the honest answer is nothing, and that is a genuinely useful answer, because it tells you that paying every month for a fast response is buying something you do not need. For an app taking orders all day, the number is large enough to settle the argument on its own.

Two questions decide it: how often the app has to change, and what an hour of it being down actually costs you. App size decides nothing.

Somebody titled a post on a builder community with the whole subject in one line: “Vibe coding works until someone else has to maintain the vibe”. The point underneath the joke is that these arrangements are about a person, not about a tool, and the person is currently you.

Two things are worth settling before anybody else touches the app, whichever arrangement you pick. Every one of the accounts underneath it needs your name on it first, because none of the four arrangements survives finding out that the repository or the payment account belongs to somebody who has stopped replying. And whoever you are considering, buy one small job first. Finishing the part that was never built is a good first job because it produces something visible. So is any repair that has been annoying you for a month. If the person you are considering has gone quiet before, what to do when the person who built it has gone quiet is its own problem and it is worth solving before the maintenance question.

What a month of upkeep adds up to, line by line and including the months that cost nothing at all, is counted on its own page and not here. This page is about which arrangement, not how much.

Common questions about who maintains an AI built app

Who maintains an app built with AI?

Whoever you have arranged, and by default that is nobody. The builder platform hosts the app and does not undertake to keep it correct: Lovable, Replit and Base44 all put responsibility for the running application on the customer in their own terms, read on 1 September 2026. Four arrangements cover the work instead, and picking one on purpose is the whole decision.

Does the builder platform keep my app running?

It keeps its own service running, which is not the same thing. Base44’s section 2.3 makes the split explicit by naming what stays with you: the applications, accounts, third-party services, integrations, cloud environments, credentials and security controls. Replit’s terms say you remain responsible for your apps and projects. All three disclaim warranties on the software the tool produced for you.

Can I maintain the app myself if I cannot read code?

Yes, for a while, and plenty of people do. Prompting the builder handles cosmetic changes, copy, new pages and many bugs. Where it stops is anything living outside the code: the database, the payment account, the mail sender, expired credentials, and permissions that decide who can read what. When the fix keeps not holding, that is usually the signal that the problem is in one of those places.

My app has no users yet. Does it still need looking after?

Less, but not nothing. The work that arrives on somebody else’s calendar arrives anyway: package security releases, expiring certificates, store deadlines and platform version changes do not check your user count. A quiet app can safely run on the first two arrangements. What it cannot safely do is go a year with nobody looking at it and then take its first real customer.

What keeps costing money even when nobody touches the app?

The machines and the accounts. Hosting, the database, the mail sender and any metered service charge every month regardless of whether a line of code changed, and what the stores themselves charge to keep a published listing is its own separate line. Those bills are the machine half of the question and are counted apart from anybody’s time.

Can I move between these arrangements later?

Yes, and most owners do, usually in the same direction. The common path is prompting it yourself, then one repair at a time as the fixes get harder, then a monthly arrangement once the app carries something that matters. Moving is easier if the accounts are already in your name, because a new person can then start without needing anything from the last one.

What should be in my own name before anyone else works on the app?

The repository, the domain and its DNS, the database, the payment account, the mail sender, the store listing, the analytics and the environment secrets. Each takes about a minute to check inside the relevant account. This matters for maintenance rather than for pride: an arrangement where somebody else holds the accounts leaves you dependent on that person staying reachable, and it comes apart at exactly the wrong moment.

Who is answerable when something goes wrong inside the app?

You are, under the terms of all three builders read here, and that is true whether the code was written by you, by an AI tool or by somebody you paid. The arrangements on this page change who does the work, not who is answerable for it. That is the reason to write down what an arrangement covers, and it is the reason a monthly agreement is worth more for its terms than for its price.