Teams4 min read
Before 2027: Who Owns the App the AI Built?
Plenty of teams shipped an AI-built tool this year that people now depend on. Fewer can say who maintains it, where the code is, or who can change it.
2026 was the year building an internal tool stopped needing a developer. Someone in operations described a tracker, someone in sales built a quote calculator, someone in finance made the dashboard everyone now opens on Monday morning. Most of these started as experiments. A surprising number of them are now load-bearing.
That is a good outcome. It also creates a question nobody asked when the experiment started: who owns this? Not in the legal sense, but in the practical one. Who fixes it when it breaks, who can change it, where is the code, and what happens when the person who built it changes jobs?
An app without an owner is not finished. It is just not broken yet.
Five questions to answer before the year ends
The end of the year is a natural moment for this. Budgets get set, people plan time off, and teams take stock of what they rely on. For each AI-built tool your team uses, try to answer these five questions in a sentence each.
- Who is the owner? One named person who is responsible for it, not the team that uses it.
- Where is the code, and could someone else get it if the builder's account disappeared tomorrow?
- Who can change it, and who can publish those changes to the version people use?
- Which keys and accounts does it depend on, and whose name are they in?
- If it broke on the first Monday in January, how would you get back to the version that worked?
If any answer is "I'm not sure", that tool is the one to look at first.
The code should outlive the account that made it
The first risk is the simplest. If the app lives only inside one person's account on one platform, the app's survival depends on that account. People leave, subscriptions lapse, and passwords go with them.
In Vibez.now every agent turn is a git commit, so a project has a full history from its first message. That history can be pushed to a GitHub repository your organisation owns, which means the code exists somewhere that does not depend on any one person, or on us. For a tool your team depends on, do that before the holidays. It is the cheapest insurance in this list.
Give access by role, not by password
The second risk is access that grew informally. The builder shared a login, a colleague got edit rights to fix a typo, and now nobody is sure who can publish. That is how a well-meaning change goes live on a Friday afternoon without anyone else seeing it.
Viewer
Can see the project. Right for most people who use the tool but do not change it.
Commenter
Can leave feedback. Right for the person who reports what is broken.
Editor
Can change the project. Keep this to the people who actually maintain it.
Admin and owner
Can manage members and settings. Nobody can grant a role above their own, so access cannot quietly escalate.
Workspaces in Vibez.now keep an append-only audit trail of who changed what, and organisations that manage people centrally can provision members through SCIM, so someone who leaves the company loses access along with everything else. Neither helps if everyone is an admin, so the role review comes first.
Move the keys out of people's names
The third risk hides in the integrations. The quote calculator sends email through someone's personal sending account. The dashboard reads from a database whose admin login belongs to an intern who left in August. These work perfectly until the day they stop, and then nobody knows why.
- List every key the app uses. In Vibez.now the project's Secrets page shows each one by name, along with whether it is server-only or visible in the browser.
- For each key, find the account it belongs to. If that account is a person's, move it to a shared or organisational account.
- Rotate any key that was ever pasted into a chat, an email or a document. You cannot list where those copies went.
- Set a spending limit at each provider. A runaway loop over the holidays should hit a ceiling, not your card.
Know how you would get back to working
The last question is about the bad Monday. Something changed, the tool is broken, and the owner is on a beach. Because each change is a commit, restoring the last working version does not need the person who made the change, only someone with the right role and a rough idea of when it last worked.
Write it down in one paragraph
For each tool: who owns it, where the code is, who can publish, which accounts it uses, and how to roll it back. A paragraph in your team's wiki is enough. It is the difference between a ten-minute fix in January and a lost week.
Do we need a developer to own an AI-built tool?
Not necessarily. The owner needs to understand what the tool does, who uses it, and how to roll it back. For a small internal tool that is often the person who built it, as long as someone else can take over.
Should we rebuild these tools properly next year?
Only if they need it. An AI-built tool with an owner, its code in your own repository and sensible access is not a prototype any more. Rebuild when the requirements outgrow it, not because of how it started.
What is the single most important step?
Get the code into a repository your organisation owns. Everything else can be fixed later, as long as the code still exists.
The tools your team built this year are a real asset. Spend an afternoon in December making sure they still have an owner in January.