The arrangement works or fails on one decision: whether the new product needs your engineers on the critical path. If it does, you have added a second project to a team that could not start the first one. If it does not, you have genuinely created capacity.
Everything below is in service of that one thing. Separate repository, separate deployment, an interface agreed in writing, and a review rhythm measured in hours rather than weeks.
Key takeaways
- Separation is the whole design: Own repository, own deploys, own on-call for the new product.
- The interface contract comes before code: What it may read, what it may write, what happens when either side changes.
- Budget one day of your engineers, not one day a week: If more is needed, the scoping was wrong.
- Plan the handover at the start: It is the expected ending, not an exception.
Step 1: scope it without your team
Most discovery phases run on your senior engineers' calendars, which spends exactly the resource you are short of. The alternative is for the external team to read the system rather than be walked through it: the schema, the existing integrations, the API surface, the deployment setup, recent incidents.
What that requires from you is read access and a single day of questions. Not a standing weekly meeting, not a workshop series. If an outside team needs more than that before they can propose scope, they are asking you to fund their learning with your bottleneck.
We go through this in more detail in how to scope an R&D project so your team stays out of it.
Step 2: give the new product its own surface
Own repository, own deployment pipeline, own environments, own on-call rotation. This is not a preference, it is the mechanism that protects your team.
If the new product deploys through your pipeline, your team owns its releases. If it runs inside your infrastructure, your team gets paged when it breaks. If it lives in your repository, your team reviews its code. Each of those is a small, reasonable-sounding concession that hands back the capacity you were buying.
The new product reaches your existing system through one defined route, and nothing else.
Step 3: write the interface contract before any code
This is the document that decides whether the two systems can evolve independently. It should state:
- What the new product may read, and from where. A read-only replica or a documented API, not direct access to production tables.
- What it may write, if anything, and what validates those writes.
- What the new product must never do. Usually: no schema changes, no writes to core tables, no long-running queries against production.
- What happens when your side changes. How much notice, and who tells whom.
- What happens when their side is down. Whether your system notices, and whether it should.
Agreeing this in writing takes a few hours and prevents most of what goes wrong later. The version that fails is the one where the boundary is understood but never written, and both teams turn out to have understood it differently.
Step 4: review working software, not pull requests
Every two weeks, something you can open and use. Not a percentage, not a status colour, not a code review.
This is the exchange that keeps the cost low. You are trading detailed oversight for regular evidence, and it only works if the evidence is real: a build, a link, a test account. If a fortnight passes with nothing usable, that is the signal to ask why, and it is a much better signal than any report.
Your engineers do not attend these. The point is that they do not have to.
Step 5: decide the ending at the beginning
Handover is a planned piece of work with a date, not a hope. Decide at the start which of three endings you are aiming at: your team takes it over, the external team keeps running it, or it merges into the existing system later.
Each implies different choices during the build. A product your team will inherit should be written in your stack, with your conventions, documented for the engineer who takes it. One that stays external can make different choices. Deciding this late is how teams end up inheriting something they cannot maintain. We cover the detail in who owns the new product after it ships.
What this costs your team, realistically
One day at the start for questions. A named person who can decide interface questions, reachable within a day, for a few hours a month. A fortnightly half hour to look at what has been built. Read access to the relevant systems.
That is the whole commitment. If it is running higher than that after the first month, something in the arrangement is wrong, and it is worth naming early rather than absorbing.
Ali Boran Gazel