A company with four thousand engineers brings in an outside build team, and someone in the approval chain asks the obvious question: why are we paying for engineers when we have engineers. It is a fair question and it has a good answer, but the answer is almost never the one written in the request. The request usually says the internal team lacks a skill. That claim is easy to attack, sometimes untrue, and it puts the sponsor in the position of arguing that colleagues are inadequate. The real answer is about queues, focus, and the shape of the cost, and it survives scrutiny because it is arithmetic rather than opinion.
This is written for the business-unit leader who wants the work done and for the finance partner who has to approve it. It sets out why large engineering organizations still buy outside build capacity, how to write the case so it clears a finance review on the first pass, and what the comparison against the internal alternative actually looks like when it is done honestly. The worked example uses illustrative numbers so the method is visible; substitute your own and the structure holds.
The four reasons that survive scrutiny
Strip away the framing and there are four durable reasons a company with plenty of engineers buys outside build capacity. Most requests involve two of them.
The internal queue is full and the queue is not yours to reorder. This is the most common and the least often stated, because stating it sounds like a complaint about platform engineering. It is not a complaint. A shared engineering group serves the whole company and prioritizes by a process that exists precisely so no single business unit can jump it. When the answer is "we can start in two quarters," that is the system working. The question for the sponsor is what the two quarters of delay costs, and whether that number is larger than the cost of buying capacity outside the queue. Frequently it is, by a wide margin, and that comparison is a legitimate finance argument rather than an organizational grievance.
Focus that an internal team structurally cannot give. An internal team assigned to a new build is also on call for the systems it already owns, in the incident rotation, in the quarterly planning cycle, and subject to reassignment when something breaks. Effective capacity on the new thing is a fraction of nominal capacity, and the fraction is unpredictable. An outside team assigned to one build is on that build. That is not a statement about diligence. It is a statement about competing obligations.
A skill used once rather than continuously. Standing up an evaluation pipeline for a probabilistic system, moving a workload to a new cloud architecture, taking a system through a security accreditation, building an accessible interface to a published standard: these come up once every few years per unit. Hiring for them means hiring a person whose specialty is idle most of the time, and specialists who are idle leave. Buying them for the window they are needed is what the skill is actually worth.
Risk that moves off your book. When an internal team misses a date, the business unit absorbs it. When an outside team is engaged on fixed-price milestones tied to written acceptance criteria, the schedule and scope risk sits with the supplier for the duration. That transfer has a price, which is why fixed-price work costs more per nominal hour than a time-and-materials arrangement. It is also a real purchase, and finance understands paying for risk transfer better than most sponsors expect.
Conditions that make an outside build team the cheaper option
Editorial weighting, illustrative rather than measured. The last row is deliberately low: permanent evolving ownership is the strongest case for an internal team.
The comparison finance actually wants
Most business cases fail at the same point. They compare the outside quote against an internal cost per hour that is not a cost, and the reviewer notices. Three errors do most of the damage.
Comparing a rate against a salary. An internal engineer's cost is not salary divided by the hours in a year. It is the fully loaded cost, including employer taxes, benefits, equipment, software licenses, cloud accounts, recruiting amortization, the manager's time, and the share of facilities and internal services the unit is charged for, divided by the hours that engineer will actually spend on this build. That last denominator matters more than any of the additions. An engineer nominally assigned at eighty percent, who is also on call and in the planning cycle, may deliver half of nominal capacity on the new work. The effective internal cost per productive hour on this build is often within sight of an outside rate before any of the other factors are counted.
Leaving out the cost of the delay. If the internal path starts two quarters later, the case has to price two quarters of not having the system. Sometimes that is revenue the business can name. Sometimes it is cost that continues: manual processing hours, error remediation, a license that could be retired, a regulatory remediation date. Sometimes the honest answer is that the delay costs little, and in that case the internal path is probably right and the case should say so. A business case that concedes the cases where it loses gets believed on the cases where it wins.
Counting only the build and not the alternative's overhead. The internal path has its own costs: recruiting if hiring is required, ramp time on the domain, and the opportunity cost of what the internal team is not doing while it does this. That opportunity cost belongs in the case explicitly, named as the specific work being deferred. Reviewers who see it treat the rest of the case as honest.
A worked example, with illustrative numbers
The numbers below are made up to show the method. Nothing here is a market rate or a measured figure. Substitute yours.
Suppose a business unit needs a document-processing system: ingest, extract structured fields, route exceptions to a human queue, and write results into an existing system of record. Say the unit currently pays for roughly four full-time equivalents of manual processing and wants that down to one plus an exception queue. Call the fully loaded cost of a processing FTE 90,000 dollars a year, so the manual cost being addressed is about 360,000 a year and the target saving is about 270,000 a year.
Internal path. Four engineers at, say, 220,000 fully loaded per year each. They are available at sixty percent of nominal because of existing obligations, so the effective team is 2.4 engineers. At that rate the build takes, say, nine months of elapsed time. Cost of engineering time consumed: four engineers times 220,000 times nine twelfths times sixty percent allocation, which is about 396,000 dollars. Add the delay: the internal team cannot start for two quarters, so the saving begins fifteen months out rather than at month nine. That is six extra months of the 270,000 annual saving foregone, about 135,000 dollars. Add the deferred work: the team's other roadmap item slips two quarters, and if the unit can name what that item was worth, name it.
Outside path. A team of four on fixed-price milestones, starting in three weeks, delivering in five months because the team is not split. Say the quoted price is 520,000 dollars for the build. The saving starts at month six. Internal cost is not zero: a product owner at, say, thirty percent for five months, a subject-matter expert at fifteen percent, and one internal engineer at fifty percent to learn the system and take it over. Call that about 150,000 dollars of internal time. Total roughly 670,000 dollars.
| Line (illustrative) | Internal team | Outside build team |
|---|---|---|
| Direct build cost | About 396,000, in engineering time consumed | 520,000 fixed price against milestones |
| Internal time still required | Included above, plus management | About 150,000: owner, expert, one engineer |
| Start | Two quarters out, queue dependent | Three weeks |
| Benefit begins | Month fifteen | Month six |
| Value of the nine-month difference | Foregone, about 200,000 at the stated saving rate | Captured |
| Schedule and scope risk | Sits with the business unit | Sits with the supplier to the acceptance criteria |
| Two-year position | Higher, once the delay is priced | Lower, and the capability lands with your engineer |
On these illustrative numbers the outside path costs more on the invoice line and less in total, which is the pattern the comparison usually reveals when delay is priced. It is not always the pattern. If the internal team could start next month, if the build is small, or if the system will need continuous change by the same people for the next four years, the internal path wins and the case should not be written.
Two things make this table credible to a reviewer. First, every number is labelled as an assumption with its source named as an assumption. Second, the sensitivity is shown: state what happens if the outside quote is thirty percent higher, if the internal start is only one quarter out, or if the saving is half what the sponsor believes. A case that survives its own sensitivity analysis gets approved. A case with one confident set of numbers gets sent back for a second opinion.
What a finance reviewer weighs when approving outside build spend
Editorial weighting, illustrative rather than measured. The last row is deliberately low: advocacy for a supplier invites a procurement objection.
How to write it so it clears finance on the first pass
Finance reviewers see many of these and reject on a small number of recurring grounds. Address each before submitting.
- Name the decision, not the vendor. The case is for buying outside build capacity for a defined result. Vendor selection is a separate paragraph and a separate process. Cases that read as advocacy for a chosen supplier attract a procurement objection that has nothing to do with the merits.
- State the internal alternative fairly and cost it fully. Include the fully loaded rate, the realistic allocation percentage, the earliest realistic start, and the work that gets deferred. Understating the alternative is the fastest way to lose the reviewer's trust.
- Price the delay explicitly. One line: what each month of not having this costs, and how that number was derived. If it cannot be derived, say so and drop the argument rather than gesturing at it.
- Show the shape of the spend, not just the total. Fixed-price milestones with dates and amounts, or a committed team at a stated monthly rate with a stated end. Finance cares about the commitment profile and the exit point as much as the sum.
- Write the acceptance criteria into the case. Measurable thresholds on named data, a latency figure at a stated load, a deployment that runs from a clean checkout. This is what turns the spend from a service purchase into a deliverable purchase, and it is the difference between a case that reads as consulting and one that reads as capital deployment.
- State what the company keeps. Code assigned outright and living in your repositories, data staying in your environment, documentation and runbooks as payment-gated deliverables, and one named internal engineer who will own the system afterward. A reviewer's real fear is a dependency, and this paragraph addresses it directly.
- Include the measurement plan and who signs it. The baseline measured before work starts, the metric, the method, the date it will be read, and the named person who will report it whether or not it flatters the decision. Cases that promise a benefit with no plan to check it are the reason later cases get harder to approve.
- Include the stop condition. The point at which the work is halted and what it will have cost by then. A case with a cheap exit is easier to approve than a case that argues nothing can go wrong.
What the internal path is genuinely better at
A case is stronger for being honest about this, and the reviewer will raise it anyway.
Systems that change continuously belong internally. A build with a defined end can be bought. A product that will absorb new requirements every quarter for years accumulates context that is worth holding in people who stay, and paying an outside team to hold it is paying rent on your own knowledge.
Work that is inseparable from a proprietary internal platform belongs internally, unless the platform team is part of the engagement. An outside team spending eight weeks learning an idiosyncratic internal deployment system is eight weeks you paid to teach someone something you already knew.
Anything where the constraint is a decision rather than capacity belongs internally. If three executives disagree about what the system should do, adding engineers accelerates nothing. Resolve the decision first; the engineering is the easy part after that.
How we work inside a large company
Precision Federal builds AI systems, data platforms, cloud infrastructure, and full-stack web and mobile software, and we deliver them into production, including inside U.S. federal agencies where the system has to clear authorization, accessibility, and data-handling review before it is allowed to run. That work sets our default: we build assuming a security review is coming, because for us one usually is.
What the first weeks produce. Week one and two: an architecture, a written scope, and acceptance criteria stated as tests, agreed with your sponsor before any build commitment. By roughly week six: a working slice against your real data, in your environment, doing one narrow thing end to end. Then increments against the milestone schedule, each one deployable, with your engineer working beside ours from the first commit.
What you keep. The code, assigned to you outright and written in your repositories from day one, with any pre-existing tooling of ours named in the agreement and licensed to you perpetually so no future maintainer is blocked. Your data stays in your environment. Infrastructure defined as code, the evaluation suite, the runbooks, and a handover rehearsal in which your team deploys while we watch, all tied to final payment rather than offered afterward. Your customers and your business relationships remain entirely yours.
How it is priced. Fixed-price milestones tied to the acceptance criteria when the scope is definable, which is the arrangement that puts schedule and scope risk on us. A committed team at a fixed monthly rate when the roadmap is genuinely open and you want capacity rather than a defined result. Not hours on a timesheet, because that arrangement makes us accountable for attendance when you need us accountable for an outcome.
The first step is one email with a one-page brief: the business problem and the number it moves, the systems the result must live inside named by product and version, what data exists and who can grant access, the security destination, the date that matters, and who can approve a scope change. We return a scoped, priced statement of work with acceptance criteria written as measurable tests, which you can drop into the business case as the spend line.
Five ways the case gets rejected
The comparison uses salary instead of fully loaded cost at realistic allocation. The reviewer recalculates in thirty seconds and now distrusts every other number in the document.
The delay is asserted rather than priced. "Time to market" without a number is not an argument. Either derive the monthly cost of not having the system or leave the argument out.
The case is framed as an internal-team deficiency. It invites a defense, turns a finance question into a political one, and is usually not even the strongest argument available.
There is no measurement plan. A reviewer who has approved benefits that were never checked will not approve another one without a named owner, a method, and a date.
The commitment has no exit. An open-ended engagement with no stop condition and no defined deliverable reads as an unbounded liability, which is what it is. Milestones with acceptance criteria and a stated stop point remove the objection entirely.
Bottom line
Large companies buy outside build teams for four reasons that hold up under examination: a full internal queue they cannot reorder, focus an internal team structurally cannot give, a skill used once every few years, and schedule risk that moves off the business unit's book. The case clears finance when it compares fully loaded internal cost at realistic allocation against the outside price, prices the delay with a derived number, names the work being deferred, shows the spend as milestones with acceptance criteria written as tests, states plainly what the company keeps, and includes a measurement plan and a stop condition. Write it that honestly and it will also tell you when not to buy, which is the part that makes it believable when you do.
Frequently asked questions
Because capacity is not the same as availability. The internal queue is prioritized for the whole company and may not be reorderable for a business unit; internal engineers assigned to a new build are also on call, in the incident rotation, and subject to reassignment, so effective capacity is a fraction of nominal; some skills are needed once every few years and a specialist who is idle leaves; and fixed-price milestones move schedule and scope risk off the business unit's book. None of those arguments requires claiming an internal team is inadequate.
Use fully loaded internal cost, including employer taxes, benefits, tooling, cloud, recruiting amortization and management time, divided by the hours the engineer will genuinely spend on this build rather than nominal hours. Then add the priced cost of the delay if the internal path starts later, and name the roadmap work that gets deferred. Compare that total against the outside price plus the internal time the engagement still requires: a product owner, a subject-matter expert, and one engineer who will take the system over.
The decision stated without advocating a vendor, the internal alternative costed fully and fairly, the monthly cost of delay with its derivation, the spend shown as fixed-price milestones or a committed team with a stated end, acceptance criteria written as measurable tests, an explicit statement of what the company keeps in code, data and documentation, a measurement plan with a baseline and a named reporter, a stop condition with its cost, and a sensitivity analysis showing what happens if the key assumptions are wrong.
When the system will change continuously for years, because the accumulated context is worth holding in people who stay. When the work is inseparable from an idiosyncratic internal platform and the platform team is not part of the engagement. When the internal team can genuinely start within weeks and the build is small. And when the constraint is an unresolved decision rather than capacity, since adding engineers to a disagreement accelerates nothing. A case that names these conditions and shows they do not apply is far more persuasive than one that ignores them.
Fixed-price milestones tied to written acceptance criteria when the scope can be defined, which is what actually transfers schedule and scope risk to the supplier. A committed team at a fixed monthly rate with a stated end when the roadmap is genuinely open. Avoid hourly time-and-materials for a defined build, because it makes the supplier accountable for attendance rather than for a result and leaves the definition of done with the buyer, which is the arrangement that produces most disputes.