Picture an ordinary Tuesday. Someone in your finance org hands in their notice, works the two weeks, gets a leaving lunch. IT runs the offboarding checklist and every box gets ticked: accounts deprovisioned, laptop back in the cupboard, SSO revoked. HR closes the ticket. Nobody does anything wrong at any point in this story, which is the part worth holding onto.
Six weeks later the quarterly close slips, because a reconciliation tool that four people quietly depended on has started returning numbers that are wrong in a way nobody caught for a while. It runs in production. It sits behind your SSO. It holds a live database credential. It was built in an afternoon by the person who just left, and there's no repo anyone recognizes, no runbook, and no team name attached to it anywhere in your systems.
The ticket has to go somewhere. Where?
That's day 2. Not the launch, not the demo, not the approval, but the years afterward when something breaks at an inconvenient hour and somebody has to answer for it. For the fastest growing category of software in your company, that job has not been assigned to anyone.
Here's the Thing
- Gartner found that 41% of employees are business technologists, building technology capability while reporting outside of IT (Gartner, 2022). That was measured before AI made the building part trivial, so treat it as a floor.
- 75% of CISOs say they have already found unsanctioned AI tools running in production, and another 16% aren't sure (Saviynt / Cybersecurity Insiders, 2026).
- Day 1 is close to solved. Deployment is a product now, and a good one. Day 2 has nobody's name on it, because every other class of software in your company arrived with a support team already attached and this one doesn't.
The good part, and I mean it
I want to be clear about which side of this I'm on, because the argument that follows gets misread as gatekeeping about once a week.
A supply chain analyst building a working internal tool in an afternoon is the best thing to happen to enterprise software in a decade. Not the second best. For thirty years the constraint on internal software was never a shortage of ideas, it was the queue. The person who understood the problem had to describe it to someone who didn't, wait two quarters, and receive something adjacent to what they meant. Most good ideas died quietly in an intake form and we all agreed to call that prioritization.
That constraint is gone. The person with the problem now builds the solution, and they build it with full context, because they are the context. Quarters became hours. I've watched people who would never describe themselves as technical ship things that were genuinely good, and I have no interest in putting that back in the box.
So nothing below is an argument for slowing it down. It's an argument that we threw the party at the wrong milestone.
Day 1 got solved, including by us
Deployment used to be the wall. It isn't anymore, and I can speak to that directly, because we knocked it down ourselves.
At JFrog we built an internal path that takes someone from a prompt to a running production service with no engineer in the loop. It handles the parts that used to cost three tickets and a fortnight. It wires the app into Okta, so authentication is real rather than improvised. It provisions DNS, so the thing has a proper address instead of an IP someone pastes into Slack. And it runs an automatic security review before anything goes live. Nitzan Gotlib in our CISO organization drove that work and deserves the credit it gets internally. A non-developer describes what they want and gets back something with a real login, a real address, and a scanner's sign-off.
I'd defend that design. What nags at me is its shape.
Every capability in that list points at a single moment, the instant the thing goes live. Okta, DNS, the scan: each one is a question asked once, answered once, and filed.
The security review makes this clearest. It's a photograph of one afternoon. It tells you the app was safe when it shipped, and nothing whatsoever about the app eighteen months later, when the model behind it has been deprecated, its token has been rotated, some upstream API changed its response shape, and the only person who could explain any of that now works somewhere else. We built an excellent front door and never got around to the building.
Which is a version of an argument I've made before about self-service agent platforms: the generator is the commodity and everything wrapped around it is the actual product. I got that half right. I put the approval gate at the center and called it governance. An approval gate is still a day 1 control. It just happens to be the last one in the sequence.
Every other product in the building has a support team
Think about any other software your company runs.
Your ERP came with a vendor, an SLA, and an internal owner. The customer-facing product your engineers build has on-call, error budgets, runbooks, a postmortem culture, and a director whose bonus moves when it goes down. Even the ancient internal Java service everyone complains about has a team name in the CMDB and a human being who winces slightly when it comes up in a meeting.
None of that was designed as a separate initiative. Support came bundled, because the two historical ways to obtain software, buying it or having engineers build it, both ran through organizations that already understood they were signing up for years rather than for a launch. You couldn't get the software without also getting the org structure. The bundle was invisible precisely because it was unavoidable.
Prompt-to-prod broke the bundle. It reproduced the ability to create production software without reproducing any of the scaffolding that used to come attached. The build got democratized. The operating model didn't. That gap is where the reconciliation tool lives.
Scale is what turns this from a platform team annoyance into a CIO problem. Ten engineers shipping gives you ten services with ten owners. Four hundred non-engineers shipping gives you a long tail: hundreds of small tools, most used by three people, a handful of them quietly load-bearing, and no reliable way to tell which is which until one of them fails during a quarterly close.
The security numbers suggest the ownership vacuum is already measurable. Past the 75% who found unsanctioned AI tools in production, 92% of those CISOs say they lack full visibility into the AI identities in their environment, 71% report AI tools holding access to core systems like Salesforce and SAP, and only 16% believe that access is governed effectively (Saviynt / Cybersecurity Insiders, 2026). The one that stopped me: 5% are confident they could contain a compromised AI agent. None of those are day 1 statistics. Every tool in that survey passed whatever review existed on the day it shipped.
Three obvious homes, all of them wrong
Look at this as a CIO and you reach for an existing box on the org chart. There are three available and each fails in an instructive way.
The first instinct is to hand it back to the business unit that built it. You built it, you own it, pager included. Philosophically that's correct and operationally it's fiction, because a finance analyst has no rotation, no monitoring, and no coverage when they're on holiday in August. You've assigned accountability to a group with no means of discharging it, which produces the worst available outcome: a name in a field that makes the governance dashboard look green while nothing is actually being watched.
The second is central IT, which is what happens by default no matter what the policy says. This is how you end up with a team debugging an application they didn't write, in a stack they didn't choose, built by someone who isn't an engineer, with no documentation. IT carries the liability for software it never reviewed. It's also worth noticing where these tickets already land. Fixify's benchmark of more than 50,000 help desk tickets over fourteen months found Software and Applications alone accounts for over a third of all volume, and adding onboarding, offboarding, and identity management pushes it past 70% (Fixify, 2026). The categories this problem sits directly on top of are already most of the queue.
Third is the platform team, which is the closest fit and still wrong. A platform team's job is the substrate: deploy path, auth, runtime, DNS. Ask them to also own the business logic inside four hundred applications and you have quietly rebuilt the central development backlog everyone spent a decade escaping. Solving day 2 by recreating the queue is not solving day 2.
Which leaves no good home. Every option is bad in a different direction, and that's usually the signature of a missing box rather than a misassigned one.
What an answer would have to include
I don't have a shipped solution here. I have three things I'd argue for in a planning meeting and defend afterward.
Ownership has to be a deploy-time requirement rather than a policy. Not a field someone can skip, not an annual attestation, not a spreadsheet maintained by an unlucky program manager. You cannot reach production without a human and a team on the record, and that record has to be wired into offboarding, so the day someone leaves, their applications surface on somebody's desk as an explicit decision. Reassign or turn off. Pick one. The tool at the top of this post isn't a story about a careless employee, it's what happens when ownership lives in documentation instead of in infrastructure. I made this case about Claude Code hooks and it holds here too. A control that politely requests compliance isn't a control. A deploy that refuses to complete is.
Then, expiry dates. Default the entire long tail to something like ninety days and require a deliberate act to renew. This is the piece everyone resists and the one I'd fight hardest for, because it's the only mechanism in the list that scales without headcount. The renewal prompt asks a question nobody currently asks: does this still need to exist? Most of the tail will die of silence, which is the right outcome, because most of it should. The genuinely load-bearing things get renewed, and the act of renewing them is how you find out what they are. Note what that does to the definition, by the way. An unowned app that gets switched off isn't a day 2 failure. It's day 2 working correctly, and decommissioning turns out to be a bigger part of this than fixing.
The third is duller and probably the highest leverage: draw the substrate line explicitly and publish it where the ticket router can see it. Platform owns the road, meaning auth, DNS, runtime, deploy path, monitoring, base images, credentials. The business unit owns the logic it wrote. Write it down and "my app is down" splits cleanly into "the road is broken, ours" and "your logic is wrong, yours." A lot of the current pain is the absence of that line rather than any absence of effort on either side of it.
The function that doesn't exist yet
Someone has to run those controls, and that someone isn't on any org chart I've seen. My guess is it's a mix of three things rather than a new department, and only one part of it is actually new.
Agents have to handle the long tail. There's no headcount argument that covers hundreds of small applications, and pretending otherwise turns this into a hiring request that gets denied in Q1 and quietly forgotten by Q3. First-line triage, diagnosis, hunting down whoever owns the thing, drafting the fix, filing the decommission proposal: that's the same class of work the AI did when it built the app, just pointed the other way. AI created the volume. It's the only thing on the table that can absorb it.
The service desk is the front door, and it already receives these tickets. What it's missing isn't willingness. It's a mandate, the access to act, and any inventory worth routing against. Give it those three and you don't need a new function at all for the intake half of this.
The genuinely new job is small, and it isn't support. Call it a curator: one or two people whose mandate is the portfolio rather than any individual app. They watch what the renewal cycle reveals, promote the few things that turned out to matter into real engineering ownership with real SLAs, and switch off the rest without a lot of ceremony. The scarce skill is judgment about what deserves to survive, which is much closer to product management than to operations. Product management for software nobody intended to build.
I'd rather call this a sketch than dress it up as a framework. I haven't run it. It's what I'd argue for, not a case study, and if you've actually staffed something in this shape I'd genuinely like to hear how it went, including if it went badly.
Frequently asked questions
What does "day 2 support" mean here?
Everything after launch: who fixes it at 2am, who patches it when a dependency moves, who notices it's returning wrong answers, and who decides it should still exist. That last one carries more weight than people expect. Since most internally built tools serve a handful of users, decommissioning is a bigger slice of day 2 than fixing.
Isn't this just shadow IT with a new name?
No, and the difference is what makes it harder. Shadow IT was unsanctioned by definition, so discovery and consolidation were the fix. This software came through your approved deploy path, passed your security review, and sits behind your SSO. It's fully sanctioned and still unowned, so you can't detect your way out of it.
Should we just stop letting non-developers deploy?
That would work, and it would cost you the largest productivity gain currently available. It also doesn't hold. 45% of employees are now regular AI users on corporate devices, up from 15% a year earlier (Verizon DBIR, 2026). Bans move the building off your paved road, not out of the company.
Where does security fit if the review already happened?
The review is a snapshot and the risk is continuous. 92% of CISOs report lacking full visibility into AI identities, and only 16% say the access those tools hold is governed effectively (Saviynt / Cybersecurity Insiders, 2026). Expiry dates close more of that gap than a second review would, because they shrink the population you're securing.
What's the smallest useful first step?
Make ownership a required field at deploy and wire it into offboarding. A week of work, no glamour, and it converts the worst failure mode, an application nobody knew existed, into a routine transfer decision on somebody's leaving checklist.
Where I landed
The moment I kept chasing was somebody's face when an app they'd built themselves came up on a real URL. I still like it. I just mistook it for the end of something. Getting a non-developer from an idea to a running production service was real, and we built real machinery to get there: the deploy path, the Okta wiring, the DNS, the automatic review. I'd build it again. All of it points at a single moment.
The moment was never the hard part. Every piece of software your company has ever run showed up with an owner and somebody who wakes up when it breaks, and it showed up that way because the only available means of getting software forced you to settle that first. We found a new means. It skips the step.
So if you're looking at a growing pile of things your own employees built, the useful question isn't whether the deploy path is safe. It probably is. It's what your organization does eighteen months from now when one of them breaks, and whether the answer to that is a name or a shrug.
I'm Liran Baba, AI Lead on JFrog's CIO team. Eighteen years in enterprise tech, most of it spent on the unglamorous side: integrations, security reviews, and the systems people actually have to run. I write at liranbaba.dev about dev tools, agents, and what shipping AI inside a real company looks like.
If you're working on something similar and it's going badly, I'd like to hear about it: LinkedIn.
Originally published at liranbaba.dev
