Before the second feature fights the first
Most products don’t fail. They drift.
You ship the first version and it works. Then it grows. A discount rule starts in Stripe, then shows up again in the admin, then leaks into onboarding, then gets patched into a nightly job. Nothing is broken — and that is the trap. The same rule now lives in four places nobody chose on purpose, and every change starts by searching for where it really lives.
That is the moment the question quietly changes. Early on it is can we add this? — and modern tools answer in an afternoon. Past a certain size it becomes where does this belong? — and the stack does not answer that one for you. The pieces were never the hard part. Where they live is.
Modern tools give you the pieces. Smallbox gives them a system to live in — proven by one real workflow.
That means one .NET product base where the core parts already have a place to live: accounts, an operable admin, transactional email, failures you can find, and a real deployment. One real product workflow then travels through all of it, end to end. Smallbox gives your next developer a serious place to start.
That next contributor might be the first developer you hire, an AI session with no memory of the last one, or you in six months. If what you hold today is an AI prototype, that situation has its own page; if it is a system you inherited, so does that.
Not every product needs this. A brochure site with a contact form does not — and an inherited system nobody fully understands starts with a System Report, not a build.
Build the first workflow properly and the tenth still has somewhere to go — the next one becomes a pattern to follow, not an argument to have again. Here is the shape that holds it:
The shape that holds it
↓ one API · typed contracts ↓
↓ typed SDK clients · a contract change is a compile error ↓
Surfaces on top, one seam in the middle, reusable modules below it, your engine beside them, and one place every failure lands. Media, billing, translation, and external integrations exist as proven optional modules in the same shape — added only when your product needs them.
This diagram is not a promise of future architecture. The running original — every real service behind CompanyGraph and Smallbox Labs, every line between them, clickable — is public on the live architecture map. What you are buying is that establishment, installed under your product.
One workflow, through every box
The diagram is not the deliverable. The deliverable is one real product workflow traveling through it, end to end. Here is that path as it actually runs today — sign-in by emailed link, step by step through the boxes above:
- Your website
A visitor asks to sign in.
They type their email on your website. That is the whole form.
- Backend
The backend takes the request.
One API call. The backend drives the sequence from here — the modules below it never call each other.
- Identity
Identity issues the account.
An account exists now if it did not before — asking twice is safe — and a signed sign-in token comes back.
Email carries the link.
The sign-in link goes out through the email module: templated, queued, kept in history.
- Backend
The click becomes a session.
The link lands back at the backend, the token is checked against identity, and a secure cookie signs the visitor in.
- Your admin
The operator sees the result.
The visitor, the account it became, and what it has done since — all visible on the admin.
- Logging
Every step left a record.
Each box reports here as it works; a failure anywhere in the chain becomes a record someone can find on Monday.
One path, five receipts: the account is real, the email is real, the operator can see it, a failure would land as a record, and the whole thing is deployed. This exact sequence runs behind CompanyGraph today; in the build, your first workflow travels the same way — different steps, same boxes, same bar.
That single path is what the connections mean in practice. Identity actually gates the action. The rules run in one layer, not wherever code happened to land. The email goes through a queue with history instead of vanishing. The admin shows the result without anyone opening the database. The log answers “why did this break” with one query. Once that path holds, the second workflow is a pattern to follow rather than a fresh argument — and it is the worked example your next developer, or your next AI session, builds from.
The accepted cost: building one workflow properly takes longer than stubbing five. Five stubs prove nothing connects; one real flow proves the foundation is real.
The foundation is supposed to feel boring once it works: users log in, emails send, failures surface, admin screens answer questions, and deployment is repeatable.
What is included
Accounts and roles. An operable admin. Transactional email with a visible history. Failures as records, not lost log lines. A production deployment with health checks and handoff docs. The first workflow, wired through all of it. And a written orientation for whoever continues the system — the rules with their reasons, and the first workflow named as the pattern to follow.
Each piece already runs in production — none of it is invented for your project. For the evaluator who wants depth: the full technical inventory, every connection, and why each one exists is on the Foundation Map. You do not need it to understand the offer.
Why this is an edge, in the AI era
An AI assistant produces working screens in days — this package assumes you keep using that speed. But raw speed is no longer an edge, because everyone has it now. The first version of anything is a weekend, not a moat.
The bottleneck moved to change — who can keep safely changing a growing system. AI is genuinely fast at that, but only on a codebase with a shape it can reason about: one home per responsibility, contracts it cannot silently break. Point the same assistant at a tangle and it only deepens it — re-deriving the architecture every session, solving the same problem three ways, breaking things it cannot see. The foundation is the part generation does not produce: the structure the fast pieces land inside.
That is the edge, and it is mechanical, not motivational: a structured codebase is the only kind AI can keep building safely — so the foundation turns AI from a one-time head start everyone gets into a compounding advantage only the structured keep. Everyone is fast in month one. The foundation decides who is still fast in month twelve. (The mechanism, written out.)
Proof — already running
CompanyGraph — a full stock-analysis platform — and Smallbox Labs, the site you are reading, both run on this exact shape: the same identity service, the same email service, the same admin pattern, the same deployment. The foundation is reusable because it has already been reused.
Ownership, plainly
You own the product-specific code, workflows, schema, and the running system.
The reusable foundation modules are licensed, not sold — perpetual and irrevocable, with a source snapshot at handoff. Nothing depends on Smallbox staying online.
Your domain engine never enters the catalogue.
Updates are optional, bounded work — never an obligation in either direction.
The full terms live in your engagement agreement, in the same plain language; the public, plain-language version is on the ownership & terms page.
How the build works
The foundation is installed in an environment you own, not inside Smallbox’s infrastructure — your domain, your server, your repositories. The whole path, in order:
- Together
Agree the scope.
A short, free conversation names the modules in scope, the first workflow, where the system deploys, and what is explicitly out — in writing before any work is billed.
- You
Start the build.
€2,500 starts the build — the only payment until the first workflow runs.
- You
Create the working ground.
A domain, a small cloud server, and Git repositories Smallbox can commit to — an afternoon of setup, not a project. A small Hetzner server or equivalent is the right start: a few euros a month, and real enough to test the system honestly. The scoping conversation walks through it if this is new to you.
- Smallbox
Smallbox sets up the environment.
One repository per running service, each deploying on its own when code is pushed — the code boundary matches the way the system actually runs. Database, health checks, domain routing; the server starts as staging and is promoted, upgraded, or moved when production needs are clearer.
- Smallbox
Smallbox installs the foundation.
The website surface, the admin, your product’s backend, identity, email, logging — every box on the map above, now running in your environment.
- Together
The first workflow goes through.
Wired end to end, clarified together in a few short conversations, until one real path runs through the whole system.
- You
Inspect the result yourself.
Visit the domain, sign in, open the admin, find the email in its history, read the records every step left — and follow the first workflow through the running system.
- You
Pay the balance.
The remaining €7,500 is due when the first workflow runs end to end in your environment — after you have clicked through it, not before.
- Smallbox
Handoff.
The code is in your repositories, the system runs on your server, and the handoff docs say where future changes go. If you already have a developer, handoff includes a walkthrough together; if you hire one later, the same walkthrough is bounded follow-up work, not a dependency.
One boundary on scope: the package does not include your domain engine, branding, the hosting bill, or open-ended support — anything beyond the fixed scope is named up front and quoted separately.
Send your first workflow — five to eight steps, in plain language — and one line on the product. Smallbox will tell you honestly whether the foundation path fits or you should start with a System Report.