What a person costs

What they do

Works through well-defined tickets under a senior's review: screens, forms, CRUD, content work, bug fixes and the long tail of small changes that a product accumulates.

What it changes

Takes the volume work off your expensive people. A senior who spends their week on form validation is a senior you are paying four times over for the wrong thing.

When your project needs one

When the shape of the product is settled and there is simply a lot of it to build. Not the first hire on a green field, where every decision is still load-bearing.

What they do

Takes a feature from a description to something in production: data model, API, interface, tests and the edge cases nobody wrote down.

What it changes

The steady rate of delivery. A middle developer needs the goal explained, not the solution, so your week is not spent breaking work into pieces small enough to hand over.

When your project needs one

Almost always. This is the role most projects are actually short of, and the one that keeps a roadmap moving once the architecture is set.

What they do

Makes the decisions that are expensive to reverse: data model, service boundaries, auth, multi-tenancy, performance, and how the whole thing is deployed and observed.

What it changes

Avoided rework. The costly failures in software are almost never a slow feature; they are a structural choice made early by somebody who had not seen it go wrong before.

When your project needs one

At the start of anything new, when scale or compliance is in play, or when you can feel delivery slowing down and nobody can say precisely why.

What they do

Runs the plan and the communication: scope, sequencing, dependencies, risks, written updates, and being the person who answers when you ask where something is.

What it changes

Your own time back. Without one, coordination lands on whoever is most senior on your side, which is usually the person whose hours are worth the most.

When your project needs one

Once more than two people are building, or when the work touches your own team, a third party or a deadline that somebody outside the project cares about.

What they do

Writes and runs the test plan, checks releases across browsers and devices, hunts the paths users take that nobody designed for, and keeps a regression suite honest.

What it changes

Bugs found before your customers find them. The same defect costs a fraction to fix in a test run than in a support ticket, and far less again than in a refund.

When your project needs one

When the product handles money, personal data or anything regulated, or when releases have started to feel risky enough that people delay them.

What they do

Turns a requirement into flows, wireframes and an interface: what the screens are, what happens on each one, and what the whole thing looks like as a coherent product.

What it changes

Fewer things built twice. Deciding a flow in a design file costs hours; discovering it was wrong after it is built costs weeks, and usually costs the goodwill too.

When your project needs one

When the product is user-facing and the interface is part of why anyone would choose it. Less so for an internal tool with a captive audience.