Building with AI got fast. You describe a thing, and a page, a dashboard, a small
internal report, or a client-facing microsite comes out. The awkward part is the
next step: you want exactly three people to see it, and the default way we share a
built thing is a public URL that anyone who gets the link can open.
For a landing page that is fine. For a client's numbers, an unreleased feature, a draft you only want two colleagues to read, it is the wrong default. I kept hitting
this while building Thryvate (disclosure: it is mine, this is a build-log, not a pitch), and the access model turned out to be the hardest and
most interesting part. Here is where I landed and the tradeoffs behind it.
Paste-to-link hosts (Tiiny.host, Static.app, Netlify Drop, and friends) are great at
one job: take a file, give back a public URL, done. But "public URL" quietly decides
three things for you:
For a lot of AI-built artifacts, the whole point is that they are not for everyone. A URL that treats every viewer identically cannot express "these people, nobody
else." So the model needs an identity for the viewer before it will show anything.
The rule I committed to is simple to say and annoying to build: no content renders
until the viewer has proven who they are. Concretely, a private site does this:
The important word is before. Verifying after render leaks the content to anyone
who loads the page and closes the tab. Verifying before render means the bytes never
leave the server for someone who is not on the list. That one ordering decision is
most of the security value.
The allowlist is the piece that makes forwarding harmless. The site is bound to a
set of email addresses, not to knowledge of a URL. If a viewer forwards the link,
the recipient hits the same verification wall and bounces unless the owner added
them. Adding and removing people is the owner editing a list, and revoking is
immediate: drop the address and their next load fails.
This is a different mental model from "unguessable link." An unguessable link is a
password you accidentally paste into Slack. An allowlist is a guest list the door
checks every time.
Two smaller controls ride on top of the allowlist because real sharing is messier
than a single switch:
They compose. You can require both an allowlisted email and a password, or set a
private allowlisted site to also expire on Friday. The design goal was that the common cases (just me and two people; anyone at this company; public but only for
a week) are all expressible without a settings PhD.
One more thing that is invisible until it bites you: an AI-built page can contain
arbitrary HTML and JS. If every site renders on the same origin, one site's script
can reach another's storage and cookies. So each site renders on its own sandboxed,
cookieless origin. It costs some convenience (no shared login state across sites,
by design) and buys real isolation between things different people published.
Being honest about the ceiling, because "private by default" oversells easily:
The public-link hosts were designed for a web where you published things you wanted
found. A lot of what we build with AI now is the opposite: specific, personal, meant
for a named few. When the making is cheap, most of what gets made is not for the whole internet. So the sane default for sharing it is private, with the owner naming
who gets in, and public as the deliberate exception.
If you have built something with AI and the "now share it with just these people" step felt wrong, I would genuinely like to hear how you handled it. And if you want
to see the access model above in practice, Thryvate is where I built it.