Internal prototypes should be easy to share

I built a small thing at work recently. I won't go into the details because it is an internal tool, but the idea is simple: let people turn an idea into a small interactive page and share it with others inside the company.

The original motivation was not engineering productivity. It was more about communication between product, design, engineering, and everyone else who has a half-formed idea that is hard to explain in words. Or maybe it is easy to explain in words, but the words don't land the same way for everyone. That happens a lot.

Everyone now has access to AI agents. Some of them are surprisingly good at creating small apps, mockups, dashboards, weird calculators, feature sketches, whatever else you can describe in a prompt. And for many product ideas, a tiny visual prototype is worth more than a long document. Not because documents are bad. I like documents. I write too many of them. But sometimes you need to show where the button goes, what happens when you click it, what data should be visible first, what feels too crowded, what is missing, what is obvious only after you see it.

Words are lossy. Screenshots are less lossy. Interactive prototypes are even less lossy. Still lossy, but in a more useful way.

The usual path is awkward. Someone has an idea, they write a document, maybe they attach a screenshot from Figma or a hand-drawn thing, engineering reads it, asks questions, product clarifies, engineering builds something, product says "yes, roughly, but not exactly like that", and then everyone spends a few more rounds aligning the mental image. That's normal. That's work. But the mind dumping barrier is real. Translating a fuzzy product thought into something engineering can act on takes effort. Translating it visually can be easier.

So the tool is basically: upload a small self-contained web page, get an internal URL, share it. That's it. If an AI agent can create the page, it can also publish the page. The agent can go from prompt to hosted prototype end-to-end, which is both slightly silly and very useful. It means the human can stay mostly in the "what should this feel like" space, and the agent can deal with the "make a page and put it somewhere" part.

There is a small platform SDK too. Not a huge framework; just a few common capabilities that prototypes often need. Store a tiny bit of configuration, send something to Slack, call an LLM through a shared integration and use credentials without putting credentials into the page. That last one matters because if the happy path is "paste this secret into JavaScript", then the happy path is wrong. Small prototypes still deserve boring safety rails.

I like this pattern because it treats AI agents as a new kind of glue. Not magic employees, not replacements for engineers, not autonomous geniuses running the company while we all sip coffee. More like fast hands attached to a reasonably good autocomplete brain. They can make the artifact that lets humans talk more clearly. And that's enough. That's already a lot.

There were three important constraints in the design.

First, security. This is internal-only. It sits behind restricted logins. The pages people publish are not public websites and they are not meant to become public websites. Also, isolation matters. If people can upload little apps, even trusted coworkers, you still need to assume someone will accidentally create something messy. Separate subdomains give each namespace its own browser origin, so one prototype does not casually poke another prototype. It is not a bank vault. It is not trying to be a general-purpose multi-tenant cloud. But the obvious browser isolation boundary should be used when it is available. Yes, I have opinion on how things should work.

Second, usability. Uploading needed to be plain. Pick a file, give it a name, get a link. If you want the agent to do it, there is a small skill for that too. The flow can be: describe the app, let the agent build it, let the agent publish it, open the link. Nothing clever. Mostly moving a file from one place to another and making sure the URL keeps working. Which is the kind of thing computers should be doing for us, allegedly.

Third, lean architecture. This is not for hundreds of thousands of users. It is not even for hundreds of active users. We have fewer than a hundred employees, and most of them will not use this every day. A single instance is enough. A simple persistent disk is enough. A small database is enough. The boring choice is correct here. If this ever becomes a real bottleneck, then that's a good problem and we can solve that problem then.

This is the part I keep coming back to with internal tools: the right scale is the scale of the actual problem, not the scale of the architecture diagram you want to draw. If the problem is small, build the small thing. If the small thing becomes useful and starts bending under load, great, now you have evidence. Until then, a single boring service is a perfectly respectable answer.

The whole project took a few days of prompting between meetings and chats. Not a few days of uninterrupted heroic focus. More like: ask the agent to add a capability, review it, test it, get pulled into a meeting, come back, ask it to fix the sharp edge, repeat. This is becoming a normal shape of work for me. I don't sit down and "code the feature" in the old way as often. I sit down and steer the feature into existence. Sometimes the steering is more work than coding would have been. Sometimes it's much less. Time will tell where the balance settles.

I don't know yet if this tool will work socially. Technically, it works. Socially is the harder part. Will people use it? Will PMs find it natural? Will engineers appreciate getting a prototype, or will they see it as another artifact to decode? Will prototypes clarify intent or accidentally create false precision? All possible.

But I like the bet. Lowering the cost of making an idea visible seems worth trying. The worst case is that we have another small internal tool. The best case is that some conversations become shorter, clearer, and less dependent on everyone imagining the same invisible screen.

That sounds like a good two-way door to me.