Engineering firms are unusually hard to evaluate. The pitch is fluent, the case studies are unfalsifiable, and the difference between a firm that sells hours and a firm that delivers systems does not show up until month three, by which point the client has been given a date. That asymmetry is fixable, but not by better diligence questions in the abstract. It is fixed by holding the firm to a standard that is observable in the first two weeks, before the money matters. This is that standard, written from the side that has to meet it: what a partner should require, what each requirement reveals, the questions that separate the two kinds of firm, and the terms that make a relationship hold across many engagements rather than one.
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 consulting practices. We would rather be measured against this standard than described in adjectives.
The six requirements
Each of these is observable early, and each one is a proxy for something that is hard to observe directly.
A scoped and priced statement of work within days of a one-page brief. Not a capabilities deck, not a discovery phase, not a range with a footnote. A written scope with acceptance criteria, named engineers at stated allocations, milestones and a price. A firm that needs six weeks and a paid discovery phase to produce this is either unfamiliar with the problem class or is selling the discovery. A firm that has built the thing before can scope it quickly because it already knows where the difficulty is.
Senior engineers on the work, not in the pitch. The oldest failure in the category: the people in the room are not the people on the keyboard. The check is simple and non-negotiable. Ask for names, allocations as percentages, and start dates, written into the statement of work, plus a substitution clause that requires the partner's approval for a change. Then ask to meet the technical lead alone and have them walk through the design of a comparable system. Ten minutes of that is worth more than any reference.
Working software every week from week one. Not a status document, not a slide. Software running on a shared screen, doing something. Week one should produce an environment and a skeleton that deploys from a clean checkout through the real path. Week two should produce real data moving through it. Week three should produce a slice a sponsor can operate. A firm that cannot show anything running until month two has told you something important about how it works.
Transparent cost with the risk allocated deliberately. The partner should be able to say which parts are fixed price, which are a committed team, and why each is shaped that way. Fixed price where the destination can be written as acceptance criteria; a committed team where the scope is still forming. A firm that only quotes hours is asking the practice to carry all estimation risk, and a firm that quotes fixed price on a scope nobody has written is going to reopen the price later.
A client-safe voice. Engineers in a client's room should not advocate for technologies, criticise the client's existing systems, speculate about timelines, or agree to scope. This is a discipline, and it is testable: put the technical lead into a client meeting early and watch, rather than accepting an assurance about conduct.
A handover that is rehearsed, funded and inside the schedule. Not documentation delivered at the end as a courtesy. Source, build pipeline, infrastructure as code, environment configuration, credential rotation and a runbook, with the receiving team deploying the system while the partner watches, before the final invoice releases.
What actually predicts whether an engineering partner delivers
Editorial weighting, illustrative rather than measured. The last row is deliberately low: logos are the least predictive thing in the room.
The questions that separate the two kinds of firm
General diligence questions get general answers. These are specific enough that only a firm that has done the work can answer them, and the quality of the answer is visible immediately.
"Walk me through the last system you took into production. Where did it deploy, what gated go-live, and what went wrong?" A delivery firm answers concretely and volunteers the difficulty, because every real system had one. A staffing firm describes activity and outcomes without mechanism.
"What are the three things most likely to make this late?" The correct answer is about queues rather than code: data access approvals, environment provisioning, identity administration, security review, and decisions with a single owner. A firm that answers with technical complexity has not run into the real thing yet.
"How will we know it works?" Listen for numbers. A threshold on a named dataset. A latency figure at a stated load. A reconciliation to a report the business already trusts. A deployment that runs from a clean checkout. Answers made of adjectives predict an acceptance argument.
"What will you need from us, in what week, and what happens if it is late?" A firm that has delivered has a list ready and knows which items are on the critical path. This question also reveals whether they will manage the practice's own dependencies or simply wait and then blame.
"Who exactly writes the code, what percentage of their time, and what if the start slips a quarter?" A stated constraint is planable. An optimistic answer is not. The substitution path matters more than the initial roster.
"What does the operations picture look like six months after go-live?" Logging, alerting with owners, restore testing, dependency upgrades, a runbook. A firm that has no answer builds demonstrations that happen to be in production.
"What is in your standard agreement about intellectual property?" The answer should mention a present assignment rather than only work-for-hire language, and should volunteer a carve-out for pre-existing tooling. A firm that has never thought about this has not been asked by a serious buyer.
How the two kinds of firm behave, side by side
| Signal | A firm selling hours | A firm delivering systems |
|---|---|---|
| Response to a one-page brief | A capabilities deck and a paid discovery phase | A scoped, priced statement of work within days |
| Staffing answer | Roles and rates; names assigned after signature | Named people, stated allocations, substitution clause |
| First month output | Onboarding, discovery documents, a plan | An environment, a deploy, real data, a working slice |
| Definition of done | Left with the buyer; the supplier owns attendance | Written acceptance criteria the partner answers for |
| When something slips | Reported at the milestone it misses | Flagged the week the dependency was identified |
| End of engagement | People leave; knowledge leaves with them | Rehearsed handover gated to the final payment |
What the first two weeks should produce
This is the shortest reliable test, and it costs very little to run.
Week zero. A one-page brief goes over: what the client has decided and funded, the target system named by product and version, what data exists and who grants access, the deployment destination and any review the result must pass, the date that matters, the contract instrument, and who can approve a change of scope. Back comes a written scope with acceptance criteria, named engineers, milestones and a price. Days, not weeks, and not billed.
Week one. An environment exists. A skeleton application deploys from a clean checkout through the same path the finished system will use. Access requests for every data source and every environment have been filed, with owners and dates, whether or not the engineers are ready for them. The risk list is queues, not tasks.
Week two. Real data moves through the real path in a thin slice. Not sample data, not a synthetic file. The actual extract, with its actual encoding problems, its null patterns and its access controls. Almost every integration surprise that would otherwise appear in month four appears here instead, while the schedule can still absorb it.
A partner that produces those three weeks has demonstrated more than any reference call. A partner that cannot has demonstrated something too.
The terms that make it hold across many engagements
A first engagement runs on goodwill. A relationship across many engagements runs on terms, and six of them do most of the work.
- A present assignment of copyright, not only a work-for-hire recital. 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. A written present assignment is what actually transfers ownership from an independent contractor. Firms that rely on the recital alone can find themselves holding an implied license instead of title.
- Pre-existing tooling named, carved out, and licensed back. Any partner worth engaging arrives with existing components. Name them, exclude them from the assignment, and take a perpetual license to use them in the delivered system so a future maintainer is never blocked.
- Acceptance written as tests. A measured threshold on a named dataset, a latency figure at a stated load, a deployment that runs from a clean checkout, a conformance result against a named accessibility standard. Adjectives never get accepted, and the argument they produce damages the client relationship rather than the partner's.
- Named people with allocations and a substitution path. Written into the agreement, with a stated approval requirement for changes. This is the single term most often waived and most often regretted.
- Data handling agreed before the first extract. Where client data may live, who may touch production, whether any of it may be used to train a model, what is retained and what is destroyed at the end. Silence here is the fastest route to a legal review that stops a project mid-flight.
- A narrow mutual non-solicitation and a funded exit. Restrictive covenants are governed by state law and enforced case by case, so the workable term is narrow and mutual rather than broad. The exit is source, pipeline, infrastructure as code, configuration, credential rotation and a runbook, delivered as a condition of final payment rather than as a favour after it.
Terms most often waived, ranked by what waiving them costs later
Editorial weighting, illustrative rather than measured. The last row is deliberately low: broad covenants are the term most argued over and least enforceable.
Federal work raises the bar on three of these
If any of the practice's engagements deliver into a government agency, three of the requirements above become harder and one more is added.
The staffing requirement gets stricter, because government evaluation examines who does the work and what they have delivered before. Named people with relevant delivery experience are evidence; a resource pool is an assertion. The schedule requirement gets stricter, because go-live is gated by an authorization decision resting on documented and assessed security controls, commonly drawn from NIST SP 800-53, and that evidence has to be produced during the build rather than assembled after it. The deployment requirement gets stricter, because the destination is frequently a FedRAMP-authorized service or government region with its own service availability, and an architecture designed against commercial assumptions gets redesigned.
The addition is accessibility. Public-facing interfaces must meet Section 508 requirements, demonstrated by testing with assistive technology rather than asserted from a checklist, and retrofitting it into a finished interface usually costs more than building it in. Ask any prospective partner whether they have done this on a real system, and listen for whether they describe the testing or only the standard.
Why the first two weeks predict the sixth month
The claim that a fortnight tells you what a year will look like sounds like a shortcut. It is not. It follows from what the first two weeks actually require, which is every capability the rest of the engagement depends on, in miniature.
Producing a scope from a one-page brief in days requires that the firm has built this class of system before and knows where the difficulty sits. Nobody can scope quickly by being clever; they scope quickly by having been surprised already and remembering it. A firm that needs six weeks is not being careful. It is learning on the practice's time and often on the practice's money.
Deploying a skeleton through the real path in week one requires that the firm treats deployment as a first-class concern rather than a phase. Teams that leave deployment until the end are teams that discover in month four that the thing they built cannot be installed where it has to live. Doing it first inverts that risk permanently, and it takes a few days.
Moving real data in week two requires the willingness to look at the ugly version early. Everyone would rather work with a clean sample, because progress feels faster. The cost of that comfort is that every integration surprise waits until the design is fixed and expensive to change. A firm that insists on the real extract in the first fortnight is a firm that has paid for the alternative before.
Filing every access request on day one requires understanding that the critical path runs through other people's queues rather than through engineering effort. This is the single most reliable difference between firms that hit dates and firms that explain them. It costs nothing and almost nobody does it unprompted.
What a good partner will push back on
A firm that agrees to everything is a warning rather than a comfort, because most of the ways an engagement goes wrong are agreed to enthusiastically at the start. Four pushbacks are healthy and worth hearing.
A fixed price on a scope nobody has written. A partner who accepts this is either pricing in a large contingency or planning to reopen the number. The right response is to write the scope first, which takes days, and then fix the price against it.
A date set before the dependencies are known. If data access, environment provisioning and security review have unknown durations, a committed date is a guess dressed as a commitment. A partner should offer a date conditional on named dependencies with owners, and then hold it.
More engineers to recover a slipped schedule. Adding people to late work usually makes it later, because the existing team spends its time explaining rather than building, and because the constraint is normally a queue rather than capacity. A partner who proposes headcount as the first remedy has not diagnosed the problem.
Skipping the handover to save two weeks. This trade always looks attractive at the end of a budget and always costs more than it saves. The two weeks buy the difference between an asset the practice owns and a dependency it rents.
How we meet this standard
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 at stated allocations, and a milestone schedule. No paid discovery phase before the scope exists.
Week one produces an environment and a skeleton deployed through the real path, with every access request filed. Week two produces real data in a thin slice. Week three produces a working slice a sponsor can operate. Every week produces software on a shared screen, and the risk list tracks queues rather than tasks. Pricing is fixed-price milestones where the destination is written, or a committed team at a stated monthly rate where the scope is still forming, and we say which is which and why.
On commercial engagements we work under the practice's brand, in the practice's tooling, with the engagement lead owning every client commitment. On federal work we are named where being named helps the practice win. The practice keeps the client, the framing, the analysis, the account plan, the credit and the margin. The code transfers by written present assignment. The handover is a rehearsal inside the schedule, where the receiving team deploys while we watch, before the final invoice.
What a partner should not have to ask for
A short list, because each item on it is something a serious engineering firm offers without being asked. A written scope before money changes hands. Bad news early rather than at the milestone it misses. A named technical lead who is reachable. Software running every week. Documentation written for the person who inherits the system rather than for the file. A clear statement of what the firm is not going to do. And a price that does not change because the estimate was optimistic.
A practice that has to negotiate for those is negotiating with the wrong firm, and the cost of finding that out in month three is far higher than the cost of testing for it in week two.
Bottom line
The standard is six requirements, and every one of them is observable before the engagement is large enough to hurt. A scoped and priced statement of work within days of a one-page brief. Senior engineers named in the agreement with allocations and a substitution path. Working software on screen every week from the first. Cost stated with the risk allocated deliberately and explained. A client-safe voice, tested in a real meeting rather than promised. And a handover rehearsed and funded inside the schedule. Add the six terms that make a relationship durable, run the two-week test, and the choice between a firm that sells hours and a firm that delivers systems stops being a judgement call and becomes something the practice can see.
Frequently asked questions
On six things observable in the first two weeks. Whether a one-page brief produces a scoped and priced statement of work in days rather than a paid discovery phase. Whether senior engineers are named in the agreement with stated allocations and a substitution path. Whether working software appears on screen every week from week one. Whether cost is stated with the risk allocated deliberately between fixed price and a committed team. Whether the technical lead has a client-safe voice, tested in a real meeting. And whether the handover is rehearsed and funded inside the schedule.
Ask them to walk through the last system they took into production: where it deployed, what gated go-live, and what went wrong. Ask for the three things most likely to make this engagement late, and listen for queues rather than code. Ask how you will know it works, and listen for numbers. Ask what they need from you, in what week, and what happens if it is late. Ask exactly who writes the code and at what allocation. Ask what the operations picture looks like six months after go-live.
Both, applied deliberately. Fixed-price milestones where the destination can be written as acceptance criteria, which puts estimation risk with whoever owns the sequencing decisions. A committed team at a stated monthly rate where the scope is still forming. A firm that only quotes hours is asking the buyer to carry all estimation risk, and a firm that quotes fixed price against a scope nobody has written will reopen the price later. The partner should be able to say which parts are which and explain why.
Six. A written present assignment of copyright, because under 17 U.S.C. § 101 a commissioned work is a work made for hire only within nine enumerated categories and software is not among them. Pre-existing tooling named, carved out and licensed back perpetually. Acceptance written as measurable tests. Named people with allocations and a substitution path. Data handling agreed before the first extract, including whether anything may train a model. And a narrow mutual non-solicitation with a funded exit gated to final payment.
Week zero: a written scope with acceptance criteria, named engineers, milestones and a price, returned in days and not billed. Week one: an environment, a skeleton that deploys from a clean checkout through the real path, and every data and environment access request filed with owners and dates. Week two: real data moving through the real path in a thin slice, with its actual encoding problems and access controls. That sequence surfaces almost every integration surprise while the schedule can still absorb it.