I was hunting for a build last Tuesday and couldn't remember what I'd named the chat — "landing page v2," maybe, or something equally useless six weeks later. That's usually the moment My Builds stops being a nice-to-have and becomes the tool you actually reach for. Past your third or fourth generated app, scrolling a chat list to find a thing you made is slower than it should be, and the library is built for exactly that gap.
I typed "admin" into the search bar first, out of habit, then gave up and used the filters instead: Type narrowed to web app, Category cut it down further to internal tools versus client-facing ones, and there it was — three cards in, a version badge reading v3. I'd forgotten I'd gone back into that chat twice. The library wasn't showing me duplicates; it was showing lineage. v1 and v2 hadn't vanished, they'd just stepped out of the default view, and that turned out to matter about ten minutes later when the client on a different project hated a nav change I'd shipped as v4. I opened the old v3 card, browsed its file tree in place, grabbed the two files that mattered, and redeployed. No re-prompting, no digging through a chat transcript trying to reconstruct what the layout used to look like.
That's the part of card anatomy that earns its keep before you even open anything: a real screenshot as the thumbnail, captured post-verification, so what you see is what actually rendered rather than a build that technically finished but errored on load. Underneath that, type and category badges, a version number, a relative timestamp. Enough to triage without a click. And when you do click, the choices split cleanly —
- Preview opens the live build directly, no download, no local server. For a website it's the deployed experience; for a desktop or mobile build it's about as close as you get to running it without installing.
- Code is the file tree, browsable right there. I use this constantly for a thirty-second gut check — did it actually use the library I asked for — before committing to a download.
- The actions menu covers download, publish, native installers for anything that supports them, ship to store where it's store-eligible, and save as template.
None of that needs the conversation reopened. I only went back into the original chat once that day, and it was to ask for an actual change, which is the one thing the library genuinely can't do for you — changes need context, and context lives in the thread. Everything else, the library covers on its own, running in parallel to chat rather than as a shortcut back into it. Publish something from the card and the chat reflects it next time you open that thread; publish it from inside the chat and the card updates too. Same build, two doors.
Later that afternoon a teammate asked for a link to something I'd built the week before, and I noticed I didn't send her into the conversation — I sent the card, and honestly I'd have sent the published URL off the card if it'd been live already. Nobody wants to be handed a stranger's chat history to find one file. Once a team's got more than a couple of builds per person, this splits pretty naturally: the chat stays your private workshop, the library becomes the thing other people actually touch.
I also had a game sitting in there from a weekend project, which is where I got reminded the library isn't the only lens on the same data. Games show up in My Builds like anything else, but they also live in My Games, filtered by play-mode and publish status, and if games are most of what you make that's the better daily view. Same logic applies to Published, which shows current live state for anything with a URL or a store queue, and Shipped, which tracks app-store or extension-store review status. Different questions against the same cards — "what's live right now" versus "what did I build about topic X" — not separate systems bolted together.
One thing caught me off guard the first time I hit it: publishing a build doesn't freeze it. I went back into that admin panel's chat afterward, asked for a change, got a v4 — and the live published version kept serving v3 until I explicitly redeployed. Made sense once I thought about it. If every stray prompt against a live chat could break a production site, nobody would ever touch a published build again.
The other thing I did that week, almost as an afterthought, was save the admin panel as a template. It was the third internal tool I'd built with basically the same bones — same layout, same auth scaffolding, same table components, just different data underneath. Saving as a template pulled the structure and style, not the specific content, and starting build four from it turned what would've been a twenty-minute planning conversation into about five. The catch is that a template is frozen at the moment you save it — my conventions have shifted since, and the old template doesn't know that. Fine for a starting point you're going to diverge from anyway; if you want reuse that actually stays in sync, you're better off referencing files across builds directly than templating them.
Nothing expires. That v1 from six weeks back, still sitting under v3 in the lineage — still previewable, downloadable, publishable, exactly as retrievable as the thing I built this morning. No pruning clock running in the background. The library is an archive you can ship from, not a history page you're racing against.
Handbook
← All posts
