What to tell IT when you want to deploy an app you built yourself

You built something useful and want six coworkers to use it. Between those two facts is a conversation with whoever handles security, and most people go into it badly. They lead with what the tool does, get asked something they did not expect, and leave with a maybe that never becomes a yes.

A reviewer is not evaluating your idea. They are working through a short list of ways this becomes their problem. Answer the list up front and the conversation is five minutes.

One: where does the data go

Not “is the tool useful.” What leaves the building.

Name the systems it reads, name where it runs, say plainly whether anything goes to a third party. If it calls an external API, including a model provider, say so before you are asked. Getting caught not mentioning it is worse than the fact.

If the data stays inside systems the company already approved, lead with that sentence.

Two: what can it reach

The worry is lateral movement. An unreviewed app with credentials and a place on the network is a way into things that have nothing to do with it.

The strong answer is that it runs isolated, with access to nothing except what it was given. One API key, scoped to the thing it reads. If you cannot describe what the app can reach, that is work to do before the meeting.

Three: who can open it

Do not answer this with “only people who have the link.” That ends the conversation, for good reason.

You want to be able to say the app is behind the company’s own sign-in, access is a named list, and access can be taken away. If you do not have that yet, say so and ask what would need to be true. This is usually the one thing standing between you and a yes.

Four: what happens when you leave

Every internal tool has one owner, and owners change jobs. Your reviewer has watched a business process quietly become dependent on a script whose author is gone.

You cannot solve this, but you can shrink it. Say who else knows how it works, where the code lives, and what breaks if it stops for a week. If the honest answer is “nothing critical, people go back to the spreadsheet,” that is a good answer. Say it.

Five: is anyone keeping a list

What exhausts security teams is not any single tool. It is not knowing how many there are. One app is a request. Forty nobody has an inventory of is the thing they are trying to prevent.

Bring the answer: this will be in a list, with an owner, and here is where that list is.

Ask for the right decision

Most people ask for approval of their app. That buys a one-off exception, and the next tool starts the conversation over, which is how a good idea dies of process.

Ask instead about the place you want to run it. If the isolation, the sign-in and the sharing model belong to the platform rather than your app, they are the same for every app you ever put there. Your reviewer looks once, at that.

Say it out loud: “I am not asking you to review my calculator every quarter. I am asking whether this is an acceptable place to run small internal tools.”

If the answer is no

Sometimes the reason is real. A compliance requirement, a contract about where data can live, an incident you did not hear about.

Ask which of the five questions the no came from. A no to question three is a different problem from a no to question one, and only one of them is about you. Then ask what would change it.

Where Sploot fits

We built Sploot so this conversation happens once. Every app is sealed in its own sandbox with no ambient credentials. Sign-in is on the door before the app boots, so nothing is ever on a public URL. Access is a list of people you can change yourself. Everything you deploy shows up in one list with an owner.

The security model is written out in full, so whoever approves it reads the answers instead of taking your word.

Sploot is in private beta and there is nothing to log into today. If you are having this conversation right now, get on the list and tell us how it went.