The Body Shop Bargain

The answer could be plenty. An experienced contractor can investigate a failure, challenge a design, or take responsibility for a migration. A team with settled requirements and enough review capacity may simply need more people to do the work.

But if the proposal buys development hours while your team keeps every consequential decision, the capacity has a limit. Someone has to review all of it, reconcile it, and own it after the contract ends. That work belongs in the buying decision alongside the rate.

The work left with you

Suppose you’re replacing a billing integration. The new developers are assigned to write an adapter, the code connecting the systems, but their brief leaves failure handling to your existing engineer. That engineer still has to establish what happens when a payment succeeds but the confirmation never arrives. Can the system retry safely? What happens to payments already in flight if the team restores the old integration?

Those answers require knowledge of the service and agreement about acceptable failure behavior. Under this division of work, the developers can finish the connection while your engineer is still investigating its failure cases. If changes arrive faster than that person can resolve them, the review queue grows. More code is ready; the release still waits.

That distinction exists even inside a well-resourced engineering organization. In Google’s account of code review, a peer checks correctness while a code owner considers whether the change belongs in that part of the system and whether the team can maintain it. The roles can overlap. Approving the implementation still includes responsibility for the system it enters.

The company may have good reasons to keep final approval: it will carry the customer relationship if a payment goes wrong. That still leaves room to transfer the investigation. A contractor could check the provider’s retry rules and reproduce the missing-confirmation case, then bring a tested proposal for your engineer to accept or reject. That can reduce the preparation demanded of your engineer without removing their responsibility to check it.

The inference for a staffing purchase is conditional: additional authors help less when approval remains concentrated in an overloaded person. It applies to permanent hires as well as contractors. It also changes when the newcomers can share review, bring missing expertise, or learn enough to take ownership. Onboarding can be an investment in removing that dependency, provided someone has time to do it.

This is the body shop bargain: you buy more development capacity and retain whatever direction and ownership the agreement leaves with you. The trouble starts when the delivery plan counts the new capacity but omits the work required to make it useful.

What AI changes in the price

An AI-assisted staffing pitch still has to explain who does this work. In June 2025, engineer Sean Goedecke described a proof-of-concept coding agent running on GitHub’s free services. His argument concerned the accessibility of the software around the model. The example supplies no comparison between that agent and an engineering team delivering a production system.

There is evidence for a narrower benefit. Field experiments at Microsoft, Accenture and a third company, reported in 2025, found an increase in completed tasks with a code-completion assistant when the results were pooled. The individual experiments were noisy. They tested assistance for working developers, not replacement of a delivery team.

For the billing integration, the useful question is how much acceptable work the team can complete with the tools available. AI could help a contractor investigate retry behavior as well as write the adapter. If that produces evidence the reviewer can check, the saving may reach beyond writing speed. If the behavior remains unresolved, that decision still holds up the release. A contractor who can settle it may be worth more than someone who produces a larger patch.

The same scrutiny belongs on the fee. Under an hourly contract, fewer billed hours can lower the buyer’s cost; reputation and repeat business give the supplier reasons to help you finish, too. With a fixed fee, the supplier can keep the benefit of faster implementation, but also carries extra implementation effort if the agreed price and scope stay fixed.

Both arrangements can be reasonable. Compare proposals against the same accepted result, including the failure cases and the handoff. If one fee covers only writing the adapter and another covers investigating how it fails, the rate alone cannot tell you which costs you less. Your team’s retained work belongs beside either quote.

Put the responsibility in the proposal

Take a real piece of blocked work into the staffing conversation. Establish which decisions the proposed engineer can make, which need your team’s approval, and who will maintain the result. Include the reviewer in that conversation. A promise of independent delivery means little if the person expected to approve it has already been allocated elsewhere.

For the billing work, acceptance could include a demonstration, in a test environment, that retrying after a lost confirmation won’t charge the customer again. It would also need a plan for payments in flight during a rollback. Assign who prepares that evidence and who accepts it. Follow the change through review and note what your engineer still had to investigate; that’s work the staffing plan must account for.

Then consider whether the work itself can shrink. For a marketplace contemplating custom tax-handling software, a managed service might replace part of the proposed build. That choice would still require checking the provider’s coverage and deciding how to handle exceptions. Compare its fees and integration effort with owning the custom implementation. A contractor could identify the option and implement the integration; the value would include code you no longer need to own, rather than only hours added.

If the work is well understood, can be divided safely, and has an agreed way to check the result, buying more engineering capacity can be the right call. If it is waiting on a product decision, give the existing decision-maker room to make it before expanding implementation. If nobody on the team has the necessary expertise, seek someone who does and give them a defined area to own. A senior consultant still needs to show how they’ll take that responsibility off your team.

Put the expected demands on your reviewer beside the proposed development capacity. You may choose to buy extra implementation and keep every approval inside the company. Make that choice with the person whose calendar has to absorb it.