An Agency Working With Your In‑House Developers: What to Agree First

• If you'd have to write their tickets, you're buying capacity. If you can describe the result and how you'll accept it, you're buying an outcome. This list is for the second.

• Their code goes through your review and merge rules, with the least access the work needs.

• Progress is working software in your environment, not a status report.

• Get one accountable name, the team by name, and a written answer for what happens when someone leaves.

• The cost no proposal prices is your own team's time. Ask each firm what it needs from you, in writing, and compare the answers side by side.

Your engineers are booked through next quarter, and the release a big customer asked for isn't on anyone's plan. It might be a mobile app, an integration or a new part of the product. You can't hire fast enough, and you've seen both versions of outside help go wrong.

One version sends contractors who need tickets written, questions answered and code reviewed, so the management lands on the people you were trying to protect. The other disappears for three months and hands back something that works in a demo and that nobody on your team can explain.

There's a third arrangement: an agency working with in-house developers that owns a bounded release inside your codebase, under your rules, and hands back something your team can run. It doesn't happen by accident. It comes from what you agree before anyone writes a line, and from comparing firms on those terms rather than on the pitch.

Search for this kind of help and most of what ranks is capacity under another name: team extension, dedicated developers, staff augmentation. In those models your engineering lead sets the priorities and approves what ships. That works when you have a lead with spare time. You don't, which is why you're looking.

The test is simple. If you'd have to write their tickets, you're buying capacity. If you can describe the result, its boundary and how you'll accept it, and they can take it from there, you're buying an outcome. Everything below assumes the second.

Write the outcome so a customer would recognise it, then attach the acceptance: what has to work, for which roles and devices, and the bars that aren't features, such as performance, accessibility and a security review. Put the exclusions in writing too. An outside team that knows what it isn't building is far less likely to wander into your roadmap.

These are the terms that decide whether the arrangement saves your team time or quietly costs it. Get each one in writing, from every firm you're considering.

1. Who reviews, and who merges

Their code should pass the same gate as your team's. If your code is on GitHub, GitHub's protected branch rules can require approving reviews before anyone merges, require approval from the code owners of the files a change touches, and require status checks to pass. The outside team works through those rules, not around them.

Then agree the part that actually costs you, which is review load. Ask how large their pull requests usually are, whether their own lead reviews a change before yours sees it, and how much reviewing they expect from your people. A firm that sends large, unreviewed changes has moved its quality control onto your calendar.

2. Environments and access

Give the access the work needs and nothing more. GitHub's repository role guidance makes the line concrete: write access is recommended for contributors who actively push to a project, while admin is for people who need full access, including sensitive and destructive actions. A team building one release rarely needs admin.

Agree where their work runs before it reaches yours, who can release to production (usually your people), whether production data ever needs to leave production (it rarely should) and how access comes off when the work ends. Write the offboarding step on day one, while everyone's still friendly.

3. How progress is shown

Status reports describe activity. Ask for working software in an environment you control, on a regular rhythm, demonstrated against the acceptance you agreed. The principles behind the Agile Manifesto put it plainly: working software is the primary measure of progress. That holds for an outside team at least as much as your own.

The question that separates firms is when you'll first see their work running in your environment, built through your pipeline. A firm that can't answer is planning to show you slides first.

4. The named lead, and what happens if people change

Get one name: the person accountable for the release, who you call when something's wrong and who can make a decision without escalating. Ask who else is on the team, by name, and how much of their time is on your work.

Then ask what happens when someone leaves. People move on, and pretending they won't is how a team ends up rotating without anyone telling you. A good answer names a notice period, an overlap with the replacement and who absorbs the time it takes a new person to learn your codebase. It shouldn't be your team.

Rotation is a risk wherever the team sits. We looked at the location question separately in offshore, local or hybrid. This one is about who stays accountable.

5. How knowledge comes back

Agree that documentation is part of done, not a deliverable for the last week. Each merged change should leave enough behind for your engineers to change it next: why it's built that way, how to run it, what it depends on. Decisions that affect the rest of the product get written down when they're made.

Plan the last stretch so your engineers work in the code before the outside team steps back, and treat the handback as something your team demonstrates rather than a folder that arrives. The software handover checklist covers how to test that properly.

6. Changes to scope, and who looks after it after launch

The product will move while they're building. Agree how a change gets raised, costed and approved, and who on your side can approve it. A fixed price for a defined release gives the outside team a reason to protect the boundary. An open-ended hourly arrangement turns every new idea into more capacity for you to manage.

Then decide who carries the new surface once it's live: who gets the alert, how long the outside team keeps fixing defects and the date it becomes yours. Your team shouldn't discover it owns a production service on the morning something breaks.

Send each firm the same questions and ask for written answers by a set date. Then read the answers against a table like this one. Scroll sideways on a phone.

You're not looking for the firm with the most impressive answers. You're looking for the one whose answers you could hold it to.

Of everything on that list, one row decides whether this works: what it asks of your team. A proposal prices the outside team's work. It never prices your reviewers' afternoons, your lead's decisions or the drag of answering questions in a shared channel all day. That's the cost you were trying to avoid, and it's the one that creeps back.

So ask each firm to state what it needs from you, in writing, then check it against reality in the first few weeks. If the two drift apart, raise it then. It's much harder to fix at the end, when the same overhead has been absorbed for months and nobody remembers agreeing to it.

This is close to how we work with in-house teams on B2B products. The code lands in your repository, under your conventions and your review, and who owns which part of the work is agreed before the first pull request. The detail is on our web app development for B2B SaaS page.

Before your next call with either firm, copy the first column of that table into an email and send it to both. How each one answers, how specific it is, how quickly it replies and whether it asks you anything back will tell you more about working together than either pitch will.