Who owns a vibe-coded app? Owner duties¶

Once anyone besides the builder relies on a vibe-coded, citizen-developed or other employee-built app, a named app owner is accountable for it. The app owner is a business role, usually the process owner or the builder's manager. The builder is responsible for the build. IT supports the platform and the approved patterns, not the app's logic, unless the app is Critical, when IT co-owns it through graduation.

Who this is for

Business managers who are about to become an app owner, IT managers who need to assign owners, and builders who want to know who answers for their app. You get the definitions, the owner's duties by tier, the builder's and IT's duties, and what makes ownership change. Reading time: about 8 minutes.

What do owner, builder and maintainer mean?¶

App owner: The business person accountable for the app once anyone besides the builder relies on it. Owns the tier answers, the agent grants, downgrade requests, the support arrangements and the retirement decision. The owner may differ from the builder, and is recorded as a role, the person in it and a named successor.
Builder: The person who builds or changes the app, with or without AI help, and is responsible for the build, the intake answers, the app's test cases and the verification self-check.
Maintainer: Anyone other than the original builder who changes the app. A maintainer is the first thing a Team app needs when its builder moves on.

The decision rights for each of these roles, including who signs a downgrade, are on roles and decision rights. This page covers the duties, not the approvals.

What does the app owner have to do?¶

The owner's work scales with the tier. The gates behind each row are in the gate matrix; this table only says what the owner does.

Duty	Sandbox	Team	Important	Critical
Be named in the app registry as a role and a person, with a named successor	the builder is the owner	yes	yes	yes
Keep the app record current, and re-answer the six tier questions when the app gains users, data, reach, permissions or an AI feature	the builder	yes	yes	yes
Attend the scheduled review and confirm the owner, the successor and the grants are still right	at 90 days	every 12 months	every 6 months	every 6 months, with a quarterly access review
Make sure a named backup has run the app and a runbook exists	no	no	yes	yes
Own the agent's or automation's identity, grants and tokens, and approve changes to them	the builder	yes	yes	yes
Request a downgrade, with compensating controls and a review date, and sign it, for answers that would set Important or Critical (the result may be Team, for example under standard downgrade 3)	no	if an answer would set Important or Critical	yes	yes
Approve go-live, and any change that moves a tier	no	yes	yes	yes
Decide to retire the app	the builder	yes	yes	yes, with IT
Request graduation and agree the plan; the IT/platform owner decides	no	when a trigger fires	when a trigger fires	required
Hand over to a new owner; the owner's manager decides who	no	yes	yes	yes

If an owner can't do these, the app isn't ready for the tier it's in. Say so and either reduce its scope or retire it. Who is accountable for each decision (retire, graduate, reassign the owner) is set in the RACI on roles and decision rights; this table follows it.

What does the builder have to do?¶

