--- title: "The three-week playground" description: "We scaffolded a /try web playground in 21 commits on April 15, scored it against a gimmick-risk rubric on April 16, and deleted it on May 7 with the lesson written into the commit message. The audit doc is still in the repo." publishDate: 2026-06-10T15:00:00.000Z author: Sarvesh Chidambaram tags: ["product", "process", "history"] canonical: https://memoire.cv/blog/the-three-week-playground --- ## Three dates April 15: built. April 16: audited. May 7: deleted. That is the entire life of `/try`, the web playground that was supposed to let people experience the product in the browser before installing anything. The whole arc fits in three weeks, and every beat of it is in the git log. This is the most useful failed feature in the repo's history, so it deserves a proper write-up. ## The build day 2026-04-15 was the single most manic day in the website's history: 55 commits, most of the v0.13 marketplace built in phases by a roster of named agents, and somewhere in the middle of it, `/try` scaffolded with five surfaces (commit 6a3082c, 2026-04-15, plus 20 more). Twenty-one commits in one day is enough room to get genuinely carried away, and I did. The playground grew a TikTok-style feed (commit cbf3b7e) and a variation tree (commit efaedcb) before the day was over. A feed. For a design-memory tool. At the time each commit felt like momentum. In hindsight the feature set was the tell: when a surface starts accumulating formats borrowed from entertainment products, it is optimizing for the demo, not the user. I am not going to pretend I saw that during the build. I saw it the next morning. ## The audit, eighteen hours later On 2026-04-16 I sat down and formally audited my own day-old work (commit 0f4de55, 2026-04-16). Not a gut check. A written scorecard, committed to the repo at `audits/try-write-audit.md`, grading `/try` and `/write` on four axes. One of the axes was named "Gimmick risk." The score that mattered: `/try/mcp` came out at gimmick 4, continuation 1. The way I read that pairing: maximally flashy, minimally likely to carry anyone into the real product. A visitor would poke the toy, feel a small spark, and leave. The playground demonstrated that the engine could do tricks in a browser tab. It did not demonstrate the actual value, which is memory that persists across an agent's runs on a real codebase. You cannot fake persistence in a sandbox that resets. Writing the audit the day after the build, rather than the day of, was accidental but turned out to be the mechanism. Same week, so I still remembered what every surface was for. Different day, so the dopamine from shipping had worn off. Day-of audits flatter the work. Week-later audits forget the intent. The morning after is the honest window. ## Three weeks of waiting The audit did not trigger a deletion. The scores just sat in the repo while the project's center of gravity moved. Over those three weeks the log is all engine and Studio: v0.13.0 and v0.13.1 cut on April 25, trust gates hardened in v0.14.4 on April 30, the native Mermaid Jam integration and Studio DMG build CI landing May 5, v0.17.0 cut May 7. Nothing in that stretch needed `/try`. Nobody routed a launch through it. The playground was not failing loudly. It was failing the quieter way: by being irrelevant to every decision that mattered. A gimmick score of 4 did not kill it. Three weeks of the roadmap ignoring it did. ## The deletion On 2026-05-07 the playground was deleted entirely, and the commit message carries the conclusion in plain text: the macOS Studio is the product (commit 6147959, 2026-05-07). The context makes it sharper. That same day the site got reskinned twice, the blog CMS launched with its first three posts, and the download page shipped with a single source of truth for releases. The deletion was not a retreat. It was the same energy that built 21 commits of playground in a day, pointed at the surfaces that actually convert: the post you read, the DMG you download, the app you keep. Deleting it entirely mattered too. Not feature-flagged off, not parked behind a redirect, removed. Half-killed features are worse than dead ones, because they keep collecting maintenance cost while providing the same value as the void. ## What stays in the repo `audits/try-write-audit.md` is still committed. The playground is gone; its autopsy is permanent. That is the part of build-measure-kill that I think most write-ups skip. Build is fun and kill is at least decisive. Measure is the step everyone fakes, because measuring honestly means writing down a 4 on gimmick risk about code you shipped eighteen hours ago and still like. The scorecard only worked because it existed in writing before the kill decision needed making. By May 7 there was no relitigating: the numbers had been sitting there for three weeks, in my own words. And keeping the audit in the repo means the next "what if people could try it in the browser" idea, which will absolutely come back someday, has to argue with a document instead of a memory. The document is hard to charm. Total cost of learning that the Studio is the product: one day of building, one morning of honest scoring, one deletion commit. The expensive version of the same lesson would have been maintaining `/try` for six months because deleting a day's work felt wasteful. Three weeks was the cheap price, and the commit message was the receipt.