Build it in-house or bring in an engineering partner

The decision usually arrives disguised as a hiring question

A team with a working product picks up a customer whose environment is unfamiliar — a government program office, a regulated buyer, a prime contractor, someone whose security staff sends words like authorization, impact level, controlled unclassified information, or air-gapped. Suddenly there is work on the roadmap that nobody on the team has done before, on a date nobody on the team set. The conversation that follows is almost always framed as headcount: do we hire two engineers who know this, or do we bring in a firm? That framing is comfortable because it is familiar. It is also the reason so many of these decisions go badly, because it collapses three separate questions into one.

The three are: who does the work, who holds the understanding when the work is finished, and who carries the risk of getting it wrong in a way nobody notices until an outside reviewer does. In-house and outside answer those three differently, and the honest answer for most teams is a split — some of it inside, some of it outside, with the boundary drawn deliberately rather than by whoever had capacity that quarter.

This is written for the team facing that decision for the first time. It is not a pitch for outsourcing. There are shapes of work where hiring is plainly correct and bringing in a firm is a waste of money, and we say which ones below.

What you are actually deciding

Who does the work. This is the labor question, the only one most build-versus-buy discussions actually address. It is answered by capacity, by cost, and by whether the skill exists on the market at a price you can pay.

Who holds the knowledge afterward. This is the one that determines your cost three years from now. Software you cannot change is a liability regardless of how well it works today, and the mechanisms that keep knowledge inside your company are contractual and architectural, not a matter of goodwill. They have to be designed in at the start; they cannot be added at the handover meeting.

Who carries the risk of silent failure. Some engineering mistakes announce themselves. A federal requirement misread does not. You find out during an assessment, or during a customer's security review, months after the architecture set. The value of experience here is not speed — it is knowing which decisions are irreversible before you make them.

When in-house is the right answer

Build it yourself when the work is recurring, when it sits close to what makes your product yours, and when the calendar allows for a learning curve.

• The work is permanent. Vulnerability remediation, patch cadence, evidence collection, and the operational side of a monitored system never end. A firm that leaves cannot own an obligation that runs indefinitely.
• It is the product, not the packaging. Your model, your data pipeline, your domain logic. Outsourcing the differentiator is how a company ends up renting its own product.
• The constraint is domain knowledge you already have. If the hard part is understanding your customers' work rather than understanding the deployment environment, nobody outside will get there faster.
• The deadline is far enough out to absorb learning. Learning is the cheapest way to acquire a capability if there is time for it. There often is not, and pretending otherwise is where schedules break.
• You will do it again. A second and third federal customer make in-house capability an investment. A single one-off makes it an expensive hobby.

There is a second reason to keep work inside that engineering teams underrate. In 1968 Melvin Conway published "How Do Committees Invent?" in Datamation, arguing that any organization designing a system produces a design whose structure mirrors the organization's own communication structure. The practical form of that observation: whatever you hand to an outside group tends to become a module boundary in your system, whether or not that is where the boundary belongs. Draw the split around a seam you actually want — a deployment adapter, a control-implementation layer, a data interface — rather than around whoever was available.

When in-house is the wrong answer

Hiring fails as a schedule lever. Fred Brooks made the point in The Mythical Man-Month in 1975 and it has not aged: adding people to a late project makes it later, because the new people consume the time of the people who already understand the problem. If the requirement is already on a date you did not set, a job posting is not a plan.

The clearer signals that the work does not belong in-house are structural rather than about speed:

The work is a one-time transformation. Moving a product from a single-tenant commercial deployment to something installable inside somebody else's environment is a large, bounded, deeply unfamiliar body of work that you will do once. Hiring a permanent team for it means either carrying capacity you no longer need or losing the people you just trained.

The failure mode is silent and the feedback loop is long. If the first honest signal that your architecture is wrong comes from an independent assessor a year from now, the value of having seen the pattern before is enormous and cannot be replaced by intelligence or effort.

The knowledge is perishable and narrow. Some rules you need exactly once — a cryptographic module validation status, a hardening baseline for a specific image, the shape of an interface a customer will not describe in a meeting. Building a permanent internal function around knowledge you will never use again is a poor trade.

You need someone who will tell you the thing you do not want to hear. Internal teams are structurally bad at telling leadership that a committed date is not achievable with the current architecture. This is not a character flaw; it is the incentive gradient. An outside firm with no promotion at stake can say it in the first week.

The decision, by shape of the work

Most engagements are not all one or the other. Sorting by the shape of the work gets you further than sorting by cost.

Three ways bringing in a partner goes wrong

The body-shop failure. You buy seats instead of an outcome. Nobody outside your company is accountable for whether the thing works, because the contract measures hours. This is the most common failure and it is visible in the first proposal you receive: if the deliverable is a number of engineers rather than a working result and a named artifact, you are buying labor and keeping all of the risk.

The black-box failure. The system works and nobody inside your company can change it. There are no architecture decision records, the reasoning behind the irreversible choices lives in somebody else's head, and the first significant change request goes back to the original firm because it has to. This is not usually malicious. It is what happens by default when knowledge transfer is a line item at the end of a schedule instead of a property of how the work was done.

The conflicted-reviewer failure. The same party builds the thing and grades it. The federal government writes this principle down: FAR subpart 9.5 rests on preventing conflicting roles that might bias a contractor's judgment, and FAR 9.505-3 states that evaluation contracts shall not be awarded to a contractor that will evaluate its own offers without proper safeguards. That rule binds federal contracting officers, not your commercial procurement — but the logic is worth borrowing outright. Whoever writes the assessment should have nothing to gain from its conclusions.

