The shareability gap

This doc follows the #eng thread on the Quick write-up and Jaime's note that he wants a proper internal platform for this. It does three things: pulls Quick apart properly, answers "is there an open-source or vendor tool that just does this", and ends with what the comparison implies for html-previews. Short version: nobody sells the whole thing. The pieces exist, scattered across a dozen tools, and the part that matters most is the part you can only get by owning it.

The landscape in one picture

Two axes decide whether a tool can be the home for internal artifacts: how hard it is to publish, and who can see the result once you have. The interesting corner is top right: zero-friction publishing into an org-gated audience. For HTML artifacts, only Quick lives there, and Quick is a blog post, not a product.

Publish friction against audience trust. Notion and Google Docs reach the gated corner but can't carry HTML artifacts: no interactivity, no built diagrams, no demos. For folder-of-HTML publishing, the corner is empty unless you build there. The dashed arrow is the html-previews roadmap: keep the gate, remove the friction.

What Quick actually is

Quick launched inside Shopify in July 2025. The pitch fits in a sentence: drop in a folder of HTML and assets, get back yoursite.quick.shopify.io, visible only to Shopify employees. No frameworks, no pipelines, no config files. The motivating observation came from leadership and is worth quoting because it is exactly the observation html-previews started from:

"Sharing things at Shopify was harder than building them."

The shareability gap, per the Quick write-up

In the AI era the cost of making a website, dashboard, prototype or explorable doc collapsed to a prompt. The cost of showing it to a colleague stayed where it was: a deploy pipeline, a hosting decision, an auth story. Quick removes that second cost, and the growth curve shows what was pent up behind it.

Total Quick sites, redrawn from the article's chart. Roughly 10,000 sites in the first six months, then a sharp inflection: the remaining 43,000 arrived in five. The platform didn't change in January; the authoring tools did.

A whole platform on one $200 VM

The architecture is deliberately small, and the write-up is proud of it: a single VM costing about $200 a month serves all 53,000 sites. NGINX holds a wildcard config that maps {site}.quick.shopify.io to /sites/{site}/, which is a Google Cloud Storage bucket mounted with gcsfuse. The quick deploy CLI is a wrapped gcloud rsync. Everything sits behind Google's Identity-Aware Proxy, so every request arrives with a verified employee identity before any application code runs.

Redrawn from the article's architecture diagrams. The two halves matter equally: static hosting so simple it barely exists, and a single shared API server that turns "internal trust" into zero-config capabilities.

The API server is where Quick stops being a static host and becomes a platform. Because IAP guarantees every caller is an employee, the client-side SDK needs no keys, no tokens and no setup. The capability set is small and fixed:

Database

quick.db.collection('posts')

Schemaless collections, no migrations. Firebase-style realtime sync: .subscribe() with onCreate / onUpdate / onDelete. One shared CloudSQL behind it.

quick.ai.chat()

LLM calls and image generation from client-side code. The API server adds the key and forwards to Shopify's AI proxy; sites never see a credential.

Identity

who am I → free

Name, title, team and Slack handle for the current viewer, derived from IAP. No login flows, ever.

File uploads

straight to GCS

Persistent file storage for user uploads without provisioning anything.

Data warehouse

BigQuery

Pull warehouse data into a site, which turns Quick into the company's ad-hoc dashboard layer.

Realtime

websockets

Socket.io support for multiplayer cursors, collaborative tools and games.

Slack

via the API server

Sites can reach Slack, which closes the loop between artifacts and where the org actually talks.

The four decisions that made it work

1. Identity comes from the proxy, not the app

Putting IAP in front of everything is the keystone. It is what lets the database, AI and upload APIs be zero-config, because "who is calling" is answered before application code runs. It is also what makes the radical permission model safe. Every other decision leans on this one.

2. No permissions, no ownership, no versioning

