Guide · The missing manual
Every AI builder will teach you to build. Search for how to keep the result alive and you will find almost nothing - which is remarkable, because keeping it alive is most of the work. This is the missing manual: what maintenance actually means for an AI-generated app, the routines that keep one healthy with any builder, and the honest point where routines stop being enough.
For a generated app, maintenance is four jobs, whether anyone is doing them or not:
Change safety - making modifications without breaking what works, in a codebase where the AI may touch things you did not ask about. Failure detection - noticing when a workflow silently stops, because generated apps rarely alert anyone. Dependency survival - living through the day a third-party API changes, a key expires, or a library needs patching. Knowledge preservation - keeping the reasons behind the app somewhere that outlives the chat that built it.
Every one of these defaults to you. The builder's job ended at generation; the app's life is just beginning.
Snapshot first. Commit to GitHub if your builder syncs, or use its restore point. This is the single highest-value habit on this page: it converts every future disaster from an excavation into a revert.
One change per request, named precisely. Bundled requests force the AI to regenerate wider. Small, specific asks shrink what it guesses about - the mechanism is explained in why AI keeps changing unrelated code.
Test the critical three. After any change, exercise your three most important paths end to end - the ones that touch money, customers, or data. Not everything; those three, every time. Most accumulated damage enters through changes that "looked fine."
Log the decision. One line in a document the chat cannot eat: what you changed, why, and anything the AI was told that future-you will need. The chat history is the only place your app's reasoning lives, and the chat history runs out.
Fire every automation deliberately. List each automated behavior - the email that sends, the record that syncs, the alert that escalates - and trigger each one. A stopped automation looks exactly like a quiet week until a customer tells you otherwise.
Glance at the seams. Integrations fail at the edges: expired tokens, changed APIs, renamed fields in connected tools. A two-minute check of each connection beats a nine-day silent outage.
Skim for drift. Open the parts of the app you did not change recently. Styling drift and regressions from earlier generations often surface far from the change that caused them.
Revert first, diagnose second. Restore the snapshot, confirm the app works, then investigate at leisure. Debugging a live broken system under pressure is how one bug becomes three.
Beware the repair loop. Asking the AI to fix its own breakage often spends credits stacking corrections on corrections. If two fix attempts have not worked, stop - revert and re-apply the original change differently, smaller.
Know your handover threshold. When changes fail regularly, when the data has become genuinely important, or when you notice you are afraid to touch your own app - hand it to a developer. What decides whether that handover is possible is the decision log you kept, or did not.
Read the routines above again and notice what they are: monitoring, release discipline, dependency management, documentation. That is the job software teams staff people for - and with a generated app, it landed on you, unannounced, the moment the demo worked. Done faithfully it takes an hour or two a week, forever, growing with every app you generate. That is the real price of "build an app in minutes," and it is a fair price for many things - prototypes, experiments, products with developers behind them.
For internal business systems, we think the price is wrong, which is why Chromoly's answer is structural: the runtime is platform-owned - monitoring, alerting, patches, and migrations are the platform's job - and changes show everything they affect before they apply, because the app is compiled from an explicit blueprint rather than regenerated code. The playbook above, as architecture instead of discipline. The trade is that it builds internal tools and AI automations only; if you need arbitrary code or a consumer product, use the builders this manual was written for - and keep the routines.
Either way, the question to answer before you depend on any generated app is the one this page began with: who is maintaining this - and do they know it?
Yes, but not passively - someone has to do the maintaining, and that is the part no builder's marketing mentions. Long-term health requires owned snapshots of the code, a decision log that outlives the chat history, routine checks for silent failures, and discipline around changes. Done consistently, an AI-generated app can run for years. Skipped, most degrade within months - not because the code rots on its own, but because changes accumulate damage and failures go unnoticed.
You do. Most AI builders hand you the code and sometimes host it - but hosting is not maintenance. Keeping workflows running, catching failures, surviving third-party API changes, and keeping the app safely changeable stays with whoever built it. The exceptions are platforms that own the runtime: there, monitoring, patches, and migrations are the vendor's job by design. Knowing which model you are in - before you depend on the app - is the single most important question on this page.
By default, you do not - that is what silent means. Generated apps rarely ship with alerting, so a stopped automation looks identical to a quiet week. The practical fix: list every automated behavior your app performs, and once a week trigger each one deliberately and confirm the result. For anything critical, add an external uptime check or a scheduled test record. If discovering a failure depends on a customer telling you, the failure has already cost more than the check would have.
When changes start failing regularly, when the app holds data whose loss would genuinely hurt, or when you find yourself afraid to touch it - fear of your own software is the clearest signal it has outgrown your maintenance. The handover succeeds or fails on what you preserved: a developer inheriting code plus a decision log can work; a developer inheriting code plus a vanished chat history is starting an excavation. Keep the log from day one, even if you never expect to need it.
It moves the structural half of it to the platform, for one domain: internal tools and AI automations. The runtime is platform-owned - monitoring, failure alerts, security patches, model migrations - and changes show their blast radius before applying, so the discipline this article describes manually is built in as architecture. What remains yours is what should be: deciding what the system ought to do as your business changes. The trade is breadth - arbitrary code and consumer products are exactly what it does not build.
Describe the internal tool or automation your business needs. The runtime, monitoring, and safe changes come built in.
Start free →Internal tools and AI automations only · free plan, no card · early access January