Revdoku Turns ChatGPT Output Into Client Links, Then Tells You Who Opened Them

The Reddit founder series has reached the exact moment where an AI demo becomes annoying: the output exists, it looks useful, and now you have to send it to another person without turning into a part-time hosting provider.

This is not the glamorous part of AI. The glamorous part is Claude or ChatGPT generating a clean client report, dashboard, mini-site, pricing analysis, data room, prototype, or interactive chart. The less glamorous part is figuring out where the folder goes, how the client opens it, whether the link is still current, whether someone actually viewed it, and whether the thing you sent last Tuesday has already become the wrong version with nicer typography.

The product is Revdoku, a publishing and client-sharing tool for files, reports, dashboards, websites, and AI-generated work. Its homepage pitch is delightfully practical: drop a PDF or folder, send one gated link, see who opened what, and update the link anytime. It supports public or password-protected publishing on `*.revdoku.site` or a custom domain, visitor analytics, email gates, access notifications, stable links, snapshots, file locks, and automation from ChatGPT, Claude, Codex, API workflows, and other agents.

In plain English: Revdoku wants to be the place your AI-made work goes after the model stops being impressive and the client starts being real.

AI Made the Draft. Great. Now Ship the Thing.

The AI workflow has a surprisingly stupid last mile.

You ask ChatGPT or Claude to make a report. It gives you HTML, Markdown, charts, a PDF outline, maybe a little React app if it is feeling theatrical. You ask an agent to build a dashboard. It creates a folder. You ask a coding tool to generate a mini-site. It works locally, which is software's version of "I was charming at home."

Then comes the handoff. If you are technical, you can push to GitHub, deploy to Vercel, configure a custom domain, manage preview environments, wire forms, and pretend that "just send the link" was ever a simple sentence. If you are not technical, you can zip a folder, attach it to an email, apologize in advance, and start a small archaeological dig through versions named final, final2, and please-use-this-one.

Revdoku is aiming at that gap. Its AI connection page says users can create a free account, connect an AI tool once, then ask the AI to publish and get a live `*.revdoku.site` link they can share, update, and protect. The supported connection language is broad: Claude, ChatGPT, Codex, Gemini, command-line agents, OpenClaw, Hermes, API/MCP, and Zapier.

That is the right angle. The value is not "hosting exists." Hosting exists so hard that the internet has developed emotional calluses around it. The value is that Revdoku understands the artifact is coming from an AI or agent workflow and needs somewhere durable, trackable, and updateable to land.

Client Work Needs a Link With a Memory

The homepage has a line I like: same link, always current. Replace files and republish, but the link does not change. Snapshots and file locks protect finished work.

That sounds boring until you have ever sent work to a client. Then it sounds like indoor plumbing.

Client work is a version-control problem wearing a relationship costume. Proposals change. Reports get updated. Dashboards need fresh data. Demo sites get tweaked. Investor materials acquire one more chart. A client opens the old link because that is the one in their inbox. Someone forwards a PDF. Someone else downloads the wrong deck. The account owner asks whether the prospect actually looked at the proposal, which is apparently the moment everyone discovers that ordinary attachments are silent little bricks.

Revdoku's idea is to make the link the stable object. The files behind it can change. The access rules can change. The analytics accumulate. The viewer path becomes visible. That is useful for proposals, reports, decks, data rooms, protected demos, dashboards, and generated websites.

This is why Revdoku belongs beside SendReport, which automated the agency reporting ritual. SendReport makes the report. Revdoku is closer to the delivery surface: publish the thing, protect it, track it, update it, and avoid the haunted attachment thread.

The Docs Are Surprisingly Opinionated, Which Is Good

The Revdoku docs are more specific than the homepage. Revdoku stores generated files in private buckets as saved drafts and can publish them as public or password-protected websites. A bucket keeps file history so people and agents can update the same project over time. The CLI can publish the current folder with `revdoku p`, publish a specific folder, save a private draft, or create a password-protected website. Re-running the publish command updates the same site because the bucket is remembered locally.

That is the important product philosophy: a small fixed set of primitives. Buckets. Files. Versions. Static sites. SPAs. Protected links. Analytics. Forms. Feedback. API. MCP. CLI. Update the same thing over time.

The docs also say what Revdoku is not. It does not run custom server backends, arbitrary server code, per-bucket databases, cron jobs, or an open AI-key proxy inside published sites. That boundary is excellent. A lot of AI-adjacent tools get mushy because they want to be hosting, storage, forms, analytics, deployment, backend, database, CMS, automation platform, authentication layer, and spiritual successor to every folder on your desktop. Revdoku seems to understand that constraints are the product.

Static sites and SPAs are enough for a lot of AI-built work: generated websites, chart dashboards, single-page demos, PDF collections, reports, exported tools, and client previews. The moment you need a database or server logic, bring your own backend. Good. This is not a weakness. It is how the product avoids becoming "Vercel, but somehow also Dropbox and a client portal with a personality disorder."

Analytics Turn Sharing Into a Workflow

