Shopify's Quick is the clearest proof yet that AI-era hosting is a real category.

What Quick is and the numbers

Quick is an internal platform, and Shopify's engineering post is plain about the contract: drop in a folder of HTML and assets and get back a secure URL that only Shopify employees can see. Access runs through an Identity-Aware Proxy, so a viewer has to be a verified employee. There is no public mode; Quick is infrastructure Shopify built for itself.

The adoption numbers are the headline. Per the post, Quick has hosted more than 50,000 sites, and over half of Shopify's employees have created at least one. It launched in July 2025 and saw a major adoption spike in December 2025. For an internal tool, over half of employees having created at least one site is a remarkable figure, and it is the single strongest signal in the post: when AI makes HTML cheap to produce, the bottleneck moves to having somewhere to put it.

The infrastructure is deliberately small. Shopify describes a single VM that costs about $200 a month to run, with an NGINX wildcard config in front of a Google Cloud Storage bucket mounted via gcsfuse, so, in the post's words, NGINX thinks it's just serving local files. Deploying is quick deploy, which the post describes as nothing more than a small wrapper around gcloud's rsync. Fifty thousand sites, one VM, a static file server, and a sync command.

On top of that core, Quick bundles a set of optional capabilities for sites that need more than static files: a database (CloudSQL with a Node or Go server), file uploads, AI access for LLM calls and image generation, BigQuery access, WebSockets, and an Identity API that returns the viewer's name, title, team, and Slack handle. These are layers a subset of sites opt into; the loop everyone shares is still folder in, URL out.

Why it worked: constraints and saying no

Shopify's own explanation for Quick's success is discipline, not features. The post's stated philosophy is to keep it simple and embrace the constraints: a deliberately small, fixed set of capabilities, and a team that has, in its own words, gotten really good at saying no. Constraints drive creativity is the thesis, and the numbers back it.

This is worth sitting with, because the default failure mode for internal platforms is the opposite. Someone asks for server-side rendering, someone asks for a staging tier, someone asks for per-route middleware, and each yes adds a concept every future user has to understand. Quick's team held the line: the mental model stayed at "a folder of HTML becomes a URL," a contract small enough that, per the post, over half of Shopify's employees have created at least one site.

The infrastructure choices follow from the same discipline. A single VM and an rsync wrapper are not what a platform team builds when it is optimizing for a promotion packet. They are what it builds when it is optimizing for the user's loop staying trivial. The constraint is the product.

What only works inside a company

Two of Quick's design choices only work behind a corporate boundary, and the post is upfront about one of them. Quick has no permission system and no site ownership: any employee can overwrite any site. Inside a company, where everyone is identified, accountable, and on the same team, that is a smart trade. It removes an entire category of platform work, and the post acknowledges it would not survive in public.

The other inside-only choice is the access model itself. The Identity-Aware Proxy answers "who can see this?" with "verified employees," which is exactly right internally and unavailable everywhere else. Neither choice is a flaw; both are correct engineering for the trust environment they live in. But they define what the public version of this loop has to add.

On the open internet, the same core loop needs three things Quick can skip. First, real ownership: a site belongs to whoever published it, with per-site access control, and updating it in place is a right held by the owner, not by anyone who knows the name. Second, privacy without a corporate proxy: an unguessable URL that acts as the credential, so a page is private by default without requiring the viewer to hold an account. Third, gates you can dial up when the link alone is not enough: a password, an email-domain gate that verifies viewers by magic link, so "company-only" works on the public internet, or end-to-end encryption where the server only ever stores ciphertext. Those are not extras on top of Quick's model; they are what Quick's model converts into once the Identity-Aware Proxy is gone.

The core loop already exists publicly

Full disclosure: we build Stacktree, so read this section as us describing where we sit. Quick's core loop, drop in HTML, get back a gated URL, is the loop Stacktree runs as a public product, with the public-grade requirements above built in.

The shape is the same. You publish HTML or Markdown and get back a private, unguessable URL; the URL is the credential, so nobody needs an account to view. If you want Quick's "only our company can see this" behavior on the open internet, you add an email-domain gate, and viewers verify with a magic link to their work address. If you want stricter, there is a password option and end-to-end encryption. Sites have real ownership: update_site replaces a site in place at one stable URL, and only the owner can do it, which is the public answer to Quick's anyone-can-overwrite model.

The publishing side is agent-native, because that is who writes the HTML now. Stacktree is exposed over MCP, so Claude Code, Cursor, Codex, and Claude.ai can publish directly, and there is a plain REST API for curl. The first publish is anonymous, no account, live for 24 hours; the free tier is 5 permanent sites at 25MB each, and Pro is $8 a month with custom domains. Agents can even pay for themselves, over x402 with USDC settling on Base mainnet, or via a scan-to-pay QR card payment with an optional prepaid balance. And where Quick runs on one VM, Stacktree runs on Cloudflare Workers, R2, and D1, with no VM at all; if you want an own-your-infrastructure posture, a self-host license is a one-time $999 and it runs on your own Cloudflare account.

Stacktree is static-on-purpose: HTML and Markdown publishing, no database, no app file-storage API, no WebSockets, no AI compute. That is the same discipline Shopify credits for Quick's success, a small, fixed set of capabilities and a willingness to say no, applied to a public product. The 50,000-site number Shopify reports is what the static core loop earns when it stays simple; that is the loop worth running publicly, and running well.

The open question: the optional state layer

The honest gap is the state layer. A subset of Quick sites use the bundled extras, the database, file uploads, WebSockets, the AI calls, and for that subset the value is real: an internal tool that records submissions or streams updates needs state, and Quick bundles it as an opt-in capability.

As a public product, that bundle mostly does not exist. There are public databases, public storage, and public AI APIs, but no public equivalent of Quick's arrangement, where the static host and the optional state layer share one identity, one URL scheme, and one deploy step. Whether the market wants that as a product, or whether the subset that needs state simply graduates to a full app platform, is genuinely open. We may build toward it or we may not; we are not promising it here. What we are confident about is the order of operations Quick demonstrates: the static loop is the core, the state layer is the option, and a platform that gets the first one right earns the right to ask the second question.

What to take from Quick if you run a platform team

The transferable lesson is supply-side: give people a place to put AI-made pages and they will use it. Over half of Shopify's employees created a site, per the post, because AI made the pages cheap and Quick kept the publishing free of friction. Your company is generating the same artifacts right now, prototypes, dashboards, write-ups rendered as HTML, and they are dying in Slack threads and local folders for want of a URL.

The implementation lesson is to keep the loop small. Quick's team shipped a file server and a sync wrapper, then spent its discipline saying no. If you build the internal version, start with folder in, URL out, behind whatever identity proxy you already run, and treat every capability request as a cost. If you would rather not build it, the public version of the core loop exists today, with the ownership and gating the open internet requires. Either way, the proof is in: this is a real category, and the bar for entering it is one good constraint, held.