You built it with AI
A prototype from Lovable, Bolt, Cursor, or Claude that works but can’t take real users yet — no accounts, no admin, no safe way to change what already runs. The prototype is the spec, not the mistake.
It works. Changing it is the problem.
You built it fast — maybe with AI (Lovable, Bolt, Cursor, Claude), maybe by hand, maybe you inherited it from someone who’s gone. It runs. But now one rule lives in four places, every small change starts with a search, and shipping anything feels like it might break something nobody left a note about.
That isn’t bad code, and it isn’t AI’s fault. The parts of a growing product never got a place to live, and no one decided that on purpose. Smallbox builds the structure your product should have grown inside — and proves it by moving your first real workflow into it, end to end.
Before anyone calls it tech debt
You can feel it before you can name it.
The product still works. But shipping gets slower than it should, and the day-to-day starts to sound like this:
- “Why is this small change taking so long?”
- “We fixed it here, and it broke over there.”
- “Every change starts with a search.”
- “Only one person really knows how that part works.”
- “We let AI write more of it, and now no one’s sure where anything lives.”
That usually gets blamed on bad code, or a slow team. Far more often it’s something quieter — the parts of a growing product never got a place to live, and no one decided that on purpose.
What you’re actually paying for
A prototype treats a feature as one thing. A product can’t.
You add one simple feature. Then it needs a setting, an email, an admin action, a database field, a permission rule, an error case, a background job. Suddenly the feature isn’t one thing — it’s seven, and each part needs somewhere to live.
- Who the user isone place identity lives, not re-checked in five
- The email it sendsone email service, with templates and a history
- What an admin can see and doone operable admin
- The rule it followsone home in the product, not copied into the frontend, the admin, and a database script
- The data it writesthe one box that owns that data
- What happens when it breakslogs you can actually search
- Getting it deployed and runninga real deployment, not a laptop
Left alone, those parts still get placed — just not on purpose. The rule ends up in the frontend and a database script. The truth about what the product does moves into one developer’s head. That isn’t bad code or a bad developer; it’s what growth does to a product when no one decides where things go. Either responsibility is placed deliberately, or it spreads accidentally.
Those homes, taken together, are your product’s Responsibility Spine — the structure where every responsibility has one clear place to live. Smallbox builds it early, while the product is still small enough to shape, and wires one real workflow through it — so the second feature reuses it instead of inventing it again, and the tenth still has somewhere to land. The feature works either way. The difference is everything that comes after it.
Not the fastest way to ship the first feature. A faster way to keep adding them after the first one works.
The main offer
We don’t rebuild your app. We give it a structure to live in.
One deployed .NET product with its Responsibility Spine already in place — accounts, an operable admin, transactional email, failures you can find, a real deployment — and your first real workflow moved into it, end to end, as the worked example.
- We install the base — deployed, not a sketch.
- We move one real workflow into it, end to end.
- You get a running, observable system — with failures you can see.
- The rest gets migrated the same way — by you, your AI, or us — because the hard part, deciding where everything goes, is already done.
That last step is the whole point. The same AI that made the tangle becomes fast and safe again once there is a structure to build into — it stops guessing where things belong, because the answer already exists.
Proof in production
The same shape already runs in production.
The base behind the offer is not a diagram. That exact shape runs today behind CompanyGraph and behind Smallbox Labs itself, with several of its modules carrying both products at once.
- Architecture →The fleet, the seams, and the one inner shape every service repeats.
- Status →The live pulse of the systems we run. Public, always on.
- Testing →How a change is proven safe before it ships.
- Cases →Two production systems we built and operate end to end.
- Articles →The thinking behind the method, problem-first.
Different origins, one condition
Which of these is you?
The same tangle, four ways of arriving at it. Each has a page that speaks to it directly — start where you actually are.
You outgrew no-code
A Bubble, Webflow, or Airtable build that proved the idea, then hit the platform’s ceiling — the thing you need next is the thing it will not let you do. What you built is the spec, not the mistake.
You’re about to hire a developer
The morning your first hire clones the repo decides their first quarter: a base to build on, or three months spent building one alone, under pressure to ship.
You inherited a tangled system
A running system whose authors are gone, where the next change feels risky. When it’s too large to price blind, a read-only System Report maps what is safe to change before anything is rebuilt.
Who we are
A small studio. One system at a time.
Smallbox is an intentionally small backend studio — 15+ years in production C#/.NET: architecture, data pipelines, integrations, testing, deployment. One engagement at a time, clear responsibility, deep understanding before implementation. AI is used as a tool, not a replacement for thinking; the architecture and the final responsibility stay with the engineer.
Get in touch
Send your system context.
Send a short description of your system, what you want to change, and what context is available.
You decide the access boundary. Smallbox works inside it. Nothing is required before the first email, and the more context you can share, the more precise the assessment.
hello.smallbox@proton.meAnswer only what you can. Nothing has to be complete.
You'll get a reply on the right starting point — Prototype to Product + First Workflow, a System Report, or a smaller bounded build — and what access or context would help.
The better the access and collaboration, the more precise the report.