Work with me directly

I take ownership of your system, so the next change is easier than the last.

I’m the developer behind Smallbox Labs. I work with small companies that have a real product and no clear technical owner. The system runs, but every change has become slower, riskier, and harder to place than it used to be.

What I offer is ownership. I learn your business, find where the important rules actually live, and reshape the system so the next valuable change costs less and breaks less than the one before it. Not by shipping more code — by giving change somewhere to go.

This is for you if…

• Your product works and has real users, but each change takes longer and feels riskier than the one before it.
• The person who built it has moved on — or it is you, and you are now too busy running the company to also hold the system in your head.
• You have been shipping with freelancers or AI tools, and code keeps arriving, but nobody owns the whole.
• You need one serious developer before you need a department — or you are about to make a first hire and want them to inherit a system they can build on, not untangle.

If that is the shape of it: I become the developer who owns your system. The goal is not to make you dependent on me — it is to make the system easier for the next serious developer to continue.

What ownership actually means

Ownership means holding the business and the system together closely enough, and long enough, to make better technical decisions than someone touching it for the first time. In practice that is a handful of concrete jobs:

• Understanding the business — what the system is meant to protect, repeat, and never get wrong, so the structure follows the work instead of fighting it.
• Knowing where every rule lives — one clear home per decision, so a change is made in one place rather than hunted across the frontend, the admin, and a database script. Much of the early work is finding where the business rules are actually hiding.
• Reducing hidden coupling — so a change in one corner stops surprising you somewhere unrelated.
• Making failures visible — errors that surface as records someone can read, not problems discovered a week later from a customer email.
• Leaving decisions written down — so the reasoning behind the system is in the system, not only in the head of whoever made the call.

The honest part: understanding your business takes time

I will not pretend I can understand your business in a week. The first weeks are mostly me learning what your system is supposed to do — reading the code, watching it run, and asking the questions whose answers were never written down. Some of those answers do not exist yet, and finding that out is part of the work.

What I can do from the first commit is keep the code grounded: leave every part I touch more legible than I found it, anchored to how the system actually behaves rather than to how it was once described. So the understanding I am building becomes visible in the system as I go, instead of staying trapped in my head. That is the difference between someone learning your system and someone quietly becoming the only person who knows it.

What I bring, and what you bring

One boundary, stated plainly, because it keeps the work serious rather than magical: I take ownership of the system. I cannot take ownership of the product — what it is for, who it serves, which tradeoffs are worth making. A system is a model of a business, and a model needs a business to be a model of.

So I need someone on your side who can answer what the product is trying to do: the rules, the priorities, the users, the calls only the business can make. Where those answers are unclear I can help — surfacing the rules that are implicit or not yet agreed, writing them down, and turning them into structure the system can hold. What I cannot do is decide, for you, what the product should become. I bring technical ownership; product direction has to be owned on your side. That is the setup where this works: your direction and my system, meeting in the open.

Why one owner, and why it is worth a retainer

You are not paying for tickets closed or lines of code shipped. A system can produce new problems faster than it produces stable capability — and when it does, fixing them looks like productivity while the real cost, the cost of making any change at all, keeps climbing. Everyone is busy; the product moves slower every quarter.

The work I am paid for is the opposite of that loop. Instead of fixing a bug and moving on, the question is why this kind of bug became possible — which missing boundary, which rule with no clear home, which failure that never surfaced — and then reshaping that part so the whole class becomes less likely. One person who can hold the business, the structure, and the history together can bend the cost of change downward in a way that more hands on an unclear system cannot. Coordination without ownership is its own expense.

Ownership without dependency

The fair worry about one owner is that you become dependent on them. My job is the reverse: to raise the number of people who could safely take the system over, not to become the only one who can.

That is a property you can hold me to, because it is built from concrete things — one clear home per rule, tests anchored to real behaviour rather than to themselves, failures that surface on their own, and decisions recorded where the next developer will find them. Done well, the system gets easier for someone else to continue over time, including after me. The same values I work by, each paired with the place in a live system where you can check it, are written out in full.

How we would start

There are two honest starting points, and which one fits depends on your actual problem. If you are not yet sure which, uncertainty and capacity are different problems with different first moves.

• If the uncertainty is high — a system with real stakes that nobody fully holds — we start read-only, with a System Report that maps what is actually there and what is safe to change, before anything moves. It is also the honest ground for a refactor-or-rewrite decision — made on evidence, not instinct.
• If the system is understood and the need is capacity — the shape is clear, there is just too much to do — we start with one bounded piece of work, so you see how I work before anything ongoing.

Either way, the ongoing shape is the same: a monthly ownership retainer. It is ownership capacity, not unlimited hours, and it does not come with guarantees over hidden history that no honest engineer can make. What it comes with is a disciplined process: visible assumptions, evidence-backed decisions, and bounded steps you can stop between.

What you can check before you talk to me

Smallbox is built around one standard — quality of change: not elegant code, but whether the next important change can happen with less guessing, less hidden coupling, and better evidence than the one before it. CompanyGraph and this site run on that standard, and you can watch it — the live status, the architecture, how change is tested, and two cases built end to end. The values behind all of it name, for each principle, the exact surface where you can check it — including where it currently falls short. Claims about how I work sit next to where they can be verified, on purpose.

And if you want the conventional version — the years, the stack, the history — my CV is one click.

The thinking underneath this

A few short pieces go deeper than this page does, each on one idea the offer rests on:

• Good code is a place for change — what “better” means, if not elegance.
• False efficiency in software — why a busy team can ship a slowing product.
• Ownership without dependency — how one owner lowers your dependence instead of becoming it.
• One senior before two juniors — why structure has to come before more hands.
• Why are there so many bugs — bugs as symptoms of where the structure is missing.

Questions I am usually asked

What does €6,000 / month actually buy? Defined senior ownership capacity — planning, implementation, maintenance, a written progress-and-risk note each month, and the tests and documentation that keep the system continuable. Not unlimited hours, and not counted in tickets closed. What you are paying for is the cost of change staying low.

Are we becoming dependent on one person? A fair worry, and the answer is built into how I work — one clear home per rule, tests anchored to real behaviour, failures that surface on their own, decisions written down. The job is to raise the number of people who could safely take the system over, not to become the only one who can.

What happens if you leave, or we stop? You are left with a system that is easier to continue than the one I started with — that is the deliverable, not a side effect. The same properties that prevent dependency are what make a clean handover: nothing is locked to me or runs only from my machine, the reasoning is written down where the next developer will look, and at any point you can hand the system to another senior developer. The honest measure of the work is how little they would need to ask me.

Do you guarantee a timeline or an outcome? Not over a system carrying hidden history — no honest engineer can. What I hold to instead is the process: visible assumptions, evidence-backed decisions, and bounded steps you can stop between.

Does every engagement start with a System Report? No. The report is for uncertainty — a system with real stakes that nobody fully holds. If the system is understood and the real problem is capacity, we start with one bounded piece of work instead.