AI & Infra6 min readUpdated November 7, 2026

Who Owns Vibe-Coded Internal Apps When the Builder Leaves?

A dashboard stops updating. Nobody on the engineering team knew it existed. It was built by marketing with an AI app builder, deployed under someone's personal account, and that person is gone.

Ownership of an internal app belongs to the company, not the person who prompted it. The fix is boring: every internal app gets a company-owned deployment target, a company-owned service identity, and a named owner in a registry. Three lines in your onboarding doc prevent the whole class of problem.

The pattern repeats across companies: someone with domain knowledge but no engineering background prompts an app into existence over a weekend. It works. It gets shared on Slack. It quietly becomes load-bearing.

See How We Work

In This Guide

The anatomy of an orphaned app

The pattern repeats across companies: someone with domain knowledge but no engineering background prompts an app into existence over a weekend. It works. It gets shared on Slack. It quietly becomes load-bearing.
The pattern repeats across companies: someone with domain knowledge but no engineering background prompts an app into existence over a weekend. It works. It gets shared on Slack. It quietly becomes load-bearing. It runs on the builder's personal Vercel account, reads production data with a service key that has admin scope, and the only person who understands it is the builder. Then the builder leaves, the trial plan expires, or the personal account gets compromised, and the app dies with no owner, no docs and no access.

The three rules that prevent it

First, company-owned deployment targets: one organization account per platform, paid for by the company, with SSO where available. Second, scoped service identities: every app gets its own database user with permissions limited to the tables it needs, so a compromise or a departure is one key rotation.
First, company-owned deployment targets: one organization account per platform, paid for by the company, with SSO where available. Second, scoped service identities: every app gets its own database user with permissions limited to the tables it needs, so a compromise or a departure is one key rotation. Third, a registry entry before first production use: name, owner, data touched, runtime location. None of this blocks the builder. It takes ten minutes and it makes the app survivable.

What to do with the orphans you already have

Sweep first: grep your secrets manager and cloud IAM for personal emails, check billing for unknown projects, ask each team lead what internal tools their team uses. Then triage each orphan into adopt (move to company account, add owner), rewrite (usually cheaper than it looks, the app is small), or kill (most orphans deserve this).
Sweep first: grep your secrets manager and cloud IAM for personal emails, check billing for unknown projects, ask each team lead what internal tools their team uses. Then triage each orphan into adopt (move to company account, add owner), rewrite (usually cheaper than it looks, the app is small), or kill (most orphans deserve this). Set a two-week deadline. Orphans that keep running with no owner are unpatched software with your data in it.

4 Tips to Get Started

1

Ban personal accounts for anything internal touches production data. One shared company account per platform (Vercel, Supabase, Railway) costs nothing and survives departures.

2

Keep a registry of internal apps: name, owner, data it touches, where it runs. A spreadsheet is fine. Ten apps is already too many to hold in your head.

3

Give every app a service identity with scoped permissions, never a human's key. When the builder leaves, you rotate one key, not their whole access.

4

When you inherit an orphaned app, decide in the first week: adopt, rewrite, or kill. Orphaned apps that keep running are the worst option.

Ready to Stop Worrying About Infra?

Knowledge is the first step. Get a free 1-hour diagnostic and see where your infrastructure leaks time, money, and focus.

Sources & References

roqy.io cites authoritative sources including engineering blogs, vendor documentation, industry surveys, and academic research to ensure accuracy.

Related Guides

What Do You Do When Your DevOps Team Shrinks but Your Infrastructure Triples?

Microservices tripled in 8 months, the DevOps team stayed the same size, then got smaller. The realistic options: platform guardrails, deletion, and buying back hours.

Why Do Internal Dashboards Become a Maintenance Nightmare, and How to Fix It?

Tens of internal tools, each breaking when the data model changes. Why internal dashboards rot, which ones to keep, and the pattern that makes the rest maintainable.

Why Do AI-Generated PRs Break Your Infrastructure, and What Guardrails Work?

AI pull requests change pipelines and add services that need config outside the codebase. Why code review cannot catch it, and the four guardrails that do.

How Do API Keys Actually Leak? (It Is Almost Never .env)

Ten leaked API key incidents analyzed: bills from $2 to $87K. The real leak paths are logs, client bundles, browser extensions and public repos, not .env files.

R

Ron Cohen — DevOps engineer & founder, roqy.io

Content reviewed by the roqy.io team. Our guides are based on publicly available data and cited sources above.

Disclaimer: This content is for informational and educational purposes only. It does not constitute professional advice or a guarantee of specific results. Infrastructure needs vary by team, stack, and stage. Consult a qualified engineer for advice tailored to your situation.

Frequently Asked Questions

Who owns an internal app built by a non-engineer with AI tools?

The company does, the moment it touches company data. Practically: whoever runs the platform it depends on (usually engineering) inherits it. The real fix is upstream: company-owned accounts, scoped service identities, and a named owner recorded before the builder leaves, not after.

How do I audit internal apps I did not know existed?

Start from the data, not the apps. List every service account, API key and database credential that was issued, who holds it, and what calls it. Anything with a personal email attached is a candidate. Then check your cloud bill and DNS for unknown deployments.

Should we ban AI app builders like Lovable internally?

No. They are genuinely useful for internal tools. Ban the deployment pattern, not the tool: no personal accounts, no shared admin keys, no production data without a scoped identity. With those three rules, a vibe-coded dashboard is just another internal app.

Get the DevOps Ecosystem Behind You

One accountable engineer. Full platform behind him. Month-to-month, no lock-in.

See How It Works