What a partner should actually be accountable for

The test is whether the engagement produces things that keep working after the firm is gone.

• A named outcome, not a headcount. The deliverable is a working result and specific artifacts, not a staffing level.
• Architecture decision records for every irreversible choice — what was decided, what was rejected, and why — written during the work, not reconstructed at the end.
• An honest inventory for anything handed over: what it satisfies on its own, what it inherits and from where, what it leaves entirely to you, and what evidence it emits without being asked.
• Runbooks and rebuild instructions your engineers can execute without the original team on a call.
• At least one of your engineers in the review path from the first week, with the authority to reject a design.
• A written recommendation you keep whether or not the build goes ahead.
• A defined end. A support window with a date on it, and a handover milestone that is tested rather than declared.

Architecture decision records and a current system model are the two artifacts that do most of the work here, because they are the difference between a system your team can reason about and one they can only operate. Written during the build, in the repository, they cost almost nothing; assembled afterward from memory, they are fiction. Our approach to that layer — decision records, C4 models, target-state design, and the trade-offs written down where the next team can read them — is described on our software architecture page.

The contract mechanics that actually decide who keeps the knowledge

Three areas cause more trouble than the rest combined, and all three are decided before any code is written.

Copyright does not transfer by default, and "work for hire" language often does not fix it. Under 17 U.S.C. § 101, a commissioned work qualifies as a work made for hire only if it falls within one of nine enumerated categories and is covered by a signed written agreement. Software is not among the nine. The Supreme Court held in Community for Creative Non-Violence v. Reid, 490 U.S. 730 (1989), that whether a creator is an employee for this purpose is determined by common-law agency principles — meaning an independent contractor's output is presumptively the contractor's copyright unless the contract says otherwise. The fix is ordinary and specific: a present, written assignment of all right, title and interest in the work product, not a paragraph that merely recites "work made for hire." Have counsel read the clause. This is not a place to reuse a template you found.

If federal money pays for development, a different rulebook applies. For noncommercial computer software delivered under a Department of Defense contract, DFARS 252.227-7014 sorts the government's rights into unlimited rights, government purpose rights, restricted rights, and specifically negotiated license rights, based largely on who funded the development. Government purpose rights run for five years by default unless a different period is negotiated, and at the end of that period the government's rights become unlimited. Under the SBIR and STTR programs, SBA's 2019 policy directive set a uniform twenty-year data protection period running from the date of award, implemented for DoD in the DFARS. Which category your work lands in is a function of funding and of how the deliverable is marked, and it is decided at contract award — not at delivery.

Obligations flow down whether or not anyone mentions it. If your work touches controlled unclassified information under a defense contract, DFARS 252.204-7012 requires the clause to be included in subcontracts, without alteration except to identify the parties, wherever performance involves covered defense information or operationally critical support. The Cybersecurity Maturity Model Certification program adds a certification requirement on the same path: the program rule at 32 CFR part 170 took effect in December 2024, and the acquisition rule adding the contract clause was published on 10 September 2025 and took effect on 10 November 2025, with requirements flowing to subcontractors that handle the relevant information. The practical consequence for a build-versus-partner decision: an outside firm in this path is not a neutral vendor. It inherits obligations, and you inherit the consequence of choosing a firm that cannot meet them. Related reading: NIST 800-171 and CMMC for software firms and what happens when CUI arrives in your product.

A structure that keeps the knowledge inside

When we are engaged, this is the shape we recommend regardless of who does the building. Each step names who owns it.

Step five is the one people skip, and it is the only one that proves the rest happened. If your engineers cannot rebuild the system from the repository and stand it up without a phone call, the knowledge did not transfer, whatever the closeout document says.

Where we fit, and where we do not

Precision Federal is an Iowa limited liability company — Precision Delivery Federal LLC. We are a small engineering firm with a few members; Bo Peng is Founder and CTO. We build production AI, machine learning, data and cloud systems that have to survive somebody else's review. On the architecture side specifically, we design target-state architectures, write architecture decision records and C4 models, build backends, APIs and event-driven and streaming systems, implement federated identity and zero-trust patterns, modernize legacy systems through incremental replacement rather than rewrite, and review an existing architecture and hand back a remediation roadmap. We also take work as a bounded assessment that ends in a written recommendation, with no obligation to continue.

What we do not do here matters as much, and we would rather you know before making contact. We are not a staffing agency and do not sell seats by the month; if what you need is bodies with a skill listed on a résumé, another firm will serve you better and cost less. We do not issue authorizations to operate — that signature belongs to a federal official. We are not a CMMC Third-Party Assessment Organization and cannot certify you; under 32 CFR part 170 those certification assessments belong to authorized assessment organizations. We do not perform your independent assessment and then remediate our own findings, for the reason FAR 9.505-3 gives. We hold no facility clearance today and do not perform classified work on classified networks. We are not a training vendor. We do not write proposals for other firms. And we will not tell you a component arrives pre-accredited, because nothing does.

How a first conversation goes

There is no retainer to talk. A first exchange is scoping: what the system is, what the customer requirement actually says, what is already fixed in the architecture, what has been tried, and what date somebody else has set. If it becomes clear the work belongs in-house, we will say that — it is a common and correct outcome, and a firm that never says it is not giving you information. If it belongs with a different kind of firm entirely — an assessor, a platform provider, a firm holding a clearance we do not hold — we will say that in the first reply and, where we can, point at who is better positioned.

Objections we hear

Frequently asked questions