← Smallbox

What you own, what you can change, what Smallbox stands behind

Ownership, licence, and responsibility

This page explains, in plain language, what you own when Smallbox builds your foundation, what you can do with the code, and what Smallbox is — and isn’t — responsible for after handoff.

None of it is meant to read as fine print. The promises here are deliberately in your favour; the boundaries exist so the work stays well-defined for both sides. This is the readable version — where it summarises, the engagement agreement you sign before any work begins is what governs, written in this same plain language.

What you get

A Smallbox engagement delivers a foundation-based system: the foundation modules you agreed on — accounts, an operable admin, transactional email, failure visibility, a real deployment — and one first product workflow wired end to end through them, running in an environment you own. The full shape is on the package page and the Foundation Map; this page is about what happens to that system once it is yours.

What you can do with the code

The delivered system is yours to run a business on: use it for your own product or company, modify it however you need, deploy it where you like, extend it with new workflows, and hire another developer — or several — to continue the work. Nothing in the arrangement ties you to Smallbox to keep building.

In plain English — you can build your business on the code. You can change it, extend it, and hand it to another developer whenever you want.

What you own, and what Smallbox keeps

Two things are yours outright, after payment: the product-specific code, content, branding, configuration, workflows, and business logic built for your project — and the running system itself. Your domain engine, the part that makes the product yours, is never part of the reusable catalogue. It is yours.

The reusable foundation — the modules, patterns, structure, and general approach Smallbox carries from one product to the next — is licensed to you, not sold: perpetually and irrevocably, with a source snapshot at handoff. You are not renting it, and nothing depends on Smallbox staying online — the system does not stop working if Smallbox does.

In plain English — your product is yours; the reusable foundation is licensed to you for good. You are not renting it, and nothing breaks if Smallbox disappears.

What is not allowed

One boundary protects the foundation itself. You may not resell, sublicense, publish, repackage, or offer the Smallbox foundation as a product in its own right — a starter kit, template, framework, SaaS foundation, or competing development service. The line is between the reusable base and what you build with it: you are free to build and sell your own product on the foundation, even when that product is itself a SaaS. What you cannot do is take the foundation and sell it on as a foundation.

In plain English — use the foundation to build your business. Just don’t repackage the Smallbox foundation and sell it as your own foundation.

What Smallbox is responsible for

Smallbox is responsible for delivering the scope you agreed and for fixing defects in that scope during the review window after delivery. That responsibility is bounded by the scope you agreed and paid for; the engagement agreement sets the bound out precisely.

After handoff, Smallbox does not become permanently responsible for everything the system later touches: changes you or another developer make, new features, a move to different hosting, a third-party service changing its API or pricing, scaling for growth, or security issues introduced by changed configuration. Any of those can become new work under a separate agreement — they are not open-ended obligations carried for free.

In plain English — Smallbox stands behind what it agreed to deliver. It does not become permanently responsible for every future change, API break, or developer decision after handoff.

Acceptance and defects

Delivery has a clear moment: the first workflow runs end to end in your environment, and you click through it yourself. From there, a short review window — 30 days by default, unless the engagement agreement says otherwise — is the time to report defects in the agreed scope, which Smallbox fixes. After that window, new requests are new, separately-quoted work rather than corrections.

Testing and verification

The agreed workflow is delivered with tests around it and around the modules it depends on. Tests are there to lower risk and to make the next change safer to make — they are not a promise that the system is free of every possible bug, now or forever. What Smallbox promises is narrower and honest: the workflow you agreed on is verified as part of delivery, and you can watch it run.

In plain English — the agreed workflow is tested and verified at delivery. Tests lower risk; no test suite removes it entirely.

Third-party services

A working system usually leans on services Smallbox does not own — a payment provider, an email sender, a language or AI API, the server it runs on. Those belong to their providers and run on their terms. Smallbox is not responsible for their pricing, outages, API changes, quota limits, account decisions, or policy changes. Keeping the system current as those services evolve is work that can be arranged, not a standing guarantee.

Hosting and maintenance

The system runs in an environment you own — your domain, your server, your repositories. The hosting bills are yours, paid to your providers, and you keep full control. Ongoing maintenance — monitoring, updates, backups, security patching, and support — is separate work, arranged when you want it, rather than something bundled in by default.

In plain English — the system runs on infrastructure you own and control. Keeping it maintained over time is separate work unless we agree otherwise.

Future foundation modules

The foundation is not frozen on the day you buy it. Smallbox keeps improving it — new modules, cleaner versions of existing ones, fixes at the foundation level — and as a foundation client, newer module versions are yours to take when they are available. That access is the licence, not the labour: taking a newer module does not include installing, migrating, configuring, adapting, or testing it inside your system. That is separate work, arranged if and when you want it. These modules are not public open-source releases either — they are for foundation clients, under the same terms as the rest: use them in your own product, do not repackage them for resale.

In plain English — the foundation is not frozen on the day you buy it; you can take newer modules as they are released. Fitting them into your product is separate work unless we agree otherwise.

No business-result guarantee

Smallbox builds the technical system you agreed on. It does not guarantee a business outcome — revenue, customers, product-market fit, search traffic, conversion, funding, or success. Those depend on far more than the code. What Smallbox stands behind is that the system is real, runs, and is built to be continued.

← Smallbox