From a Slack link to production in under 48 hours: cloning Shopify's "Quick" with Devin

Inside CourtyardJun 13, 2026

From a Slack link to production in under 48 hours: cloning Shopify's "Quick" with Devin<br>by<br>Joe Petrich

On a Wednesday night, Katherine Champagne dropped a link in our #ai-adventures Slack channel about Quick , Shopify's internal tool that lets anyone — engineer or not — ship a static site in seconds. By Thursday night we had our own version live on an internal domain, behind SSO, fully git-backed, built in Go, deployed on Cloud Run via Bazel and Terraform. Total elapsed time from "look at this cool thing" to "it's live in production": about 21 hours. A full slate of follow-on features — a redesigned UI with sound, a quick push/pull CLI, auto-generated site thumbnails — landed within the next day.<br>We didn't staff a team for it or slow down on our (many) existing priorities. We pointed Devin with Fable 5 at the idea, told it our constraints, and reviewed its work collaboratively as it went.<br>The spark<br>It started the way a lot of good ideas do — someone noticed something and shared it:<br>"[this is] how Shopify lets anyone from any team deploy static html (with option for some simple backend functionality too). The claimed adoption is amazing!!!"<br>Shopify's Quick is a genuinely clever piece of internal tooling: drag in some HTML, get a live URL. No tickets, no pipelines, no waiting on an engineering team. The adoption numbers in the thread were the eye-catching part - when you make shipping trivial, everyone ships.<br>The obvious question: could we have that at Courtyard? This idea had come up in the past, but usually with caveats like "make the deployment relatively easy" or "give non-engineers easy-to-use git tools" not "make deployments not a thing" or "make version control invisible and painless."<br>So we asked Devin to build it.<br>The constraints (and how they shaped the thing)<br>This is the part that makes the story worth telling. We didn't hand over a spec. We handed over a few principles and let the design fall out of a back-and-forth in Slack. Every one of these started as a comment in the thread:<br>"It should be git-backed." Every deploy is a real git commit. That gives you full history and one-command rollback for free, instead of an opaque blob sitting in a storage bucket.<br>"This shouldn't live in experimental/. It should be real code." The first prototype was a quick FastAPI app in a sandbox folder. We threw that away and made Quick a real, production-reviewed service, one whose whole job is to let people publish sites by dropping files into their own experimental//sites/ folder.<br>"If I'm going to review it, it should be in Go. And we prefer Bazel." Devin rewrote the service in dependency-free Go (standard library only, single binary), studied our existing repo to match our conventions, and wired it into Bazel with rules_go + Gazelle.<br>"Non-engineers need a drag-and-drop UI but it still has to be git-backed." This was the most interesting tension. The answer: the web UI takes your identity from the SSO header that our IAP proxy injects (X-Goog-Authenticated-User-Email), writes your files into the repo, commits with you as the author, pushes a branch, and opens a PR that our existing auto-approver merges. A non-technical user never sees git. But every single deploy is still a reviewed-by-policy commit with a full audit trail.<br>"Big files can't just fail." Our repo's CI blocks large binaries from ever entering git history — which would make Quick useless for anyone with an image-heavy site. So Devin built an invisible, git-LFS-style split: text files go to git as normal; anything large gets content-addressed (sha256), offloaded to a GCS bucket, and served back transparently. The person uploading never knows it happened.<br>Notice what's not in that list: nobody wrote a design doc. The architecture emerged from a handful of one-line product opinions, with Devin proposing the trade-offs (git-canonical vs. serving from GCS, how "commit as you" actually works, where the security boundaries sit) and us picking.<br>Working with the guardrails, not around them<br>The thing that could have turned this into a multi-week project is our own governance. Our monorepo has real teeth: an isolation check that bans PRs from mixing sandbox and production files, history-hygiene checks that reject oversized blobs, CODEOWNERS, and a human approval rule on production code.<br>Instead of asking us to relax any of that, Devin audited the constraints up front and designed within them. When a deploy needs to merge a PR on a non-technical user's behalf, it taught our existing experimental auto-approver a narrow, auditable carve-out. When we pushed back that the carve-out had to preserve the approver's core invariant (you can only auto-merge changes to your own folder), Devin tightened it so a bot deploy is only ever approvable for the deployer's own subdirectory, verified independently by the approver. Defense in depth, with BDD tests,...