Revdoku's tracking layer is one of the more interesting pieces. The homepage says users can see pages, clicks, and downloads per visitor, capture leads on gated links, and get notified when a client opens the link. The docs say published websites record Revdoku analytics and browser-side client events by default, with flags to disable tracking, server-side analytics, or browser-side events.

That matters because business sharing is not only file delivery. It is timing. If a client opens a proposal, that is a moment. If an investor opens a deck three times and downloads the appendix, that is a signal. If nobody opens the dashboard, that is also a signal, just one that makes the room quieter.

The email gate is similarly practical. Revdoku can ask visitors for an email before access on paid plans and notify the owner after protected access. That turns a link into a lightweight client portal without requiring a whole client portal. There is a reason sales tools, data rooms, proposal platforms, and document-sharing tools all converge on access tracking: the file is not the whole workflow. The reaction to the file is the workflow.

That puts Revdoku near the same "reduce the boring coordination tax" lane as Social Search Cannon, which sped up manual research without pretending to think for the user. Revdoku does not need to understand the report's argument. It needs to make the report reachable, protected, current, and observable.

The viz42 Connection Is Obvious

Revdoku also pairs cleanly with viz42, another recent Reddit-series tool that turns messy specs, notes, files, and data into editable diagrams, dashboards, charts, maps, and narrated architecture walkthroughs.

viz42 is about creating the visual artifact. Revdoku is about publishing the artifact somewhere clients, reviewers, investors, or collaborators can actually open it. This is a useful distinction because AI tooling often over-focuses on generation. Generation is fun. Distribution is where work becomes accountable.

If Claude creates a dashboard and nobody can open the folder, the dashboard is a local hallucination with charts. If ChatGPT generates a report and you email a stale PDF, the workflow has already started to rot. If Codex builds a static demo and it only runs on your machine, the demo is a motivational poster for deployment debt.

Revdoku is trying to make the AI output shareable without forcing the user into a separate DevOps rite of passage. I mean that as both a joke and a compliment.

Pricing Is Mostly Founder-Friendly

The pricing is legible. The free plan includes one website, 10 MB storage, basic visitor analytics, files up to 3 MB, 5,000 visitors per month, one team member or AI assistant, visible Revdoku branding, no search indexing, and public access that refreshes when the user logs into the dashboard every 90 days. Paid monthly plans list Starter at $7, Builder at $15, and Pro at $29, with higher storage, visitor limits, file sizes, websites, custom domains, forms, analytics, and team or AI assistant seats. Annual pricing lowers those to $5, $10, and $20 per month equivalents.

That makes sense for the target user. A consultant, founder, agency, freelancer, or indie builder can start small and upgrade when the work becomes recurring or client-facing. The file-size limits also quietly reinforce the product's shape. This is not trying to host your entire production SaaS. It is trying to publish the useful outputs that need a clean link.

The free-plan 90-day refresh rule is a little quirky, but not unreasonable. It is a nudge that free public sites are for quick sharing, not abandoned permanent infrastructure. I do appreciate when a product's pricing page tells you where the fence is instead of hiding it behind a tooltip that appears only when your launch is already late.

One Gentle Critique: Explain Tracking Like a Grown-Up

My critique is simple: Revdoku should make the analytics and tracking model painfully clear in the product flow, especially for client work.

Tracking opens, pages, clicks, downloads, gated emails, and visitor activity is useful. It is also trust-sensitive. Clients may reasonably want to know when a gated link records their email, what the owner sees, how long activity is kept, and whether a shared link is public, password-protected, indexed, branded, or analytics-enabled. The docs already explain many pieces, and the protected gate displays a notice before access. Good. Put that clarity everywhere the user makes a sharing decision.

There is also a security story worth foregrounding. The security page says bucket files are private by default, data is encrypted at rest using AES-256 on region-specific Cloudflare and AWS infrastructure, logs are available, two-factor authentication exists, and enterprise options include custom retention, SSO, bring-your-own-storage, HIPAA/BAA review, and private deployments by separate contract. That is useful context. For client reports, data rooms, dashboards, and proposals, it should not feel like a footnote. It should feel like part of the product's posture.

Basically: if Revdoku wants to own the client-sharing layer for AI-generated work, trust has to be as visible as convenience.

Verdict: The AI Output Needs Somewhere to Live

Revdoku solves a real last-mile problem in the AI workflow: models and agents are getting good at producing artifacts, but users still need a durable way to publish, protect, update, and track those artifacts.

The product is strongest when it stays narrow. It does not need to become a full app platform. It does not need to run backends. It does not need to be another everything workspace. It needs to take the generated folder, report, dashboard, PDF, demo site, or chart bundle and give it a stable link with access controls, analytics, versions, and a sane update path.

That is enough. In fact, that is the point.

The AI world has spent a lot of energy celebrating generation. Revdoku is betting that the quieter opportunity is what happens after generation, when the user needs to send the work to someone who does not care which model made it and very much cares whether the link opens.

Public markets have believed dumber things. Also, so have client inboxes.