Smallbox is a small backend studio for companies that need more than task execution. We study the system, make the hidden structure visible, and build only after the path is clear.
The first deliverable
Every serious project starts with a System Report. Not because we like documents, but because responsible implementation requires understanding. A software system is more than code — it contains business rules, old decisions, deployment assumptions, third-party services, data flows, user expectations, and parts that may work only because nobody has touched them recently. The report makes those things visible before new work begins.
The System Report is not paperwork. It is the first engineering deliverable.
PlainWhat you actually want, in your words.
TechnicalThe concrete change request, normalized to scope and outcome.
PlainWhat we can see, who we can ask, what's in and out of bounds.
TechnicalRepo access, environment access, deployment info, business-rule contact.
PlainWhat's there today and how the parts fit.
TechnicalRepositories, services, jobs, integrations, data flow, runtime topology.
PlainThe decisions buried in the code that nobody wrote down.
TechnicalImplicit invariants, edge cases, state transitions, ownership ambiguity.
PlainWhere a small change has surprising effects.
TechnicalShared services, hidden side effects, fragile boundaries, missing tests.
PlainThe order in which things should land so nothing breaks.
TechnicalSequencing, isolation boundaries, what to refactor first, what to leave.
PlainHonest range with the assumptions written down.
TechnicalPhase ranges with named risks and what would move them.
PlainThe questions we need answered before code starts.
TechnicalRequired product decisions, business-rule confirmations, scope cuts.
Even if we do not continue into implementation, the report remains useful. It gives the company a clearer map of its own system.
How complexity becomes manageable
We are not architecture religious. We use structure where it reduces confusion, risk, or maintenance cost — and avoid it where it only adds noise. Click a layer to see what lives there, and what doesn't.
End to end
The path is the same on every project. The shape and weight of each step is set by what the report finds — not by a fixed package.
Clarify scope, access, and whether the work can be understood responsibly.
Study the system, surface the rules, name the risks.
Compose the right package from what the report revealed.
Build inside the system, with shared language and clear seams.
Ship to production with rollback paths, observability, and small surface area.
Watch it run on real data, real users, real schedules. Confirm the report's assumptions.
What we do
The System Report determines the right package. Sometimes the system is clear enough for direct implementation. Sometimes the first phase is cleanup, testing, or isolation. Sometimes the safest path is a smaller version first.
The foundation. The report itself, scoped to one area, change, or integration path.
Bounded backend work, landed responsibly inside the existing system.
Vendor boundaries, scheduling, retries, lifecycle tracking, admin visibility. Not just an API call.
Untangle responsibilities, separate concerns, prepare the system for new work.
Integration tests through real layers. Realistic states, not artificial setups.
Make runtime behavior visible. Status, exceptions, batches, content, support flows.
Linux, nginx, systemd, webhooks, backups, health checks. Simple and reliable.
The structure that lets AI-assisted development stay coherent, bounded, and safe.
Proven in real systems
Patterns we use because we have shipped them in production, not because they look good in a deck.
Controller, Facade, Business Service, Repository, Domain. Each has one job. When something is wrong, you know where to look.
The UI reads page state, performs an allowed action, reads the new state. The frontend never invents behavior outside the contract.
Background work tracks start, end, outcome, and idempotency. If a batch ran, the system knows what happened.
Generate realistic state by simulating users for weeks of activity, snapshot the database, then run tests through the same Facade and BusinessServices code production uses. Catches errors that only appear when business rules interact.
Architecture docs, working notes, context-re-entry rules. AI does not maintain context on its own; we build it for the model.
What we have built
Projects that show the working method — backend depth, domain modeling, and AI-collaboration discipline.
Production stock analysis platform built end to end.
“Answers what this company is as a system — not whether the stock will go up.”
Gamified learning system, proven by simulating weeks of student activity through real backend code.
“Coupling between business rules can't be caught by testing methods in isolation — so we run the real system on simulated time.”
AI-assisted development as disciplined context management.
“AI does not maintain context on its own. Context must be built for it.”
What we optimize for
Who we are
Smallbox is a small software studio led by Jack G., a senior C#/.NET backend developer with 15+ years of experience in production systems. When useful, Smallbox works with a small number of trusted collaborators — but the process stays focused: one main project, clear ownership, and deep system understanding.
Get in touch
Send a short description of your system, what you want to change, and what context is available. Useful details: repositories, deployment setup, integrations, database, admin tools, business rules, and the person who can answer product questions.
You'll get a reply on whether a System Report makes sense for your case, what access would be useful, and the likely starting scope.
The better the access and collaboration, the more precise the report.
hello.smallbox@proton.me