Nobody wants to file a ticket for a spreadsheet macro they turned into a proper tool over lunch. But "just email it around" doesn't scale past about four people, and "post it in Slack" doesn't scale past about four days. If you built something useful and you want your team to actually use it — not just admire it once and go back to the old way — you need a real answer to "where does this live," and it can't require an engineer.
Here's what that looks like in practice, without going anywhere near a deploy pipeline.
Start with what you already have
Most tools people build with Claude, Codex, or Cursor land in one of three shapes: a single HTML file, a small bundle of files (HTML, CSS, a bit of JS), or a React component if you were working inside something like a Claude artifact. All three are publishable as-is. You don't need to containerize anything or ask someone to set up hosting.
If you built inside Claude and have an artifact you like, download it and you're most of the way there — a single .jsx or .tsx file deploys without a build step at all.
Get it off your laptop and behind a login
This is the part that actually matters. A tool that only runs on your machine isn't shared, it's a demo. And a tool sitting on a public URL with no login is worse than not shared at all, because now anyone on the internet who finds the link can see it too, including whatever data it's reading.
The fix is a platform that puts your app behind the login your company already uses, so "shared" means "the specific people I chose," not "anyone who has the link." On Volly, that's a drag-and-drop upload followed by a share dialog with three levels: everyone at your workspace, anyone at your workspace with the link, or a short list of people you invite by name. Pick the one that matches how sensitive the tool is, and you're done — no separate password to hand out, no access list to maintain by hand.
Let people find it later
A link works fine on day one. It's useless by month three, when the person who needs the tool wasn't in the Slack thread where you first posted it and has no idea it exists. A directory that everyone in the company can search solves this without you doing anything extra: publish once, and it's discoverable from then on, not just for the fifteen minutes after you posted about it.
Iterate without breaking what people are using
Once a tool has real users, you can't just push changes and hope. Save an update as a draft first, get your own private preview link, click through it, and only then replace the version everyone else sees. If the tool reads from a real database or API, this is also the only safe way to test that connection before it's live for the whole team.
None of this requires a review, a ticket, or someone from platform engineering setting up infrastructure on your behalf. It requires picking a place to put the thing you already built.