Your AI-built internal app needs a maintainer

Publishing an AI-built internal app should mean someone has agreed to maintain it.

Imagine a coworker generates an event-registration tool. It imports a spreadsheet, displays attendees, and sends reminders. The demo looks useful. Then another team starts depending on it, and someone has to decide which spreadsheet is authoritative and who fixes a bad import.

I'd make a small operational handoff part of accepting that app. The work should match what it handles: a seating chart needs less scrutiny than a tool that changes customer records.

The delivery workflow is getting shorter

Cursor's November 5 live-app release makes this timely. Cursor says its cloud agent can scaffold an app, provision Postgres when needed, configure authentication behind Cursor SSO, and host the result. It describes publish checks for common security issues, an explicit publish action, team-sharing controls, and admin visibility into apps and secrets. Admins can also unpublish an app.

I'd happily automate that setup. Before coworkers put their event data in the app, someone should agree to own it.

For this hypothetical tool, I'd propose the checks below. I haven't tested this release; the suggested permissions are requirements to verify in your app.

Start with the import someone will have to explain

For the registration tool, begin with a synthetic spreadsheet. Include two people with the same name, inconsistent category labels, and a missing email address. These give the reviewer specific decisions to check before real attendees enter the system.

Have the app propose changes in a separate preview. The person responsible for the event data should approve category mappings and duplicate candidates before import. Two matching names are a reason to investigate; merging them automatically could remove a real attendee.

Decide where corrections belong, too. If the spreadsheet remains authoritative, document how an app-side correction gets back into it. If the app becomes authoritative after an approved import, record when that happened and stop treating a stale sheet as current.

Otherwise, a teammate fixing a typo can accidentally create two competing versions of the attendee list.

Give viewing, editing, and exporting separate answers

Signing in identifies a user. The app also needs rules for what that user may do.

In this example, propose that event organizers can edit registrations, helpers can view the information needed for check-in, and only designated organizers can export the attendee list. Those are requirements to implement or verify in the chosen stack.

Check them with separate test identities. A helper should be unable to change a registration through either the interface or its underlying request. An organizer should be able to make the intended edit. Include exports in this check because they move a copy of the data outside the app.

Keep the observations with the handoff: which identity, which action, what happened. "Access checked" tells the next maintainer very little.

Write the handoff while the app is small

I'd keep a short record beside the code or in the team's normal app inventory. For this tool, the template could be:

Purpose: registration for <event>; retire after <date>
Maintainer: <person or team>; backup contact: <contact>
Source: <repository and deployed revision>
Data: <approved fields, authoritative copy, import decision owner>
Audience: <who may view, edit, and export>
Connections: <services, granted permissions, credential steward>
Stop and recover: <confirmed procedures and unresolved questions>
Checks: <date, test identities, observations, remaining failures>

Store credential references here; keep live secrets in the approved secret store. Name the person responsible for replacing or revoking them.

Leave specific questions for anything unverified: how the next maintainer would export and restore the data, how ownership transfers, and who can revoke an integration credential.

A brief announcement cannot settle every operational detail. Verify the answers against the actual product, configuration, and app before relying on them. If a missing answer prevents a safe handoff, keep the app in evaluation until someone resolves it.

Let a second person operate it

Give another teammate the record and a test version with synthetic attendees. Ask them to find the app, identify the deployed revision, remove a test user's access, and locate the disable procedure. Check whether an existing session or direct request still works after revocation. Record how long the change takes to apply.

Be precise about disabling. Unpublishing a page, stopping a scheduled notification, and revoking an integration credential are separate operations to investigate. Record which procedure stops which behavior in this app.

If the tool sends reminders, include one interruption exercise using test recipients. Interrupt the workflow after the email service accepts a message but before the app records success. Observe what a retry does, then decide how to detect or prevent duplicate sends using the service's supported mechanisms.

Microsoft's Foundry resilience guidance makes the same application-level responsibility explicit for hosted agents: recovery needs saved progress and identifiers to avoid repeating external actions. The products use different runtimes, so check this app's retry behavior separately.

Keep code recovery and data recovery separate in the handoff. Returning to an earlier revision doesn't by itself reverse an imported row or an email already sent.

For a tiny app, this can remain a short note and a few focused checks. Expand it when the data or actions justify more work. I'd accept the shared tool when someone besides the prompt author can explain what it changes, operate it, and take responsibility when it breaks.

Source notes

• Cursor: Build Live Apps in Cursor — November 5, 2026; vendor description of delivery, publishing, sharing, and admin controls.
• Microsoft Foundry: What's new in October 2026 — November 5 roundup; the hosted-agent resilience section covers the October 28 announcement and application recovery responsibilities.