This blog post is Human-Centered Content: Written by humans for humans.

AI is great at creating visually appealing HTML artifacts, whether these are just summaries of some research findings, mock-ups of some proposed solution or just an agenda for an upcoming meeting. The most common thing to do with these artifacts is to share them with others. We have a plethora of tools like Slack, Box and old-fashioned email to make sharing easy, but none of them will actually render the HTML. When staff click the links, they are only given the option to save the file to their computer, and then they have to go the extra step of opening the artifact in their browser.

These artifacts are short-lived, so typical solutions for sharing HTML documents are overkill. They slow down the sharing process considerably by requiring too many clicks, and lead to a cluttered mess by making it easy to forget to take down these artifacts once they have served their purpose. I don’t know about you, but the backseat of the family minivan with kids’ meal toys and loose pieces of petrified-yet-somehow-slimy cereal strewn about isn’t exactly the aesthetic we’re going for.

We need a solution to make sharing these HTML documents even easier, at least until we as a species get better at reading raw HTML, Matrix-style.

Our Solution

We are still in the process of honing our agentic AI application development process, so I used it to “dogfood” a home-grown solution.

Like I mentioned earlier, we use Box for our file storage and sharing platform, so staff are already used to storing their files there. While it won’t render the HTML, it was natural to leverage it for hosting and front it with an app that will actually render the files.

Additionally, since this solution will require a web server to function, we also added the option to temporarily host the files directly through the app as an even easier option to reduce the friction between the desire to share and getting the file in front of the people who need to see it. Since this is intended as a lightweight app, this option defaults to a short expiration, but it can be extended as many times as needed.

URL shorteners and file sharing apps generate a unique, but unintelligible, identifier for each link, and this would be no different. For many pages that are shared, this is adequate. However, some documents may call for a little more polish or hints as to what is being linked to. I included a feature that allows sharers to set a custom alias for their file links.

Since these files are being shared with others who may provide feedback, it’s likely that these artifacts will need to be updated. Instead of making someone take down the existing file and upload a new version, there’s an ability to update the existing file, which also naturally led to an interface that made it easy to manage all of the other aspects of the shared file, like alias, expiration and a button to take down the file early if needed.

For security, this app uses our standard internal app environment that hosts the code in Railway and leverages Cloudflare Zero Trust for authentication. This makes it easy to secure the app to outside access by default and immediately allows any staff member to authenticate and start to use it. The app itself doesn’t need to handle any of the authentication mechanism, DNS, etc.

How We Made the Solution

While I consider myself a seasoned programmer, I took the opportunity to test the agentic AI app development process we built out for the non-developers throughout of the company. My intent was to use it as a way to work out the kinks.

This process has largely been built out using a series of Claude Code skills, template Git repositories and an internal Claude plugin.

I started by running our custom Claude skill that builds out a project abstract, performs platform analysis and mocks up a prototype for proof of concept. There weren’t any requirements that needed a specific platform, so the skill landed on our default platform of full-stack TypeScript using Node and React. This platform is outside of my personal area of expertise, so this was a good test bed for the vibe coding process. It cloned our TypeScript template repo, set up branch protection, tagged the repo with appropriate topics and performed a few other initialization steps.

Then, I ran the next skill in the chain to flesh out the requirements. Claude asked me numerous questions and had me make some important implementation decisions. It created a comprehensive requirements document and handed me off to the next skill to begin development.

I spent some quality time with our build iteration skill as it implemented feature after feature, and wrote relevant documentation at the same time. Occasionally, as it would develop features that could be tested by me, it would pause and recommend I spin up the app locally and poke around. After a short time, it let me know that initial development was complete and handed me off to code review. During this phase, there were 191 different tests built out to ensure future tweaks don’t inadvertently break something.

I ran the multi-role, Claude-based code review skill. This came back with a few critical issues, several warnings and some nice-to-have suggestions. I decided to have it address all of them, which required another series of build iterations. I re-ran the code review again and it found a few more things that were also addressed.

After that, it was ready for a secondary code review – which was basically rubber stamped at this point due to the comprehensive review that was already performed – and deployment. I was able to use our internal deployment app to push it out to Railway and protect it behind Cloudflare Zero Trust, which took about 10 seconds or so.

Then, I realized that I didn’t actually have any documents I wanted to share, which I could not abide. After all, it’s not like you can open all of your birthday gifts and then not play with them. I had Claude generate a humorous app proposal to build out a Behfar (our CEO) emulating chatbot and used the app to share it with my team as a beta test.

The Result

Overall, this process was smooth, and the app has already been used by groups throughout the company. There hasn’t been a long tail of development with the last 20% stretching on for seemingly forever. Once it was done, it was actually done, and at the high standard we always strive for but never fully met in the before times.

Back then, this app would have been considered too small and low priority to ever be built. The time it would have taken to build would have been counted in weeks instead of hours, likely had more known issues that we just tossed on the backburner because we had bigger fish to fry, we would have been interrupted numerous times due to competing priorities that would have distracted and mutated the scope, and then after all of that, we would have realized that we still didn’t have any user documentation. We would have had to scramble to throw some together to check the box while our eyes were soundly on the next thing, meaning our attention to detail was barely phoning it in. Not to mention, we likely never would have put in the effort to make sure it had accessibility compliance and the overall look and feel very obviously would have been put together by someone whose art skills stopped progressing when eating paste was a delicacy and crayon-based stick figures still warranted prominent real estate on the family’s fridge.