All sites are readable by all employees. Anyone can take over any subdomain; the CLI shows who deployed last and asks you to type the site name to confirm (the prompt in the hero is lifted verbatim from the article). There are no roles, no sharing dialogs, no version history. Inside a trust bubble where everyone is an authenticated colleague, the entire permissions apparatus that makes external platforms heavy just disappears. They describe the result as Geocities nostalgia without the spam.

3. Saying no is the feature set

Feature requests for custom backends were declined. So were cron jobs, per-site databases and migrations. The write-up is explicit that a small, fixed set of capabilities is what keeps Quick simple to use and to maintain, and argues the constraints drove creativity rather than limiting it. The only scaling work in a year was rewriting the API server from Node.js to Go for memory management, and adding rate limits after people ran batch loops against the AI endpoint.

The only scaling work in a year: one rewrite for memory, one rate limit for enthusiasm.

4. Agent-first distribution

quick init installs agent skills, so Claude already knows how to deploy and how to use every API without anyone reading docs. People generate whole sites from prompts. That is why the growth chart bends in January 2026: Quick removed the sharing cost in July, and when agents removed the building cost six months later, the two costs hitting zero together produced the hockey stick. 140+ entries in a company game jam, sites embedding sites, shared JS libraries with their own landing pages, community-built Figma-style commenting and analytics. Tobi Lütke calls the result a Lehrwerkstatt, a learning workshop where knowledge spreads through proximity.

So can we just buy or clone this?

Short answer: no single tool, open source or vendor, covers the job. The job decomposes into five properties: effortless publishing, an org-gated audience, shared backend capabilities, a review layer, and agent ergonomics. Everything available today clusters around one or two of them.

Platform	Drop-a-folder publish	Org-gated audience	Backend APIs	Review & sign-off	Agent-first	The catch
QuickShopify, internal	yes	IAP	db · AI · more	community-built	quick init	Not a product. A write-up and a blueprint; you can't run it.
html-previewsus, today	PR + build	Vercel auth	comments fn only	comments · approvals	AGENTS.md	Publish friction; identity self-asserted; no discovery beyond Slack links.
Netlify Dropvendor	drag & drop	public	–	–	–	Anonymous drops expire in 24h unless claimed; public URLs.
surge.shvendor	one CLI cmd	password, $30/mo	–	–	–	Public by default; password protection is a paid bolt-on, not org SSO.
tiiny.hostvendor	drag & drop	password on paid	–	–	–	Free tier: 1 site, 7 days. Per-seat pricing grows with adoption.
Val Townvendor	save = deploy	private vals	sqlite · blob · cron	–	MCP · CC integration	Code-first vals, not folders of HTML; audience is per-val visibility, not org SSO.
Smallwebopen source	mkdir = site	behind your proxy	Deno per app	–	CLI-friendly	Designed as a single-tenant personal cloud; org identity, review and shared APIs are ours to build.
Coolify / Dokployopen source	git/docker deploys	DIY	BYO services	–	–	Self-hosted PaaS for running services. Wrong altitude for throwaway artifacts.
Vercel previews + commentsvendor	repo + project each	team-gated	–	comments · Slack sync	–	Built for "review my branch", not "publish an artifact". Review data lives in Vercel.
Claude artifacts / v0 / Lovablevendor	prompt → link	vendor workspace	vendor-shaped	–	native	No folder ingest, no house style, and the trust model is a share link, not our org gate.
Notion / Google Docsincumbent	for prose	org SSO	–	the gold standard	via MCP	Can't host HTML. No demos, no interactive diagrams, no spatial layout. The medium is the limit.

Four entries deserve a closer look than a table row:

Smallweb is the closest open-source analogue to Quick's hosting half: every subfolder becomes a subdomain, apps are sandboxed Deno workers that scale to zero, the whole thing is one Go binary. If we ever want to self-host the hosting layer, this is the project to evaluate first. But it is built as a personal cloud. The parts that make Quick an org platform, shared identity, shared APIs, the trust bubble, are exactly the parts Smallweb leaves to you.

