Here's a short list you can run through in ten minutes before a self-built tool goes from "thing I made for myself" to "thing my team uses."
Not every item applies to every tool. A dashboard that reads public data needs less scrutiny than one hooked into your CRM. Use judgment.
Before you share it with anyone
- Does it have a login? If the answer is "no, but nobody knows the URL," that's not a login. That's an unlocked door nobody's walked through yet.
- Who set the access level, and was it a deliberate choice? "Everyone at the company" and "the four people on my team" are both fine answers, as long as someone actually chose one, instead of defaulting to whatever was easiest at upload time.
- Where do the credentials live? If the tool connects to a real data source, the credential should never be sitting in the app's own code or config where a browser can see it. It should be stored server-side and injected at request time, not baked into anything that ships to the client.
Once it's connected to real data
- Does the tool only see what it needs? A tool built to show one team's numbers shouldn't be running with admin-level access to the entire database, even if that was the fastest way to get it working during testing.
- If the underlying system has its own permission model, a CRM where reps see their own accounts, say, does the tool respect that, or does it flatten everyone down to the same view? This one gets missed constantly, because replicating someone else's permission model is genuinely harder than building the feature itself.
- Is there a way to test a new version against the real data source without it going live for everyone the moment you save? Testing against production with no safety net is how a half-working update becomes the whole team's Tuesday afternoon problem.
Ongoing, not one-time
Governance that only happens at launch misses everything that changes afterward. Revisit access when the tool's purpose changes, not just when someone remembers to. A tool that started as "just my team" tends to spread, someone shares the link, then someone else does, and the access list is worth checking against who's actually supposed to have it every so often, not assuming the original settings still make sense six months later.
And when the builder leaves the company or moves teams? Someone needs to own the tool afterward, or it needs to be sunset. An internal tool with no owner is the software equivalent of an office plant nobody's watering: it'll keep running for a while on momentum, right up until it quietly breaks and nobody notices for weeks.
None of this requires a formal review board or a six-week security process. It requires treating a tool that other people depend on differently than a tool only you were ever going to open.