For founders about to hire a developer

You’re about to hire a developer. What will they inherit?

The ad is written, or the offer is already out. Some Monday soon, a developer clones your repository for the first time and reads what is actually there. That morning decides the shape of their first quarter: a base to build on, or three months of building one — alone, under pressure to ship, while the product they were hired for waits.

The shape of the moment

This page is for the specific situation where one of these is true:

• You are not a developer, and this is hire number one. Everything that exists so far came out of no-code tools, AI sessions, or an agency deliverable. The hire is the moment the product is supposed to get an engineering home — and what they walk into on day one is whatever those tools left behind.
• You are a developer yourself, and this is the hire that hands operations off — so you can get back to the product. What you hand over is whatever you managed to build while also running the company, and you already know which parts were built in a hurry.
• An agency or a freelancer built what exists, and the engagement ended. The hire is how the company takes ownership of its own system — by giving its shape to someone who was not there when it was decided.

If what you hold today is an AI-built prototype, that situation has its own page — it walks the same decision from the prototype’s side.

The most expensive months you will ever buy

Look at what a first developer’s opening months actually contain. Before the product gets a single new feature, somebody has to wire sign-in and accounts, an admin that can answer a support question, email that reliably arrives, a place where failures become visible, and a deployment that can be repeated without fear. None of that is your product. All of it is necessary. So the months you are paying the most for — a senior rate, full attention, the whole company watching the new hire — go to work that was never the reason you hired.

And the money is the smaller half of the cost. Those foundation pieces get built by one person, working alone, under visible pressure to ship something — and they are not revisited, because revisiting plumbing is exactly what a young company cannot justify. Decisions made in a hurry in week three — where the rules live, what the admin can see, how a failure surfaces — quietly become the permanent floor under every feature that follows. (Where business rules hide shows what that floor looks like a few years later.)

What a serious place to start looks like

Now run the same Monday differently. The developer clones the repository and finds accounts and roles working, an operable admin, email with a visible history, failures landing as records someone can search, and a deployment that repeats — connected to each other as one system, not five services in five tabs.

And one real workflow already wired through all of it, end to end: a user signs up, takes the product’s first real action, the result shows in the admin, an email goes out, and a failure anywhere in that chain lands somewhere findable. That worked example is the house style. The developer’s first feature follows a pattern instead of inventing conventions — and every convention they do not have to invent is one more decision that is not made alone, in a hurry, under pressure to ship.

That is what the foundation changes about the hire itself. In month one they ship product, because the plumbing argument never happens. In month twelve they are still shipping product, because the structure absorbed the speed instead of accumulating it.

The hire becomes more valuable, not less

The honest objection first: if Smallbox builds the foundation, are you paying twice for the same work? No — you are buying the months back. The foundation is the floor under your developer, not their replacement: what it removes is the generic layer every product needs anyway, so what remains is the product work you actually hired them for. It works whether they start before the build, during it, or after.

A good developer can build on a foundation. They should not have to invent one alone, under delivery pressure. That distinction is the whole offer: the foundation does not doubt your hire’s ability to build these pieces — it removes the quarter in which they would have to, while the product waits.

There is a use for it before day one, too. The scoping that precedes the build produces a written plan concrete enough to hand a candidate with the offer letter: the structure they would inherit, the first workflow they would own, what is explicitly out of scope. It shows a serious candidate what they would be walking into. Their reaction shows you at least as much.

What is decided before the build starts

The first step is deliberately small, and it is free: a scoping conversation that turns “what should my developer inherit” into a written plan. In an about-to-hire engagement it answers:

• What the developer inherits on day one — which foundation modules the product actually needs, and which are deferred.
• The first workflow you want them to own — named and bounded, end to end: sign-up to action to admin to email to failure record.
• Timing — whether the foundation is built before they start, or alongside their onboarding.
• Where it deploys and who owns the accounts — hosting, domain, keys: the company’s, from the start.
• What is explicitly out of scope, with the risks named in writing before any code — and before any contract.

Those answers become the scope of the fixed €10,000 Prototype to Product + First Workflow package — agreed in writing before any work is billed.

The economics follow from reuse. You are not paying for generic plumbing invented once for your project — you are getting a version of a foundation already built, reused, and operated across live systems, adapted to your product instead of rediscovered on your developer’s clock.

The foundation it describes is not a proposal. It is the working shape of two live products — CompanyGraph and the site you are reading — operated, day to day, from the admin you see here:

When the System Report is the right first step instead

One version of this situation needs a different door. If you are hiring because an existing system has no owner — production traffic, real users, integrations nobody can fully explain — then the developer is not walking into greenfield. They are inheriting a live system with stakes, and the honest first step is the System Report: a read-only, fixed-scope investigation that maps what the system actually does and what is safe to change. (What a System Report contains, written out.) Handing that report to the new developer on day one turns their first weeks from archaeology into orientation. You do not have to make the foundation-or-report call yourself — it is short, and the first conversation makes it honestly.

When this is the wrong fit

If you are hiring for feature work on a backend that already has structure — identity, admin, deployment in place — you do not need this page; brief your developer and build. If what you need is a brochure site, it does not need a foundation. And if you are hiring a team senior enough to own the platform’s shape end to end, let them — a foundation chosen for them would be a decision that was theirs to make.