From Individual AI to Institutional AI
Non-technical domain experts are building real software with Claude. The next step is harder, and more important.
Remco runs payroll at a B2B company with a remote workforce of more than 1,500 people across dozens of countries. Different rules in every jurisdiction. Multiple currencies. People flowing in and out of roles every week. And one immovable constraint: when payroll breaks, people can’t pay their rent.
Every month, Remco reconciles the numbers from the local employers of record with what’s sitting in SAP. Every month, he reformats datasheets to match the system’s expectations. Until recently, that work cost him and his team several days a month of careful, error-prone manual processing.
Now it doesn’t. Remco has built a small set of Claude apps running locally on his machine that do most of it for him. He’s not a developer. He has never written production code. But he has deep domain knowledge about how his payroll process actually works, and he used that knowledge, plus a long Claude chat, to vibe-code his way to something that runs. The lack of internal dev resources is no longer the constraint it used to be.
That’s the part of this story everyone is talking about. It’s also where most people stop.
The pattern: powerful, but private
Remco is not the only one. In nearly every organization I work with, I see a version of him: someone in finance, or ops, or HR, or support, who has quietly built themselves an app that automates a real, gnarly workflow. The app works. The person is more productive. From the outside, it looks like the AI dream realized.
Look closer, though, and you see the problem. These apps live in a single user’s account. They sit behind one person’s login, in one person’s chat history, with no version control, no documentation, no second pair of eyes on the prompts and logic that drive them. The institutional knowledge is in someone’s head. The app that encodes that knowledge is on someone’s laptop.
I call this individual AI. It’s a real productivity gain, and it’s also a fragile one.
If Remco gets sick, the team falls back to days of manual reconciliation. If Remco leaves, the app effectively leaves with him. If his prompt logic has a subtle bug, no one will catch it. If audit asks how a number was produced, “Claude did it” is not a satisfying answer. And if three other people on the team have similar needs, they each rebuild the same thing from scratch.
This is the same story enterprises lived through with spreadsheets in the nineties and with Power BI dashboards in the twenty-tens. Powerful local tools, indispensable to the people who built them, invisible to everyone else. Eventually the organization gets serious and brings them under proper governance. AI is on the same trajectory, except the cycle is moving much faster.
The real question
So the interesting question is not “can a domain expert build a useful AI app?” That one is settled. The interesting question is:
How do you turn an individual AI tool into an institutional one, something the whole team can use and IT can help maintain, without killing the thing that made it valuable in the first place?
This is the conversation I had with Remco. Here is the path we worked out.
A four-step path from individual to institutional
One precondition before any of this: make sure the process you’re about to scale is worth scaling. Automate a flawed workflow and you’ve made it faster, harder to change, and more expensive to undo. With Remco, the reconciliation logic had been refined over years of manual iteration. That history effectively did the stress-testing for him. If your process doesn’t have that kind of history, do the work first. Walk Claude through your current flow step by step, tell it you’re about to move from manual to AI-native, and ask it to challenge each assumption and propose improvements. Then come back to step 1.
Step 1 (optional but recommended): redesign the user experience
The v1 of a vibe-coded app is usually shaped around its builder. The labels make sense to them, the flow assumes their context, the edge cases are the ones they happened to hit. That’s fine when you’re the only user. The moment you have more, it isn’t.
Open the app in claude.ai/design (currently browser-only, not yet available in the Claude desktop app), give it the brief that the functional logic must stay intact, and ask it to optimize for someone who didn’t build it. Then export the Claude Code hand-off document, a detailed development briefing that captures the intent, the data flows, and the design decisions in a form a developer (or a coding agent) can actually work from.
This step is optional, but skipping it is usually a false economy. UX is what turns “Remco’s tool” into “the payroll team’s tool.”
Step 2: get a real repository
Request access to your organization’s GitHub (or GitLab, or Azure DevOps, whatever your IT team already runs) and create a repository for the app. Nothing about this step is glamorous. It’s also the step that unlocks everything else: version history, code review, branch protections, secrets management, the ability for someone other than you to contribute.
If your IT team asks why an HR or payroll person needs a repo, the honest answer is: because the thing I built is now software, and software belongs in a repo. That framing tends to go over well.
Step 3: clone the repo locally
Pull the empty repo down to your machine. Claude Code can walk you through this end-to-end if it’s your first time: installing git, authenticating, setting up the local folder, the works. Treat this as the moment your project graduates from a chat tab to a real workspace on disk.
Step 4: rebuild v2 in Claude Code
Start a new Claude Code session pointed at the local repo. Hand it three things: the hand-off document from step 1, the current code artefacts from your v1 app, and a clear statement of intent for v2. Then iterate.
Claude Code is now writing into a versioned, reviewable codebase rather than a transient chat. Every change is tracked. Every decision is recoverable. And, the part people underestimate, you now have something an IT colleague can plug into when you need help with the genuinely hard parts: authentication, database connections, secrets, deployment, scheduled jobs.
What you actually get
Promoting an app from individual to institutional sounds bureaucratic, but each piece earns its keep:
Version control. Git gives you a free time machine, a built-in review process, and a way to roll back the change that broke production at 17:55 on a Friday. Vibe-coded apps that live in a chat have none of this.
A shared place for documentation. README files, architecture notes, prompt explanations, runbooks. The institutional knowledge that used to live in Remco’s head gets written down where the next person can find it.
A clean handoff surface with IT. Most non-developers can get an app 70% of the way there with Claude. The last 30%, the parts involving real auth, real data, real production concerns, is where you genuinely want someone with deeper engineering experience. A repo is the artifact your IT team knows how to engage with. Without it, every conversation starts from “show me what you’ve got” and ends in frustration.
A path to wider adoption. Once the app is in a repo, deploying it for the whole team is a known problem. Internal hosting, SSO, role-based access: IT does this every day. Asking them to “deploy your Claude chat for the team” is a non-starter. Asking them to deploy a small internal app from a repo is just Tuesday.
Defensibility. When audit, security, or legal eventually come knocking, and they will, you have something to show them. Code. History. Reviewers. Documentation. The same defensibility the company expects from any other piece of software it depends on.
Not everything needs to graduate
A quick caveat, because I don’t want to oversell this. Not every Claude app deserves the trip to GitHub. Some are genuinely one-off: a personal research helper, a one-time data cleanup, a draft generator that only you will ever use. Promoting those is overhead with no upside.
A useful filter: an app is a candidate for institutional promotion when at least two of the following are true. It runs on a recurring cadence (monthly close, weekly report). More than one person could benefit from it. It touches data or decisions that the company would want an audit trail for. Losing the person who built it would be operationally painful.
Remco’s payroll reconciliation hits all four. That’s why we’re moving it.
Why this matters now
The reason this conversation is happening at all is that the bottleneck has moved. Two years ago, the constraint on internal automation was can we build it? and the answer was usually “not without a dev team we don’t have.” Today, the constraint is can we operate it at the standard the organization needs? That’s a different problem, and it’s not one Claude alone solves for you. It’s a problem of process, ownership, and the boring infrastructure of software in production.
The companies that figure this out first will have a quiet but compounding advantage. Not because they have better AI, everyone has access to the same models, but because they have more institutionalized AI. Apps that survive the person who built them. Workflows that improve every month instead of degrading the moment someone gets sick. A pipeline that takes the best ideas from the Remco’s of the organization and turns them into shared infrastructure.
Individual AI gets you the demo. Institutional AI gets you the operating leverage.
If you have a Remco on your team, the next move isn’t to celebrate what they built. It’s to give them the path to make it bigger than themselves.
Image credit: Markus Spiske (via Pexels)