Internal tools nobody has time to finish.

Someone on your team built it with AI to solve a real problem. Then they went back to their actual job, and now half the company depends on it.

What usually breaks.

Nobody owns it

The person who prompted it into existence has moved on. Nobody wants to touch a codebase they did not write and cannot read.

SSO was an afterthought

It authenticates against a hardcoded list, or against nothing. IT will not approve it, and they are right not to.

It runs on someone's laptop

Or on a VM under a desk with no backups, no monitoring, and a certificate that expired last month.

Fair things to ask.

The person who built it has left. Can you still work on it?

Yes. That's most of what we do. We read the code rather than depend on a handover that never happened.

It's only an internal tool. Does it really need security work?

Yes. Internal tools hold real data and usually have the weakest authentication on the network.

Can you connect it to our SSO?

Yes. SAML, OIDC, or whatever your identity provider speaks.

It runs on a machine under someone's desk.

We've moved worse. It ends up on real infrastructure with backups, monitoring and a documented way to restart it.

Will our IT team approve it afterwards?

That's the goal. We build the access control and audit logging they're going to ask about before they ask.

Can you document it?

Yes, and for internal tools this is often the most valuable part of the job.

It's built on something obscure.

Send it anyway. Most stacks are readable once you're inside them, and we'll tell you quickly if this one isn't.

Do we have to move off spreadsheets?

Not necessarily. Sometimes the spreadsheet is the right answer and it's the tool around it that needs fixing.

Working on something in General IT?

Send us the repo. We'll tell you what's wrong with it before you commit to anything.

Start a handoff