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 report is not a quick review. It is a structured investigation — usually several days to a few weeks working through the codebase, the business rules, the runtime, and the people who built and run the system. By the time implementation starts, both sides already share the same map of the system, and a large part of the uncertainty has been removed before any code is written.
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.
It names what already works, where the system is fragile, where business rules are implicit, where responsibility is unclear, and where a requested change would create risk. The goal is not only that Smallbox understands the system — it is that both sides can discuss the system with the same map before implementation begins.
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.
What it costs
Every serious project starts with a System Report. For very small tasks we can begin with a lighter intake — but for serious backend changes, the report comes first.
from €1,200
A bounded report focused on one system area, one requested change, one integration path, or one unclear part of the backend. A focused investigation through the code, the business rules, and the runtime. The report often removes a large part of the uncertainty before implementation begins.
€4,000–€15,000
A bounded implementation phase — a feature, cleanup and isolation, admin tools, or testing scaffolding. Range depends on scope and the condition of the surrounding system.
€8,000–€20,000+
Vendor boundaries, batch pipelines, lifecycle tracking, admin visibility, deployment and runtime setup. The real work is not just calling an API — it is making the data flow observable, recoverable, testable, and safe to operate.
by agreement
Continued work after a system is delivered — tuning, additions, operational support — is scoped together once the steady-state need is clear.
Larger systems, multiple repositories, unclear business rules, or deep cleanup may need a broader discovery phase before implementation can be priced.
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 an intentionally small backend studio with 15+ years of production experience in C#/.NET systems — backend architecture, data pipelines, integrations, testing, and deployment.
The studio works with focused ownership rather than large teams: one main system at a time, clear responsibility, low communication overhead, and deep understanding before implementation. When useful, Smallbox can collaborate with trusted specialists, but the core work stays close to the system.
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