Val Town is the best vendor expression of agent-first ergonomics: save a TypeScript val and it is deployed at a URL, with sqlite, blob storage and cron included, plus an MCP server and Claude Code integration. Its unit is a piece of code rather than a folder of HTML, and visibility is per-val rather than org-SSO, so it solves a sibling problem: tiny tools, not shared artifacts.

Vercel preview comments are the vendor version of our review widget: default-on for preview deployments, screenshots, mentions, threads synced to Slack. Worth studying for the Slack sync in particular. But the unit is a deployment of a project, so every artifact would need to be a repo with a Vercel project, which reintroduces precisely the friction Quick removed.

Glitch is the cautionary tale. For years it was the friendly place to remix and host small web apps; it shut down app hosting in mid-2025. Artifacts that matter for years (RCAs, signed-off tech plans) should not live on a vendor whose business model can sunset the archive. Our previews being plain HTML in a git repo is quiet insurance.

Where html-previews sits

html-previews started from the same observation as Quick, five weeks before the Quick write-up was published: HTML artifacts beat markdown for anything spatial, and they need a real URL behind the team's auth. Since then Martin added the persistent review layer (comments, highlights, reactions, signed approvals) and the house style, and it has been adopted for tech plans across the team. The honest comparison:

What we have that Quick doesn't ship

A review layer as a first-class feature. Block-anchored and text-selection comments, emoji reactions, viewer presence, and DocuSign-style signed approvals. At Shopify this is community-contributed; here it is the point.
A house style. AGENTS.md makes every artifact read like an engineering blog post, with a shared visual language. Quick sites are gloriously unstyled Geocities; our docs are review-grade.
The agent round-trip. pull-comments.mjs feeds discussion back into Claude Code so the artifact gets revised from its own review. Nothing in the landscape does this.
Durable, portable storage. Plain HTML in a git repo. No vendor can sunset the archive.

What Quick has that we don't, yet

Zero-friction publish. Their floor is quick deploy; ours is a commit, a PR and a build. This is the gap that explains 53,069 vs dozens.
Real identity. IAP gives every request a verified employee; our reviewers type their own names above a Vercel login gate.
Shared capabilities. Database, AI proxy, uploads, warehouse, Slack: one API server turns artifacts into apps. We have one bespoke comments function.
Discovery. A namespace people browse and build on. Ours is whoever saw the Slack message.

Which yields the roadmap, in dependency order. Each step is small and none requires abandoning what exists:

Frictionless publish. A small CLI that pushes a folder and returns a gated URL, no PR. Git stays the home for canonical docs; the CLI serves the long tail. Copy the overwrite-with-confirm UX verbatim.
Real identity. Surface the authenticated user to pages and the API instead of typed names. Decide this before building more on self-asserted identity.
Postgres. Already flagged in AGENTS.md as the comments backend's next step; also becomes the site registry that unlocks everything below.
Discovery. A real index: every artifact by category, author and recency, plus a "recently discussed" feed. Makes adoption legible, which is what the growth chart did for Quick.
Slack notifications. On publish, on comment, on approval. Every notification is an ad for the platform.
A generic data API. Generalise the comments function into collections so artifacts can hold state: polls, dashboards, planning tools.
An AI proxy. Server-held keys via ai-platform, so a tech plan can embed a working demo of the agent behaviour it proposes.
Agent packaging. The quick init move: a marketplace skill that scaffolds a styled, comment-wired artifact and knows every API above.

And one lesson to adopt before any of it: Quick's most quotable engineering decision is the list of things they refused to build. No custom backends, no cron, no permissions, no versioning. A fixed, small capability set is why one person can maintain the platform, and the constraints are part of why people love it. Whatever "a proper internal platform" becomes, it should inherit that discipline.

Discussion

Comment inline (hover any paragraph, or select text to start a thread), react, and sign at the foot of the page if you think this captures the landscape. Particularly interested in: whether the publish CLI or real identity should come first, and whether anyone has seen a tool this scan missed.