Outsourcing React development: what you actually hand over
Outsourced React fails when you hand over a list of screens and works when you hand over a module with a public API. Here is where to draw the boundary.
Contents
- The short answer
- Ten weeks in, the burndown looks perfect
- React has no opinion about where state lives
- What owning a module actually means
- A split that works, and the same project split badly
- Three ways to outsource React, and how each one fails
- What to check before you sign
- The question that predicts the outcome
- Frequently asked questions
- Is outsourcing React cheaper than hiring in house?
- How small can an outsourced React module be?
- Should the external team work in our repository or their own?
The short answer
Outsourcing React works when you hand over ownership of a bounded piece of the codebase, not a list of screens. Teams that outsource features buy velocity for one quarter and a maintenance bill for the next four. Teams that outsource a module get something their own engineers can still change a year later.
Cost is the second reason to do this. Parallelism is the first: two teams can only move at once if the seam between them is real.
Ten weeks in, the burndown looks perfect
Picture where your project is at week ten. The external squad has shipped every screen on the plan. Demos go well. Then one of your own engineers picks up what should be a small request: add a column to the results table, and keep the sort order when the user comes back to the page.
She opens the table and finds the sort state living in four places.
- The sort key is in the URL query string, because the share-a-link story needed it there.
- It is also in a context provider two levels up, because a sibling toolbar needed to read it.
- A third copy sits in a useState inside the table, because that was the fastest way to make the arrow icon flip.
- And there is a localStorage key, written by a component nobody has opened since sprint three, that quietly wins on page load.
Nobody did this wrong on purpose. Four people solved the same problem in four different sprints, and none of them was going to be there in month six to notice. That is the real cost of outsourcing by feature list, and it does not appear on any invoice.
React has no opinion about where state lives
This is usually described as flexibility, and it is. It is also why two teams sharing one React codebase drift apart faster than two teams sharing a framework with strong conventions. React will not stop you putting the same value in a context, a URL and a hook. Your conventions have to, and conventions only hold where somebody owns the result.
So the useful question at the start of an engagement is not what will they build. It is what will they own, and how would we know if they stopped owning it.
What owning a module actually means
A module a team can own has five properties. Fewer than five and you have a feature list with extra steps.
- It has a public API. Consumers import from the package root and never reach inside it.
- It has its own tests, and those tests fail the build, not a separate pipeline nobody watches.
- It is versioned. A consumer can stay on the old version for a sprint without asking permission.
- One team merges to it. Review can be shared; the merge button is not.
- It has a written contract for its props or its endpoints, and changing that contract is a visible event.
A split that works, and the same project split badly
Take a reporting product: a dashboard, a filter bar, a chart library, an export flow, and an admin area behind it.
The bad split is by screen. You give the external team the dashboard and the reports page and keep the admin area. Both halves need filters, both need the chart wrapper, both need the date-range logic. Two implementations of each appear within a month, and neither team can change one without breaking a page it does not own.
The good split is by layer. The external team owns the chart and filter packages: the primitives, their props, their tests, their Storybook entries. Your team owns the pages that compose them. When a page needs a new filter type, that is a pull request against a package with an API, not an archaeology exercise. The seam is visible, so drift is visible.
The second split is also the one that survives the engagement ending. You keep a versioned package with tests. In the first, you keep some pages and a question mark.
Three ways to outsource React, and how each one fails
These are not tiers of quality. They are different trades, and each has a failure mode you should plan for rather than be surprised by.
| Model | What you hand over | Who owns the tests | How it fails | Fits when |
|---|---|---|---|---|
| Staff augmentation | People, into your repo and your standups | You do | Your senior engineers become full-time reviewers and their own work stops | You have strong conventions and review capacity, and need hands |
| Project delivery | A scope and a deadline | Nobody, in practice | Everything not written in the scope gets negotiated at the worst moment, and the code is optimised for handover day | The scope is genuinely fixed and short lived, like a migration |
| Owned module | A package with a public API | The external team, running in your CI | Slower to start, because the boundary has to be agreed before anyone writes code | The work outlives the contract, which is most of the time |
What to check before you sign
None of this needs a technical interview. These are questions about how the engagement is shaped, and the answers are usually revealing.
- Ask where the boundary is, and ask them to name it as a package or a service. If the answer is a list of pages, you are buying the first split above.
- Ask whose CI the tests run in. If the answer is theirs, you find out about failures on handover day.
- Ask what happens to the code review load on your side. A team that has not thought about this has not done it before.
- Ask for the contract on the seam: prop types, an OpenAPI file, a schema. Something a machine can check.
- Ask how a change to that contract gets announced. If the answer is a message in a channel, it will be missed.
The question that predicts the outcome
If you ask one thing before signing, ask this: when this engagement ends, what do we have that a new engineer can pick up without talking to anyone who left?
A team that has done this well answers immediately, with a noun. A package. A service. A documented contract. A team that has not will answer with a process, or with reassurance. The difference in that one answer is worth more than the difference between any two rate cards.
If you want the same idea applied to hiring rather than contracting, our React hiring page covers what to test in an interview, and the IT outsourcing overview goes through the engagement models above in more detail.
Frequently asked questions
Is outsourcing React cheaper than hiring in house?
Per hour, usually. Per outcome, only if the boundary is right. An engagement that leaves behind code your team cannot change has moved cost into next year rather than removed it. Compare total cost over the life of the code, not the rate card.
How small can an outsourced React module be?
Small enough to have one public API and one owner. A design-system package, a charting layer, an editor, a checkout flow. If you cannot describe what it does in one sentence without using the word and, it is probably two modules.
Should the external team work in our repository or their own?
Yours, in almost every case, with their tests in your CI. A separate repository hides drift until integration, which is the point at which it is most expensive to fix. The exception is a genuinely standalone package you intend to publish.
We already outsourced by feature and have the mess described above. Now what?
Do not rewrite. Pick the one primitive that is duplicated most often, usually a table, a form field or a date picker, and give it a real API and tests. Migrate call sites opportunistically as pages get touched. The duplication stops growing before it starts shrinking, and that is the win worth having.
How do we keep code review from swallowing our senior engineers?
Review the contract, not every line. If the external team owns a package with a public API and its own tests, your reviewers look at API changes and the tests that cover them. Reviewing every internal commit of a module you do not own is the staff-augmentation failure mode wearing a different name.
Articles from the Code Elevator team, the engineers and specialists who vet developers, ship client work, and write up what they learn along the way.
More from CodeFour clients, on camera.
Why he brought his development work to Code Elevator.
One useful piece a month, no more than that.
What we learned building and hiring for this work. No newsletter filler.
Reading about it is step one. Building it is step two.
Hire a pre-vetted engineer who has shipped work like this before. Matched within 48 hours.
We reply within an hour during our working day in India and the UAE.