The usual version goes like this. You built your product with no-code tools or a GPT wrapper. It now has paying customers. You need a real developer, and a senior one costs about twice what a junior does. So you hire a junior. The maths looks obvious.

Six months later the product is slower, something customers relied on has quietly stopped working, and you can’t tell whether the developer is bad or you are bad at managing them. Nobody can tell you, because nobody in the building can read the work.

I’ll say it plainly: the junior was rarely the problem. Nobody senior was attached. Every junior hire I’ve seen work had a senior person nearby. Every one that failed didn’t.

The real number

Take an illustrative junior salary of €32,000. Add employer taxes and equipment and you’re near €40,000 a year. That’s the cheap part.

The expensive part is what happens when nobody checks the work. The junior ships something that works in the demo and breaks at the fortieth customer. Or it works, but customer data is exposed in a way nobody notices until a customer does. Then comes the rewrite, which usually costs another three to four months of salary plus the customers you lost while it was broken. A junior is cheap on the payslip and expensive everywhere else, unless someone senior is attached.

Before you hire, run these four checks.

Check 1: Who reads their work before your customers do?

Look at: the path from “developer finishes something” to “customers see it.”

A bad answer: “I’ll have a look.” You aren’t an engineer, so you can’t judge it. Or: “They’ll figure it out.” Juniors do figure things out, but they also figure out wrong things with great confidence.

What to do: name one senior person who reads every change before it goes live. A name, not a role. If you can’t name them, you don’t have a review step. You have hope.

Check 2: What exactly is the first job?

Look at: the first assignment.

A bad answer: “Take over the product.” That’s a senior’s job, handed to someone who has never seen a product break at 2am.

What to do: give them a bounded piece of work with an obvious finish line. One feature, one fix, two weeks. Something where you can say “done” or “not done” without reading code. Widen it only after the first one lands cleanly.

Check 3: Could a stranger understand how your product runs?

Look at: whether the basics are written down. Where does customer data live? What runs automatically? What costs money every time it runs?

A bad answer: it’s in one person’s head, the logins are in a chat thread, and the only documentation is “ask Sam.” A junior who inherits a mystery makes expensive guesses. Your bill goes up, or something gets deleted that you needed.

What to do: before they start, get a one-page map written. If you built it yourself, it takes an afternoon. If you can’t write it, that tells you the product needs an engineer’s attention before it needs a new hire.

Check 4: Who gets the call when it breaks?

Look at: what happens when the product goes down on a Friday evening.

A bad answer: the junior, alone. They’ll panic, change five things at once, and make the outage harder to diagnose.

What to do: make the senior person the escalation for the first three months. The junior still takes the first look, which is how they learn, but they have someone to ring.

The decision rule

If you only keep one thing from this post, keep this:

No named senior with at least four hours a week for the first 90 days, no junior hire.

Four hours a week over 13 weeks is 52 hours. That’s the whole price of making a €40,000 hire safe. If you can’t find those 52 hours, don’t hire a junior. Hire a senior, or hire someone to do the work for you until you can.

What the ones that work have in common

They aren’t smarter juniors. They have three things around them: someone senior who reads their work, a first task small enough to finish, and a product that’s written down well enough to learn from. Take away any one of those and the same person fails.

Most founders read a failed junior hire as a hiring mistake. It’s usually a setup mistake. You can fix the setup by attaching a senior engineer yourself, or by having someone else do it as part of the hire.

technical hiring — 15–20% of first-year salary, on successful hire only. engineers screening engineers; or a backed junior at 12–15% with three months of senior mentoring attached.

It starts with a free product teardown: two hours on what you are building, what already exists, and what is actually blocking launch. You leave with a written plan and a realistic number, whether or not you work with us. Book a teardown · What it costs