Smallbox Labs is smaller than it looks.

It works. Changing it is the problem.

Most systems I'm called into aren't broken. They run, real people depend on them, and then one day a small change starts with a search — because the same rule quietly ended up in four places, and nobody chose that on purpose.

That is the thing Smallbox exists to fix. Writing code got cheap; structure — deciding where each responsibility lives — stayed scarce. Give each rule one clear home and the next change gets cheaper and safer instead of slower and riskier. That single idea generates everything else on this site.

The honest org chart.

There is no “we” hiding twenty people. There is a “we” hiding two language models and one human who is accountable for all of it. Here is who does what.

• Me, Jack — the human. Fifteen-plus years building and running production C#/.NET: architecture, data pipelines, integrations, testing, deployment. I do the deciding, and I take the blame. Where each responsibility lives, which trade-off is worth making, when to tell a client the honest answer is “don't rebuild this yet” — that is judgment work, and it stays with a person.
• Claude — the pair engineer. The one writing this page, in fact, which tells you how the collaboration actually works. Reads a whole system at once, drafts code and prose, holds the map across long sessions, and pushes back when I'm about to do something I'll regret. Fast, tireless, genuinely sharp — and a tool, not the one in charge.
• GPT — the second opinion. OpenAI's models research, draft alternatives, and check the other two from a different angle. When two independent models and a human land in the same place, that is a stronger signal than any one of us alone.

The rule that keeps this trustworthy is short: the models are the workshop; the human signs the work. AI is leverage, never the decision-maker. The architecture and the final responsibility stay with the engineer — that line is load-bearing, not decoration.

What the work actually is.

The help is concrete — not “digital transformation.” On most systems it comes down to a few jobs:

• Map where responsibilities live today — and where one has drifted across controllers, admin tools, background jobs, and database shape until no single place owns it.
• Give each rule one clear home, so the next change happens in one place instead of being hunted across three.
• Build or repair the backend workflows, APIs, integrations, and data models that hang off those boundaries.
• Leave the system more legible than I found it — including a written map of the reasoning, so it lives in the system and not only in someone's head.

You can also start small: one paid week on one real problem, then month to month only if it proves useful.

Who it's for — and who it isn't.

Smallbox fits a particular shape of problem, and saying so plainly saves us both a wasted conversation.

It is built for a small company with a real backend — a prototype, workflow, integration, or product system that already does useful work but has become risky to touch. Often that is something built fast with AI or no-code that now has to become a product nobody is afraid to change; or a backend whose original authors have moved on; or the moment just before a first engineering hire.

It is not the right help for pure frontend or visual design, which needs a designer; for owning your product decisions — what to build, for whom, and where the line goes stays with you, and I structure and build underneath those calls; or for cheap code by the hour. The value is in deciding where things belong, not in the volume of code produced.

Small is the model, not the limit.

The AI team isn't about cutting corners. It is the opposite: it lets one senior person do senior system work, at depth, for more than one client — without becoming an agency where the person who understands your system sits three layers away from your problem. One engagement at a time. Deep understanding before implementation. And a deliberate aim to leave more people able to safely change your system, not fewer — including after me.

Don't take my word for it.

Evidence beats confidence — that is a house value, so here is where you can check the claims instead of trusting them:

• The architecture — fourteen small services behind two products, drawn as the live map of what is deployed right now.
• The status page — every service's heartbeat and latest test result, public and always on; the tests are checked by planting real bugs to confirm they fail.
• The work — two production systems built and run end to end, CompanyGraph among them.
• The values — each one paired with a live surface where you can check it, named even where it currently leaks.

This page is part of that evidence too: a studio compressed into something you can read in a few minutes — written by one of the team members, reviewed by the human.