Building with AI is easy. Sharing it is still painful.
Hey IH! I’m Alex, building Thryvate (https://thryvate.com).
I’ve noticed something funny about AI coding.
Building is basically solved.
You can ask Claude, ChatGPT, Cursor, or Gemini to build a dashboard, report, landing page, internal tool, or even a small web app in minutes.
Sharing it isn’t.
I kept running into the same workflow:
- Generate something with AI.
- Export HTML.
- Send it over Slack or email.
- Tell someone to download it and double-click it.
- Or spend an hour deploying it somewhere and adding authentication if the data was sensitive.
The building took five minutes. Sharing took longer than building.
So I built Thryvate.
Now the workflow is:
- Build something with your AI.
- Tell it “Publish this to Thryvate.”
- A few seconds later you have a live URL that works on any device.
No hosting. No deployment. No infrastructure.
If your AI supports MCP, it can publish directly. Otherwise you can just drag and drop the generated HTML.
The part I care about most isn’t actually publishing, though. It’s private sharing.
Most AI-generated dashboards and reports contain internal or client data. Once you send someone an HTML file, you’ve lost control of it.
With Thryvate, viewers verify their email before anything loads. You invite specific people instead of sharing a public link, and you can optionally add passwords, expiration dates, custom domains, and one-click rollbacks if your AI ships something… questionable.
One feature I recently shipped that I’m excited about: every published site now includes a built-in data layer. If your AI generates a form, it can immediately start storing submissions without you building a backend.
I’m trying to make the last mile of AI-generated software as easy as the first.
I’d genuinely love some feedback:
- How are you currently sharing things you build with AI?
- Have you ever sent someone an HTML file or thrown together a quick deployment just to demo something?
- Does requiring viewers to verify their email feel like valuable security, or unnecessary friction?
- Is there anything that would stop you from using something like this for client work?
Brutal feedback is very welcome.
email verification on every open would be too much for the quick "can you check this?" links i send. i'd keep viewing link-only, then use OTP for commenting or for the sensitive ones. have you tried splitting view and feedback permissions?
This is the most useful pushback I have had on this, thanks.
You are right that verifying on every open is wrong for the quick "can you check this?" link. The way it actually splits is anonymous vs identified. Public and password-only both keep the viewer anonymous, I have no idea who opened it, which is exactly what I want for the throwaway ones, so I keep both. The allowlist is the only mode that gives me a real identity, because email verification is the thing that ties a viewer to a name. I reach for that on the ones I would otherwise be nervous about: client work, anything with someone else's name or numbers in it. So it is a per-site choice, not one rule for everything.
Where you are ahead of me is splitting view from feedback. Right now view is the whole gate, one decision for the entire page. Published sites already have a built-in data layer, and today a form on a public site logs an anonymous submission, while the same form on an allowlist site attaches the viewer's verified email to the record. That is close to your OTP-for-commenting idea, except the identity is welded to the site's visibility instead of being its own setting. Prying those apart (open to view, verify to leave feedback) is a better shape, and I had not framed it that way.
yeah, that's the split i meant. i ended up doing it that way in PreApp: one clean reading link, one feedback link for the same HTML. the reader doesn't need to identify themselves just to open it.
would be interesting to put one non-sensitive HTML through both and compare notes. up for it?
Yeah, up for it.
Worth saying the reading half is already fine on my side: a public link takes feedback perfectly well, the form just logs the submission anonymously. So it is one link, not two. What I do not have is your second link, the one where someone reads freely but has to identify themselves to leave feedback. Identity comes from the site's visibility, so I get anonymous or verified for the whole page, never one for reading and the other for commenting.
You pick the HTML. I will put it up public with a feedback form and send you the link plus what a submission actually looks like on my end, then the same page on an allowlist so you can see what changes.
sorry, missed this in the notifications. let's use a tiny synthetic ops report so there's no client data:
source: https://github.com/serrendypity/preapp-agent/blob/main/examples/quarterly-report.html
i put the exact file on PreApp here:
read: https://preapp.app/s/ih-thryvate-cross-test-2026-07?token=view_XAt6g2BADkQIxS_iWeG91GLZIasUbOX3
comment: https://preapp.app/s/ih-thryvate-cross-test-2026-07/feedback?token=review_FLMXnQsL0CIqXXF93nceJdjoKBwlCMxU
maybe use the same test note on both: point at “return-processing latency (still 4.1 days on average)” and write “should this be median instead of average?”
send over the public + allowlist Thryvate links and a redacted view of the stored submission. i'll send back the PreApp payload for the same note so we can compare identity, target, and version without hand-waving.
Private mode is only real if authentication gates every asset before any bytes leave the server. Generated HTML can embed data or load public JSON, images, and third-party scripts even when the page shell is protected. Show the publisher every external request, and make revoke or expiry invalidate asset URLs too. Otherwise “private sharing” has a public side door.
Every file goes through the same gate as the page. Opening a site mints a short-lived signed token and all sub-resources are served under it, so there is no separate unprotected asset URL sitting on a CDN somewhere. On a private site that token lives for 2 minutes, so a copied asset URL is dead almost immediately. Link expiry is checked before a token is ever minted, and on the data path as well, so an expired link cuts off stored data exactly the way it cuts off content.
Outbound is where your point bites. Sites render in a sandboxed, cookieless, per-site origin under a locked-down CSP: scripts, styles, fonts and fetches are 'self' only unless the owner explicitly approves an origin, and publish scans the files and tells the owner which external origins it found that would otherwise be silently blocked. So "show the publisher every external request" does exist, at publish time.
The honest gap is images. img-src still allows any https origin. That was a convenience call for pages that hotlink images, and it is exactly the side door you are describing, because an image URL can carry data in its query string. Tightening it to the same approve-per-origin rule as everything else, with the publish scan surfacing what would break, is the obvious fix and it just became the top thing on my list.
The two-minute asset token closes the obvious copyable-URL hole. For img-src, I'd make approved hosts explicit capabilities shown beside the share link, not just a publish warning. Then the trust model is legible: “this page can contact these three origins.” The failure test is whether an expired page can still trigger any outbound request from cached HTML.
Capabilities beside the share link is a better frame than mine and I'm taking it. Today the approved origins are just a list on the site's settings page, so the owner has to go looking and the viewer never sees it.
Your failure test: yes, it can. CSP travels with the response, not the file. A saved copy keeps every reference and fires them all, and nothing I do at serve time reaches it. Only rewriting the document at publish would close that, which I hadn't seriously considered until now.
Also correcting myself: the publish scan is regex, best effort, and skips images entirely. Convenience, not an enforcement boundary.
Have you kept strict img-src without the support load eating you?
I think you've identified a real shift in the workflow.
As AI reduces the cost of building, the bottleneck moves to sharing, collaborating, and governing what gets built. Solving that last mile could become more valuable than making generation even faster.
Thanks! "Governing" is the word I keep coming back to. Right now for me that means allowlists and email verification, and the most common ask after that is who-viewed-what audit trails. What did you have in mind by governing?
That's a good question.
I do have something specific in mind, but it's tied to the direction you're taking Thryvate rather than governance in general. I'd rather explain the reasoning in that context than oversimplify it here.
If you're open to it, what's the best email to reach you on?
alex@thryvate.com
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.