smallbox

← All articles

Getting the base right

If Smallbox builds it, what do I actually own?

Own the product, license the foundation

The honest version of "what do I own?" is a colder question: what happens to the product the day the people who built it stop answering email? If the answer is it keeps running, and someone else can change it, you own it. If the answer is that depends on them staying reachable, you don't — you're renting something that feels like ownership right up until the moment you test it. So this is worth being precise about, because a foundation build hands you two different kinds of thing, owned in two different ways, and quietly conflating them is how people end up surprised a year later.

The product is yours, outright, from the first day

Start with the part that isn't subtle. The product Smallbox builds — the code, the database, the running system, and the data inside it — is yours outright. Not yours-via-an-agency-account with you listed as a collaborator who can be removed. The domain is registered to you. The server is your server. The repositories are in your name, one per service, and they deploy to your machine when you push to them. From the first day, before a single workflow runs end to end, the thing being built already lives in an environment you own and could, if it came to it, change the locks on.

That sounds like a procurement detail and it's actually the whole game, because the common alternative is so quiet about its consequences. A great deal of custom software is built on the builder's accounts — their cloud project, their repository, their deployment pipeline — and handed over as access rather than ownership. It works perfectly while the relationship is good. Then the relationship ends, and the "handover" turns out to be a migration off someone else's infrastructure, and the migration is leverage in a conversation you didn't know you'd be having. Owning the environment from day one means there is no handover, because there was never a moment the product lived somewhere that wasn't yours. The thing you'd otherwise have to extract under pressure was never anywhere you'd have to extract it from.

The foundation is licensed — and a snapshot makes that safe

The second thing you receive is the foundation itself: the catalogue of subsystem patterns the build draws from — accounts and identity, billing, email, file storage, content, logging, the admin, the deployment shape. Those aren't invented fresh for your project; they're the same proven patterns that already run under CompanyGraph, brought to your product. That accumulated catalogue is the thing Smallbox carries forward and improves across every build, and what you're licensed is access to it — the right to use these patterns in your product — rather than an obligation that meters or leases back what you've already got installed.

The word "license" is where people brace for the catch, so here is the part that removes it: you receive the source. Everything installed in your product ships to you as code you hold, read, and change. The licence governs the living catalogue — the ongoing body of patterns Smallbox keeps developing — not your copy of what was built into your system. Your copy is simply part of your product, and your product is yours by the section above. So the practical effect of "license the foundation, own the product" is not a leash. It's that you own your running system completely, you're separately given access to the catalogue it came from, and a snapshot of the source means that access can never be retracted out from under the thing you're already running. There is no version of the future where someone reaches into a system you own and switches a part of it off.

The test that decides whether any of this is real

All of that is structure, and structure is worth exactly as much as it survives contact with the builder leaving. The test is blunt: can someone who didn't build the system operate it and change it without the original author in the room? If yes, you own a product. If no, you own a dependency on a person, dressed up as a product.

This is why the foundation spends real effort on the parts that never demo well — an admin where an operator reads what happened to a customer from a screen instead of from the database, a single log every service writes to, a deployment a newly hired developer can run on their first afternoon. None of that is polish. It is the machinery that makes the absent-author case true, and the absent-author case is the only definition of ownership that means anything once the invoice is paid. The full argument for it — why operability, not features, is the thing that costs money up front — is what it actually takes to run a system without its author present.

You can check it before you have to believe it

The reassuring version of this would be a promise on a page. The checkable version is that the absent-author case is already true of the foundation itself, in public, right now, on systems that aren't yours — and you can confirm it without taking anyone's word. The same base runs underneath two different products. An operator who isn't the person who wrote it runs each one from an admin. None of that requires the author to be reachable for it to keep working, which is precisely the property you'd be buying — demonstrated on the builder's own systems before it's ever promised on yours. The map of those modules, photographed running rather than drawn is where that's laid out to look at directly.

The verdict

You own the product — the code, the server, the data, the running system — outright, from day one, in your name. You license the foundation — access to the catalogue of patterns the product is built from — and a source snapshot means that access can't be clawed back from what you're already running. The line between the two ends up mattering less than the single property they add up to: a system that keeps running, and stays changeable, when the people who built it are no longer in the room. That's the only kind of ownership worth paying for, because it's the only kind that's still there the day you actually test it. What that buys you, module by module, is the foundation — and the point of owning it this way is that you never have to find out the hard way which parts you only thought were yours.

Articles describe the Foundation. The Foundation Map is the thing itself — accounts, admin, email, logging, and deployment, with one real workflow running through them.

← All articles