Volly
← Articles

I Built an App With Claude. Now What?

You've got a working tool and a browser tab open on your laptop. Here's what actually happens between "it works" and "my team uses it."

You spent an hour with Claude and now there's a tool sitting in a browser tab that does the thing you needed. Maybe it's a dashboard that pulls your team's numbers into one view, or a form that turns a three-step manual process into one click, or a scheduler that finally accounts for the weird exception your team has been working around for a year. It works. You tested it twice. You're kind of proud of it.

Then you close the laptop for the night, and the next morning someone asks "can I use that thing you showed me?" and you realize you don't actually have an answer.

This is the gap nobody talks about. Building has gotten fast — genuinely, dramatically fast, compared to even two years ago. Sharing hasn't moved at all.

The three bad options

Ask around and you'll hear the same three workarounds, roughly in this order of popularity.

Screen-record it and post the video in Slack. People watch it once, say "nice," and go back to doing the task manually, because a video isn't a tool.

Paste the code or the artifact link in a channel. This works for exactly as long as that channel exists and people remember to scroll back for it. Six months later nobody can find it, and the person who built it has since left the team.

Deploy it somewhere yourself. Vercel, Netlify, a free-tier Heroku dyno, whatever's fastest. Now it's a public URL with no login, sitting on the open internet, possibly pulling from a spreadsheet or API with real company data in it. It works great until someone in security finds it.

None of these are really "sharing." They're stopgaps that happen to look like sharing for a week or two.

What actually needs to be true

For an internal tool to survive contact with more than one user, it needs three things that have nothing to do with how well it was built: somewhere permanent to live, a way to control who can open it, and a way for people to find it without someone pasting a link into three different Slack channels.

None of that is hard, technically. It's just work nobody wants to do for a tool they built in an afternoon. And that's exactly why it doesn't get done — the tool that took an hour to build shouldn't need a deploy pipeline and a security review to reach five coworkers.

That's the whole reason Volly exists. Upload the file (or have your agent publish it straight from the chat over MCP), and it's live at its own URL behind your company's existing login, visible to whoever you choose. No ticket to IT, no waiting on a platform team's backlog, no public URL with your company's data hanging out where anyone with the link can see it.

You already did the hard part. Don't let the last five minutes be the reason nobody ever uses what you built.