This blog post is AI-Assisted Content: Written by humans with a helping hand.

The Problem

AI is good at producing HTML artifacts: A research summary, a mockup, a meeting agenda you can actually look at. They’re beautiful, fun and can even have dynamic features. The trouble starts when you try to share one. Slack, Box and email all happily move the file around, but none of them render it. Click the link and you get a download prompt, then you open the file in a browser yourself, which is a few clicks too many for something someone made in thirty seconds. 

And because these artifacts are short-lived, the usual way to host a web page is overkill. You stand something up, it serves its purpose and then it lingers — one more orphaned file nobody remembers to take down. The knowledge is shareable. The sharing is just clumsy. 

What We Built

We built HTML Share, a small internal web app that renders and shares HTML artifacts in one step. It fronts Box, where staff already keep their files, and adds a temporary in-app hosting option for the fastest path from, “I made a thing” to, “Here is the link.” Links carry custom aliases, expiration dates and in-place updates. It runs on our standard internal stack, full-stack TypeScript on Railway behind Cloudflare Zero Trust, and it was built with Claude Code. It is live and in use across the company today. 

Above: The landing page to upload a file or point to our Box account 

How It Works 

Here is what it looks like for someone with an artifact to share: They have an HTML file, maybe Claude just generated it, and they want a colleague to see it rendered, not download it. They drop it into HTML Share and get back a link that opens the page directly in the browser. Anyone with access clicks once and is looking at the artifact, not a save dialog. 

A few choices make it stick: 

• Render-and-share in one step. The link opens the rendered page, not a download. That is the whole point, and it removes the step everyone used to do by hand. 
• Box or temporary hosting. Files can be served from Box, where staff already store them, or hosted directly in the app for the quickest share. In-app hosting defaults to a short expiration that can be extended as many times as needed, so nothing lingers by accident. 
• Custom aliases. A shared link can carry a readable alias instead of a random string, so the URL hints at what it points to when a share needs a little polish. 
• Update in place. Artifacts get feedback and change. Instead of taking a file down and posting a new link, the owner updates the file behind the same link, and the same screen manages the alias, the expiration and an early-takedown button. 

The result is that sharing an artifact is now about as much work as the artifact deserved in the first place. 

Above: An example of an HTML artifact produced by Claude 

How It Was Built

The most exciting part is how it got built, because it’s something we’re repeating over and over again internally to solve real problems and replace old SaaS apps. The point of the exercise was to dogfood the agentic development process we put together for non-developers, and the person driving it is a seasoned programmer who deliberately worked outside his own expertise to stress-test it.  

The process is a chain of Claude Code skills, template Git repositories and an internal Claude plugin. It ran roughly like this: 

• A scoping skill built a project abstract, did platform analysis and mocked up a prototype. With no requirement forcing a specific stack, it landed on the default TypeScript template, cloned the repo, set up branch protection and tagged it. 
• A requirements skill asked a series of questions, forced a few real implementation decisions and produced a requirements document. 
• A build-iteration skill implemented feature after feature and wrote the documentation alongside the code, pausing to recommend a local spin-up and a manual poke-around whenever a feature was testable. It produced 191 tests along the way. 
• A multi-role, Claude-based code review skill came back with critical issues, warnings and nice-to-haves. Addressing them meant another round of build iterations, then a re-review that caught a few more things, then a secondary review that was effectively a rubber stamp. 
• An internal deployment app pushed it to Railway behind Cloudflare Zero Trust in about ten seconds. 

Two decisions are worth calling out. First, the security model is not the app’s job. Cloudflare Zero Trust handles identity and DNS, so HTML Share secures itself to staff-only by default and any employee can authenticate and start using it without the app writing a line of auth code. Second, the whole thing leans on managed layers, Box for storage, Railway for hosting, Cloudflare for auth, so the custom surface area stays small. 

The honest payoff is in what did not happen. There was no long tail, no last twenty percent dragging on for weeks, no skipped documentation, no accessibility left as a someday. An app this small would never have cleared the priority bar before. It would have been measured in weeks, shipped with known issues and quietly mutated by competing priorities. This one went from “a few weeks” to done, at standard, in a fraction of that. 

 

Why It Matters

For the people sharing artifacts, the change is small and constant. Showing someone a rendered page is now a single click on both ends, so the friction that used to discourage sharing a quick mockup or a one-off summary is gone. People share more because sharing got cheap. 

The bigger point is what the build proves. The barrier to small internal tools was never the idea, it was the cost of doing it properly, with tests, documentation and accessibility, against a backlog of bigger work. When that cost drops far enough, the math changes. Tools that were always too small to justify suddenly clear the bar, and they ship at full quality instead of as a corner-cut afterthought. 

HTML Share is useful on its own. It is also a worked example of the kind of thing a team can now build in an afternoon and actually maintain. Credit goes to the team that built the agentic development process this rode on. The app was the easy part. The process behind it is the reusable asset. 

Where This Could Go

HTML Share works, but it is deliberately lightweight, which leaves obvious room to grow. 

• Security groups: Add group-level sharing so a team can share artifacts with just each other, a more granular layer on top of the staff-wide default. 
• An MCP server: Let people publish an HTML artifact straight from Claude Desktop, so the share happens in the tool where the artifact was created, with no manual upload step. This is the one a reader could build for their own setup. 
• Organization features: Add grouping, favoriting and the other quality-of-life touches that turn a sharing utility into a place you actually keep things. 
• Living next to other assets: Bring HTML artifacts side by side with the other things people want in one place, a RAG knowledge base or a Sigma app, so a shared link can sit in context instead of alone. 

None of these change what the app is. They extend a small, working tool in the directions its own users are already pushing it. 

Takeaway

Sharing an AI-generated HTML artifact used to mean a download prompt and a few too many clicks. Now it is one link that just renders. If your team is making things faster than it can easily share them, the gap is not the making. It is the last clumsy step, and that step is fixable.