A strategy practice reaches a point where the recommendation stops being the product. The client accepts the finding, funds the next phase, and asks a question the practice was not built to answer: who writes the code. The honest options are narrow. Build an engineering group inside a firm whose economics were designed around associates and partners. Rent people by the hour and manage them yourself. Or put an engineering firm behind the practice, under the practice's brand, accountable for a delivered system. The third option is the one most partners understand least and buy worst, so this is written to make it legible: what it costs, how it is staffed, what governs it, and what the firm keeps at the end.
Precision Federal builds AI systems, data platforms, cloud infrastructure, and full-stack software, and delivers them into production, including inside U.S. federal agencies. We work behind consultancies regularly. What follows is the arrangement described plainly, from the side that has to make it work.
Why the in-house build is harder than the spreadsheet says
Every partner who models an internal engineering group starts with salary and a utilization assumption, and the model looks fine. The model is not wrong about the arithmetic. It is wrong about the four things that sit outside the arithmetic.
The hiring clock does not match the client clock. A senior engineer who has shipped a production system into a regulated environment is a months-long search, followed by a notice period, followed by a ramp. The engagement that created the need closes before the first hire writes code. Practices solve this by hiring against the pipeline rather than the signed work, which converts a timing problem into a utilization problem.
Cost per billable hour is the reciprocal of utilization. Fully loaded cost includes benefits, tooling, cloud accounts, recruiting fees, and the management time to keep a group of engineers pointed the same direction. Divide that by hours actually sold, not by hours in a year. A group selling six hours in ten carries about 1.67 hours of cost per hour billed. At four in ten it carries 2.5. That reciprocal is why an internal team that looks cheap on a rate card is often the most expensive capacity a practice owns.
The career model does not have a slot for the person you need. A consulting pyramid promotes generalists who sell and manage. The engineer worth hiring is a senior individual contributor who wants to stay technical, will not manage six analysts, and compares offers against product companies rather than against consultancies. Firms that hire one usually lose them within two years, and the loss takes the system knowledge with it.
Engineering carries obligations a strategy practice has never carried. On-call. Security patching. Dependency upgrades. Incident response. Accessibility conformance. When the practice ships software, someone is responsible at two in the morning, and that responsibility does not fit inside a staffing model built on engagement cycles.
Conditions that favor an engineering partner over an internal group
Editorial weighting, illustrative rather than measured. The last row is deliberately low: repeat resale is the strongest case for owning the group.
What the arrangement actually is
Strip away the labels and there are three distinct commercial shapes, and confusing them is the origin of most disappointment.
Bodies by the hour. The firm buys time and supplies the direction. The supplier is responsible for attendance and skill level. Nobody outside the firm is responsible for whether the system works. This is a legitimate purchase when the firm has a technical lead who will own the design and the schedule. It is not what most partners think they are buying.
A committed engineering team. The firm buys a named group at a stated allocation for a stated period, with a technical lead who owns architecture and sequencing. Scope moves week to week; the team does not. This fits work whose shape is still forming, or a practice with several accounts feeding one queue.
An outcome priced to written acceptance criteria. The firm buys a defined result. The partner owns the estimate, the sequencing, and the risk of being wrong about either. This fits work whose destination is clear enough to write down as tests.
The engineering arm a practice does not hire is usually the second and third shapes braided together: a committed team for continuity across the account, with each build increment priced to fixed milestones so the practice can quote a number to a client and keep its margin.
Under whose brand, and who the client sees
On commercial work the default is that the practice is the face. Our engineers appear in the client's tooling under the practice's account, write in the practice's documentation templates, and join the client's stand-up as part of the practice's team. Client-facing decks carry the practice's name. That is ordinary and any competent engineering partner should expect it without negotiation.
Two places the default should be examined. First, when the client's own engineers will inherit the system, they behave better toward a named engineering group than toward an anonymous resource. The handover goes faster because the receiving team knows who to ask. Second, on federal work the calculus flips entirely, and that is covered further down.
How the work is staffed in the first three weeks
This is where an engineering partner earns or loses the relationship, so the sequence deserves detail rather than reassurance.
Week zero, before any commitment reaches the client. A one-page brief from the practice becomes a scoped, priced statement of work. The brief needs to answer what the client has funded, what system the result lives inside named by product and version, what data exists and who grants access, where the result must be deployed, the date that matters, and who can approve a scope change. Given those, a competent partner returns a real scope in days. Given a deck, the partner spends two weeks reconstructing the same seven answers and the practice pays for the reconstruction.
Week one. Environment access, identity, repository, pipeline, and a running skeleton deployed to a real environment. Not a local prototype. A thing that builds from a clean checkout and deploys through the same path the finished system will use. Everything after this is easier or harder depending on whether week one produced that.
Week two. Real data moving through the real path, in whatever thin slice is available. Not sample data. Not a synthetic file. The actual extract, with its actual encoding problems, its actual null patterns, and its actual access controls. Most schedule overruns in data-heavy builds are discovered here or discovered in month four, and the difference between those two discoveries is the entire project.
Week three. A working slice a client sponsor can operate. Narrow, unpolished, and genuinely functional end to end. This is what converts an engagement from a promise into evidence, and it is what a practice should demand of any engineering partner before the second invoice.
Three systems that are always underestimated
Partners scoping a build tend to price the visible part, which is the model or the application. The cost lives in three places nobody puts on the slide.
Data integration. Not the pipeline diagram, the reality underneath it. Source systems that export at different cadences. Identifiers that do not join because one system trims whitespace and another does not. Historical records restated after the fact, so a report run in March and rerun in May returns different numbers for the same period. Time zones stored inconsistently across a decade of rows. A build plan that allocates two weeks to integration and eight to the model has almost always got the ratio backwards.
Identity and access. Who can see what, enforced at the data layer rather than in the interface. Group membership sourced from the client's directory rather than maintained in the application. Approval flows that mirror the client's actual delegation of authority, which is never the org chart. This is where a security review stops a project, and it is the least glamorous work in any build.
Operations. Logging that answers questions rather than filling disks. Alerting with owners attached. Backups tested by restoring, not by existing. Dependency upgrade paths. A runbook a person who was not on the build can follow at three in the morning. Systems that lack this are demonstrations that happen to be in production.
Where build effort actually lands on a data-heavy engagement
Editorial weighting, illustrative rather than measured. The last row is deliberately low: the model is the part everyone scopes.
Pricing that lets the practice keep its margin
A partner that only quotes hours pushes all the estimation risk onto the practice, which then either pads the client number and loses the sale or holds the number and eats the overrun. Neither is a working arrangement across many engagements.
The shape that holds is fixed-price milestones for work with a written destination, and a committed team at a stated monthly rate for work that is still forming. Fixed price is not a discount posture. It is the partner accepting estimation risk in exchange for owning the sequencing decisions, and it only works when acceptance criteria are written as tests rather than adjectives. Accurate, scalable, and production-ready are not acceptance criteria. A measured threshold on a named dataset, a latency number at a stated load, a deployment that runs from a clean checkout, and a conformance report against a named accessibility standard are.
For a practice quoting a client, that shape matters more than the rate. A fixed number the practice can mark up is a sellable line item. An open-ended hourly commitment is a risk the practice carries alone.
| Dimension | Internal engineering group | Hourly staffing supplier | Engineering partner behind the practice |
|---|---|---|---|
| Time to first working code | Hiring cycle plus ramp, typically months | Weeks, then a ramp on the client stack | Days to weeks, gated by environment access |
| Who owns the word "done" | The practice, through its own management line | The practice. The supplier owns attendance | The partner, against written acceptance criteria |
| Cost between engagements | Continues in full; utilization decides margin | Stops, and the system knowledge leaves | Stops, or a small support increment is retained |
| Who the client sees | The practice | The practice, with individuals visible in tooling | The practice, unless naming the partner helps |
| Who runs it after go-live | The practice, permanently | Nobody, unless separately contracted | The partner or the client, decided in the scope |
| Typical failure mode | Utilization falls and the practice carries the group | Nobody is accountable when the result misses | Bought as hours, then asked for an outcome |
Federal work changes the posture, not the arrangement
A public-sector practice pairing with an engineering partner faces a different set of facts. Systems delivered into agencies have to reach an authorization to operate, which means security controls documented and assessed against a recognized control catalog such as NIST SP 800-53, not a security summary written at the end. Cloud destinations are frequently FedRAMP-authorized regions rather than a commercial account. Controlled unclassified information brings handling and storage obligations that reach the engineering environment itself. Public-facing interfaces must meet Section 508 accessibility requirements, tested with assistive technology rather than asserted from a checklist.
The visibility default also inverts. On commercial work an unnamed partner is normal. On federal work, a named technical partner with a defined scope, real people, and a delivery record generally reads better to an evaluator than an anonymous pool of resources, and personnel evaluation makes concealment awkward. Decide the posture before anything goes to the government, not after somebody asks who wrote the code.
Independence deserves its own check. In federal acquisition, whether the firm that advised may also build is answered by regulation rather than by the client's comfort, and the restriction can reach a supporting role as well as the direct one. That analysis is cheap in the first week and expensive in the tenth. Run it before a date is given to anyone.
Governance that keeps the practice in control of the room
A partner who talks past the practice to the client is a partner who has broken the arrangement, whatever the contract says. Four mechanisms keep the relationship straight, and all four are ordinary to set up.
- One named engagement lead on each side. The practice has an engagement lead who owns the client relationship and scope. The partner has a technical lead who owns architecture and schedule. Every scope change passes through both. No engineer negotiates scope in a client meeting.
- A weekly working demonstration, not a status document. Software running, on a shared screen, doing the thing it is supposed to do. Progress reported any other way is progress asserted. A practice that accepts written status for six weeks running is a practice about to be surprised.
- A shared plan the practice can read. Milestones with acceptance criteria, in the practice's own tracker if it has one. Two people on the practice side should be able to say what is due next and what is at risk, without asking the partner.
- A client-safe voice. Our engineers write and speak in the client's room the way the practice would want. No technology advocacy, no criticism of the client's existing systems, no commitment made without the engagement lead. This is a discipline, and it is fair to test it in the first client meeting rather than take it on assurance.
What the practice keeps
The fear underneath this decision is rarely economic. It is that the partner ends up owning the client. That risk is real, and almost all of it is removed in how the agreement is drawn.
The practice keeps the client relationship, the framing of the problem, the analytical method, the account plan, and the credit. It keeps the margin on the build, because the partner's price is an input to the client number rather than a share of it. And it keeps the code, if the agreement says so in the right way. A work-made-for-hire recital is not sufficient for software, because under 17 U.S.C. § 101 a commissioned work qualifies as a work made for hire only where there is a written agreement and the work falls within one of nine enumerated categories, and software is not among them. What transfers ownership from an independent contractor is a written present assignment of copyright. Pair that with a named carve-out for the partner's pre-existing tooling and a perpetual license back, so a future maintainer is never blocked.
Two further terms are worth insisting on. A mutual non-solicitation, drafted narrowly and to the governing state law. And an exit that is a deliverable rather than a courtesy: source, build pipeline, infrastructure as code, environment configuration, credential rotation, and a runbook, delivered as a condition of final payment. The best handover is a rehearsal, where someone on the receiving team deploys the system while the partner watches, before the last invoice.
Five ways this goes wrong
The partner is bought as hours and then asked for an outcome. The most common failure by a wide margin. Hours were priced, so the partner staffed to hours, and the practice expected accountability it did not purchase. Decide which of the three shapes is being bought, and price it that way.
The scope is written in adjectives. When acceptance is subjective, acceptance never arrives, and the engagement ends in an argument about whether the work was good instead of whether it met the criteria. Numbers in the statement of work prevent this entirely.
The pilot is built where it can never be deployed. A prototype standing on a convenient cloud account with a copy of production data is a prototype that dies in security review. Build in the environment the system will live in, or against a stated authorization path from the first week.
Data access arrives in month three. The single most reliable schedule killer. Access approvals are an organizational process, not a technical one, and they should start on the day the scope is signed rather than the day the engineers are ready.
Nobody wrote the exit. Knowledge leaves with the partner because the handover was never scoped, funded, or rehearsed. It costs two weeks to do properly and it is the difference between an asset and a dependency.
How we work behind a practice
The first step is one email with a one-page brief. We return a scoped, priced statement of work with written acceptance criteria, named engineers with stated allocations, and a milestone schedule. No discovery phase billed before the scope exists.
In the first weeks the practice gets an environment, a running skeleton deployed through the real path, real data in a thin slice, and a working demonstration a sponsor can operate. Pricing is fixed-price milestones where the destination is written, or a committed team at a stated monthly rate where it is still forming. The practice keeps the client, the code, the margin, and the credit. We work under the practice's brand on commercial engagements, and we are named on federal work when being named helps the practice win.
What makes the arrangement durable across many engagements is not the first project. It is that the second one starts faster because the environment patterns, the security posture, and the working rhythm already exist. A practice that has run this twice can quote a build with confidence in the room, which is the capability it was trying to hire in the first place.
Bottom line
A strategy practice does not need to become an engineering company to sell working systems. It needs a build capability it can quote, staff, and stand behind, with a price shape a client will accept and a governance model that keeps the practice in control of the room. Hiring that capability means a months-long clock, a fixed cost aimed at bursty demand, and a career model that does not hold senior engineers. Renting hours leaves the definition of done with the practice. An engineering partner accountable for a written result gives the practice the arm without the payroll, and the practice keeps everything that matters: the client, the analysis, the code, the margin, and the credit. The check takes a week and the first brief takes a page.
Frequently asked questions
Build the team when the demand repeats across accounts, when the same asset is sold more than once, or when the firm intends to hold a product. Use a partner when the delivery date is shorter than a hiring cycle, when demand arrives in bursts tied to which clients said yes, or when the result has to clear a security or accessibility gate the firm has never cleared. An internal group is a fixed cost aimed at variable demand, and cost per billable hour is the fully loaded cost divided by hours actually sold, so utilization decides whether it is cheap or the most expensive capacity the practice owns.
Yes, and on commercial work that is the default. Engineers work in the client's tooling under the firm's account, use the firm's documentation templates, and join the firm's stand-up as part of the firm's team. Client-facing material carries the firm's name. The posture is worth revisiting in two cases: when the client's own engineers will inherit the system and a named technical group speeds the handover, and on federal work, where a named partner with a defined scope generally reads better to an evaluator than an anonymous resource pool.
Fixed-price milestones where the destination can be written as acceptance criteria, and a committed team at a stated monthly rate where the scope is still forming. A fixed number is a line item the firm can quote and mark up. An open-ended hourly commitment leaves all the estimation risk with the firm, which then either pads the client number and loses the sale or holds it and absorbs the overrun. Fixed pricing only works when acceptance is written as tests: a measured threshold on a named dataset, a latency number at a stated load, a deployment that runs from a clean checkout.
Whoever the assignment clause names, and the clause has to be drafted correctly. Under 17 U.S.C. § 101 a commissioned work qualifies as a work made for hire only if there is a written agreement and the work falls within one of nine enumerated categories, and software is not among them. A written present assignment of copyright is what transfers ownership from an independent contractor. Pair it with a named carve-out for the partner's pre-existing tooling and a perpetual license back to use that tooling in the delivered system.
One page answering seven things: what the client has decided and funded, what system the result must live inside named by product and version, what data exists and who grants access to it, where the result must be deployed and any security or accessibility destination, the date that matters and what happens on it, the contract instrument, and who can approve a scope change. Given those, a competent partner returns a scoped and priced statement of work in days. Given only a deck, the partner spends two weeks reconstructing the same seven answers.