Answer the intake questions honestly, for what the app can do rather than what it's meant to do.
Write the app record and the runbook, and keep source and configuration exported where someone else can find them (document an AI-built app).
Run the app's own test cases before each release, and the verification self-check (check an AI-built app before release).
Keep secrets server-side (a secrets manager or the platform's server-only secret store), never in code, the front end or prompts (where API keys and secrets leak).
Teach the named backup and the maintainer how to run and change it.
Hand over before moving on (when the builder leaves).

What does IT support?¶

IT and platform engineering provide the approved tools, the hosting patterns, sign-in and the registry. They run the scheduled exposure scans (or delegate them to a technical reviewer), and provide or train the technical reviewers who do the technical check at Important. They don't fix an app's logic, answer questions about its numbers, or absorb its support just because it runs on the company's tenant. The exception is Critical: IT or engineering co-owns the app through graduation, with a capacity check, and the business app owner stays accountable for what the app is for.

A published public-sector policy takes a similar line. It has IT maintain functionality that touches the most sensitive data classes, is public or crosses ministries, or supports core processes, and it lets non-compliant apps be reviewed, reassigned to IT or retired¹. Separately, vendor guidance on support strategy defines three kinds of apps with matching support and a graduation path, because builders overwhelmed by supporting their critical solutions can't build anything new². Both are guidance, not measured outcomes.

What support does each support level give?¶

Support follows the tier, through four support levels (self-supported, team-supported, assisted and IT-supported). Who answers at each level, response expectations and escalation are on the support model.

When must ownership change?¶

Reassign or retire the app when any of these happen. Record the change in the registry the same day.

The builder moves or leaves. The owner names a new maintainer or starts retirement (when the builder leaves).
The owner moves or leaves. The successor takes over, or the owner's manager names a new owner before the owner's account is disabled.
The owner stops being the right person. The process moved to another team, or the app serves people the owner doesn't manage.
The app crosses a tier. Re-answer the six questions, and the new tier's gates apply (risk tiers).
Nobody will own it. An app with no owner doesn't stay in service. Reassign, graduate or retire it (orphaned app recovery).

How do I record ownership so it survives people leaving?¶

Record three things: the owner's role, the person in it, and a named successor. The role is the durable field. The person and the successor are recorded by directory account (the stable sign-in ID from your identity provider), because that's what a leaver list or an identity export can be matched against; a role alone can't be. When the person in the role changes, update the account and nominate a new successor. Run the registry's orphan check monthly (health checks); the app registry template has the fields.

Don't: let the builder be the only owner

A builder who is also the only owner leaves an app nobody else can run or retire. Orphaned apps stay live, unpatched and unmonitored, with standing access to connected services (AP19)³.

Don't: assume IT owns everything on the tenant

"IT owns anything that runs on our tenant" silently moves every app's support to IT and gives owners no reason to keep their apps current. Support follows the tier, and owners stay accountable below Critical.

Don't: record an owner with no successor

A named owner with no successor is one resignation from an orphan. Record the successor at registration, and check it at each review.

What does app ownership look like in practice?¶

Illustrative composite

A sales operations analyst builds a renewals tracker that two sales teams use. It holds account names, renewal dates, the account rep, and the business contact details of customer staff, with no contract values or negotiated terms. The six questions: Q1(b) business contact details of customer staff; Q2(b2) two sales teams; Q3(a) company sign-in only; Q4(b) the teams work from the CRM if it stops; Q5(a); Q6(b) it writes only to its own data store. Intake puts it in Team. (If it held contract values or terms, Q1© would make it Important.) The analyst's manager is recorded as the app owner (a role), the team lead as successor, and a champion from the second team as maintainer. Six months later the analyst moves to another group. The manager reviews the registry's record, confirms the maintainer can change the app, moves the platform ownership and the one scheduled job to a service account, and updates the record. Nobody needed IT to fix a bug in the tracker's logic, and nobody needed to find the analyst. All names and details are invented.

Assumptions and evidence¶

A-034 (Low): we expect the app owner to be recorded as a role with a named successor, so ownership survives people leaving; test this each quarter by counting owner roles with no current holder.
A-020 (Low): we expect orphaned worker-built apps to accumulate unless retirement is part of registration; test this by checking whether, after 18 months, most apps in your registry are still owned and reviewed.

Evidence: vendor-originated research on ownership⁴, public-sector policy, vendor support guidance and an OWASP risk entry; no quantified study of ownership in AI-built apps. Facts on this page are as of October 2026.

Roles and decision rights: who approves and signs which decisions.
App registry: where the owner, successor and grants are recorded.
Support model: what each support level promises.
When the app's builder leaves: the handover when the builder or owner changes.
Risk tiers for worker-built apps: the tiers that set the owner's duties.

Government of Saskatchewan, low-code/no-code development and maintenance policy (issued May 2026): IT maintains functionality touching sensitive data classes, public or multi-ministry reach, or core processes; non-compliant apps may be reviewed, remediated, reassigned to IT or decommissioned. https://taskroom.saskatchewan.ca/-/media/project/taskroom/documents/policy/lowcodenocodedevelopmentandmaintenancepolicy.pdf [primary], accessed 2026-10-21. ↩
Microsoft, "Support strategy for solutions" (2025-05-14): three kinds of apps with matching support and a graduation path. https://learn.microsoft.com/en-us/power-platform/guidance/adoption/support-strategy-solutions [vendor], accessed 2026-10-21. ↩
OWASP Citizen Development Top 10, CD-SEC-09 "Asset Management Failures" (2022; the orphan risk persists). https://owasp.github.io/www-project-citizen-development-top10-security-risks/content/2022/en/CD-SEC-09-Asset-Management-Failures [primary], accessed 2026-10-21. ↩
Spotify Backstage Insights, published via the CNCF (2022 research): the top desired outcome is to maintain clear ownership of software. https://contribute.cncf.io/techdocs/analyses/2023/backstage/insights-summary [vendor], accessed 2026-10-21. ↩