At a Glance
- We build our own apps on a Flutter and Parse stack we have spent years sharpening. Enough people asked how that we packaged it into a product: Zovia Snapshot.
- The hard decision was not what to include. It was what to leave out. Ship too much and you hand the buyer a black box they cannot own. Ship too little and Claude hallucinates the gaps.
- Our rule: vendor as real source only the foundation Claude cannot reliably rebuild, and let Claude build everything else from a rulebook. The design system and backend layer go in the box. The app does not.
- It comes in two layers: the stack for working developers, and the same stack plus a Claude-delivered guide that teaches a technically literate builder to ship a real app. One is for people who can already read the code. The other is for people learning to.
- This is a build-in-public post, not a sales page. It includes an honest section on who should not buy this.
We are a small studio. We ship a growing set of consumer apps, all on the same Flutter package ecosystem and the same Parse backend, and we have written before about the pieces of that machine: the cross-app authentication, the receipt engine, the schema validator, the workflow that keeps us from running out of Claude tokens.
After enough of those, a pattern showed up in our inbox. People did not want another article about how we built a thing. They wanted the thing. The design system, the backend wrapper, the rules, the guardrails, the setup that makes a new app feel eighty percent done on day one. Could they just have it.
So we packaged it. It is called Zovia Snapshot, and this is the honest story of building it, including the parts we are still unsure about.
Why sell it at all
The stack is our advantage. Handing it to strangers sounds like giving away the store. We decided to do it anyway, for two reasons.
The first is that the advantage was never the code sitting still. It is the code plus the judgment that shaped it, plus the habit of maintaining it, plus the next hundred decisions. A snapshot of the foundation is genuinely useful to someone else and still does not hand them the studio. We know this because we lived the other side of it: our first agency client shipped in three weeks precisely because a real foundation existed to build on. The foundation is a head start, not a finish line.
The second reason is simpler. Building with an AI coding agent has a quiet failure mode: a blank repo. Claude is extraordinary at extending a codebase that already has taste and structure, and merely competent at inventing that taste from nothing. The most valuable thing you can give someone building with Claude is not a tutorial. It is a starting point that is already opinionated, so every prompt after it inherits the opinions. That is a thing we happen to have.
The decision that shaped everything: what goes in the box
Here is the whole design problem in one sentence. If you ship too much, the buyer gets a finished app they do not understand and cannot own. If you ship too little, Claude fills the gaps by guessing, and guessing is where the hallucinations live.
The resolution we landed on, and the single most load-bearing decision in the product:
Ship as real, vendored source only the foundation Claude cannot reliably rebuild. Let Claude build everything else from a rulebook.
Concretely, three things go in the box as actual source code, identical for every buyer:
- The design system. 132 components, tokens, the whole visual language. This is thousands of small consistent decisions. Ask an AI to regenerate it and you get something plausible and subtly incoherent. It has to be the real thing.
- The backend layer. The service wrapper that every server call goes through, plus the initialization. Get this wrong and nothing talks to anything. It has to be the real thing.
- The analytics layer, which the design system leans on.
Around 39,000 lines of production Dart, counted from the shipped source, not estimated.
And then, deliberately, the app itself does not go in the box. The screens, the features, the navigation, the auth flow: Claude builds those in the buyer’s own project, from a rulebook of conventions, a set of snippets, and cloud-function templates. Not because we were lazy about packaging. Because a feature Claude builds from your rules, in front of you, is a feature you understand and can change. A feature we pre-build and hand over is a black box the moment it needs to bend.
The line between the two is the product. Vendor what must be identical and is expensive to get right. Generate what should be yours and is cheap to get right with good rules. Most boilerplate products sit on one side or the other: a finished template you fight to customize, or a pile of snippets that never cohere. The interesting space is the seam between them.
What we refused to put in the box
Build-in-public means the subtractions too.
Our real auth. Our own apps sign users in with a custom device-credential and passkey system. It is the thing we are proudest of, and it is exactly wrong for a buyer, because it depends on cloud functions that live in our backend and nobody else’s. Shipping it would have handed over code that cannot run. So the starter uses standard, boring, correct Parse authentication instead: email and password with verification, password reset, Google sign-in, an email one-time-code template. Less clever. Actually usable by someone who is not us.
Every secret. The bundle build ends with a gate that fails the whole thing if a single one of our backend identifiers is found inside either zip. Not a code review step a human might skip. A hard stop in the script. We verified the shipped bundle by extracting it outside our own repo, where nothing could mask a mistake, and building it clean from scratch.
A finished app. Tempting, and wrong, for the reason above. The value is a foundation you extend, not a destination you inherit.
Two layers, two very different buyers
The stack alone is one product. The stack plus a guide is the other, and the guide is the part we care most about.
The guide is a teaching layer delivered entirely through Claude Code. A setup module where Claude verifies each install step before moving on. A curriculum that goes beat by beat, first building a small website to learn the motions, then building and extending a real app on the starter. A progress file so you can close the laptop and pick up where you left. A single bootstrap prompt to start the whole thing. We did not invent this mechanic for the product. We had already built it to teach a family member to code inside our own repo, and we lifted the shape of it wholesale.
The two layers sort cleanly by who you are. The stack alone is for a working developer who wants the foundation and will drive Claude themselves. The stack plus the guide is for a technically literate person with a computing background who is not yet a working app developer, and wants to become one by shipping something real rather than watching a course.
That second person is the one we built this for. Which brings us to the uncomfortable part.
Who this is not for
We would rather talk someone out of buying than watch them buy the wrong thing and struggle. So, plainly:
This is not a no-code product. There is a floor, and the floor is real. You need to be able to read code, understand basic architecture, and hold a mental model of how a client, a backend, and a database fit together. Claude does the typing. You do the directing, and you cannot direct what you cannot follow. If you have never programmed, this is the wrong starting point, and no amount of guide will change that. Start somewhere gentler and come back.
There is no human support. It is self-serve by design. The guide is thorough and Claude is patient, but nobody is on the other end of a ticket. If you need a person to unblock you, this is not that.
It is not a shortcut around learning. The guide compresses the path. It does not delete it. You will still have to think, get stuck, and work through it. That is the point, not a defect.
If you read those three and felt relief rather than disappointment, you are probably exactly who this is for.
The pricing, and what we are honestly unsure about
Two tiers. The stack on its own, and the stack plus the guide, which is the one most people should want. Early buyers, the first hundred, get an intro price well under the list price. The current numbers live on the site rather than in this post, because they will move.
The model is one-time, not subscription. You own what you download, forever, for unlimited personal and commercial use. Today it is purely one-time: there is nothing to renew and nothing to lapse. Updates are currently included, so buying now gets you every future version at no extra cost. We may add an optional yearly renewal for continued updates later. If we ever do, the same promise will hold, let it lapse and you keep the last version you pulled, and nothing you paid for gets taken back. But that is a possible future, not something you buy today. We chose this shape because the downloadable-code category is overwhelmingly one-time or lifetime, and subscription pricing really only fits the hosted AI builders that own the entire inference loop. We do not own your loop. You bring your own Claude, your own backend, your own keys. Charging you rent for code sitting on your disk would be dishonest.
The part we will say out loud: we set the prices against comparable products, not against demand we have measured, because we have not measured it yet. We launched low on purpose and we will adjust as we learn. That is the honest state of it.
To keep the recurring update fee honest rather than a nag, the stack carries a public dated changelog, a quiet once-a-day check that tells you if a newer snapshot exists and otherwise stays silent, and up-front copy about exactly what you own and keep. A weekly internal sweep tracks the Claude model lineup, the Flutter and Dart versions, Parse, and every pinned dependency, and folds safe updates in. The stack you download is frozen and verified per release, not drifting under you.
The takeaway
Packaging your own stack into a product forces a clarity you can avoid forever while you are just using it. You have to decide, precisely, which parts are the irreplaceable foundation and which parts are just this week’s implementation. For us the answer turned out to be a clean line: vendor the design system and the backend layer as real source, because an AI cannot rebuild them faithfully, and let Claude build the rest from good rules, because it can, and because code you watched it build is code you can own.
That line is the product. Everything else, the two tiers, the guide, the pricing, the update mechanics, follows from it.
If you want to see what is actually in the box, down to the counted component and line, it is all laid out at snapshot.zovia.studio. And if you got here from the post about not running out of tokens, this is the packaged version of that same system. the rulebook, the guardrails, and the model-sizing discipline, wired into a stack you can build on today.
Built at Zovia Studio. We ship apps that families use every day, and we decided to ship the workbench too.