Short answer
An employee-built app is safe to keep running once it sits on accounts the company controls, has individual logins and backups you’ve restored, and has a named owner who approves changes. Until then, it’s one resignation, expired credit card or deleted file away from stopping work.
Why employee-built apps become business-critical (and why banning them backfires)
They start small. A dispatcher builds a spreadsheet to track which trucks are due for service because the whiteboard kept getting wiped. A customer service rep uses an AI app builder to make a returns-lookup screen. An analyst writes a script that pulls the nightly order export into the report the operations manager reads every morning.
Each one solves a real problem faster than a formal project could, so other people start using it. A few months later a whole team relies on something that runs on one person’s account, has never been backed up and has no documentation. That’s shadow IT: internal apps and tools doing real work outside the systems IT knows about and supports.
Banning these apps sounds safe, but it tends to push them further out of sight. The need doesn’t go away, so the next tool gets built on a personal laptop or a free account nobody mentions. A ban also throws away a working model of exactly what the team needs, which is often the hardest part of a software project to get right.
The better goal is visibility: know what exists, decide what each app needs, and give the useful ones a proper home.
The security risks of employee-built apps
- Personal accounts. The app, its database or its domain sits on an account tied to one person’s email and credit card. When the card expires or the person leaves, the app can stop, and the company may not be able to get back in.
- Shared or missing logins. Everyone uses one password, or anyone with the link can open it. You can’t tell who changed a record, and you can’t cut off one person’s access.
- Secrets in the open. Passwords and API keys for other systems are typed into the spreadsheet, script or app settings, where anyone with a copy can use them.
- Untested backups, or none. Nobody has tried restoring the data, so nobody knows whether it can be restored.
- Data going places it shouldn’t. Customer or employee information copied into a free tool, a personal drive or an AI service the company hasn’t reviewed.
- One person who understands it. When they’re out, nobody can fix it. When they change roles, nobody can change it.
Inventory: find the apps your business already runs on
You can’t govern what you haven’t found. The NIST Cybersecurity Framework 2.0 lists maintained “inventories of software, services, and systems managed by the organization” among its outcomes (ID.AM-02). Employee-built apps are exactly the software that tends to be missing from that list.
Where to look
- Spreadsheets with logic. Workbooks with macros, lookups across files or formulas people are afraid to touch. Macro-enabled files (.xlsm) on shared drives are a quick place to start. If a workbook has quietly become the system of record, see signs you’ve outgrown spreadsheets.
- Scripts and scheduled jobs. Python or PowerShell scripts, scheduled tasks on someone’s desktop, and automations that move data between apps overnight.
- No-code, low-code and AI-builder apps. Apps built on platforms like Bubble, form builders that feed spreadsheets, and tools made with AI app builders.
- Cloud accounts on personal cards. Expense reports and card statements show subscriptions for hosting, databases, domains and app builders that never went through IT.
- Outside apps connected to company accounts. On Google Workspace, an admin can list the third-party apps that have accessed company data (Google’s instructions). On Microsoft 365, apps people have consented to appear under Enterprise apps in the Microsoft Entra admin center (Microsoft’s instructions).
Ask the people who use them
The fastest inventory is one question to each team lead: “Which spreadsheets, scripts or apps that IT didn’t give you would you struggle to work without?” Present it as finding tools worth supporting, not as an audit, or the list you get back will be short.
What to record for each app
- What it does, which teams use it and roughly how many people
- Who built it, and who keeps it running today
- What data it holds, and whether any of it is customer, employee, financial or covered by a contract or NDA
- Where it runs, and whose account and card pay for it
- What it connects to: other systems, email accounts, API keys
- What stops if it’s down for a day
That register is close to what a software handover checklist collects: code, accounts, hosting, data and documentation. The checklist works as well for an employee’s tool as it does for an outside developer’s project.
Risk triage: data sensitivity × how many people depend on it
Not every app needs the same treatment. A macro that formats one team’s weekly report is a different risk from a scheduling app the whole site uses. Two questions sort them quickly:
- How sensitive is the data? Ask: if this leaked, who would we have to tell? Customer details, employee records, pay, pricing, health or payment information, and anything covered by a contract or NDA all count as sensitive.
- How many people depend on it? Ask: if it stopped working tomorrow morning, what would stop? Count the people and the work, not just the logins.
This is a lightweight version of the NIST framework’s outcome that assets are prioritized “based on classification, criticality, resources, and impact on the mission” (ID.AM-05). You don’t need a formal risk program to start.
Triage also sets the order of work. Start with the high-sensitivity apps, because exposed data is the hardest damage to undo, and fix who can get in before anything else.
Example (hypothetical, not client data)
A distributor’s inventory turns up 23 employee-built tools. Fifteen are personal helpers that simply get registered. Five are team tools that get a named owner and a company account. Two hold customer pricing, so they move to company accounts with individual logins that week. The last one, the overtime app payroll depends on, is scheduled for promotion to a supported system.
Found an app the business can’t run without?
“We built a prototype and need someone to deploy and support it.” If that’s where you are, your first call is with an engineer, who’ll ask what the app does, who depends on it and where it runs today.
A promote-or-retire policy for employee-built apps
A policy turns a one-off cleanup into a habit. It can fit on one page, and it should make registering an app easier than hiding it. Here’s a version you can adapt.
Register
Anyone who builds a tool other people use, or one that touches sensitive data, adds it to the register with the fields above. Registering needs no approval and carries no penalty, including for apps found later. If registering feels like getting in trouble, people stop doing it.
Review
On a set schedule, and whenever an app moves into a riskier quadrant, someone from IT and the app’s business owner look at it together: which quadrant it’s in, whose accounts it runs on, whether it has logins and backups, and what it would take to support. Each review ends in one of three decisions.
Promoting doesn’t always mean writing code. Sometimes the right home is a low-code platform the company already licenses; sometimes the app has outgrown that and needs to become a custom application. Our guide to low-code vs custom software covers where that line falls, and the guides library has more decision guides for operations and IT teams.
Retiring an app without losing its data
- Export the data to company storage in a format anyone can open, such as CSV, and check that the export is complete.
- Keep a read-only copy for as long as your records policy requires.
- Revoke the API keys, passwords and connected-app permissions the app used.
- Cancel subscriptions on personal cards, and reimburse the builder if they’ve been paying.
- Remove shared links and tell users what replaces the app.
Give the builder credit either way. They found a real gap and proved what the fix should look like, and they’re usually the best person to explain how the replacement should behave.
Who may change it, and how changes get released
Once people depend on an app, the riskiest moment is a change: a formula edited mid-shift, a renamed column a script depended on, a quick fix made straight on the live version. Three rules cover it.
A named owner and a named maintainer
Every promoted app has a business owner who decides what changes and when, and a technical maintainer who makes the changes. For a small tool they can be the same person, but both names go in the register. The maintainer might be the original builder, your IT team or an outside team that provides maintenance and support.
At least two people should be able to get into every account the app depends on, with the credentials stored somewhere the company controls, not in one person’s browser.
A staging copy
A staging copy is a second copy of the app with test data, where changes are tried before they reach the people using it. For a spreadsheet tool it can be a copy of the workbook with sample rows; for a hosted app it’s a separate environment. Either way, nobody experiments on the live version.
A simple release rule
Write it as one sentence everyone can remember. For example:
Example release rule
Changes are tried on the staging copy, checked by someone other than the person who made them, released between shifts or outside working hours, and noted in a change log with a way to undo them.
The change log can start as a shared document. What matters is that when something breaks on Monday, someone can see what changed on Friday.
Making an employee-built app production-ready
Deploying an employee-built app securely comes down to a short list: move it onto hosting and accounts the company controls, give each person their own login and role, take passwords and API keys out of the code, and set up backups you’ve actually restored. Our prototype to production service explains how we approach those gaps while keeping the workflow your team already relies on.