A proposal is due Friday and it now contains a software build. Somebody has to put a number next to it. The number has to cover an engineering firm you will pay, carry margin the practice needs, survive a client procurement team that will compare it to other quotes, and still be defensible in month five when the build runs longer than anyone expected. Most firms price this by taking the partner's quote and adding a percentage, which works until it does not, and the moment it stops working is always the same: a change the client believes was included, a build that slips past the milestone that funds it, and a margin that quietly goes to zero while nobody wants to reopen the conversation.
This is the pricing problem, written for the partner or finance lead who owns the number rather than the engineer who owns the code. Precision Federal is on the other side of these arrangements, quoting builds that sit inside larger engagements. What follows is how the economics actually work, what a partner needs from you to quote accurately, and where the margin leaks.
Four ways to carry a build inside an engagement price
There are four commercial structures in general use, and firms often pick by habit rather than by fit. Each one moves risk to a different place, and the right choice depends almost entirely on how well the scope is known when the price is set.
Pass-through at cost with a stated fee. The client sees the engineering cost and pays the firm a separate management or integration fee, often a fixed amount or a percentage disclosed openly. Common where the client's procurement rules require visibility into what the engineering firm is paid, and on public sector work where cost transparency is expected. The firm's margin is explicit and therefore negotiable, but the risk transfer is clean: the engineering price is the engineering price.
Resale at a marked-up rate. The firm buys engineering hours at one rate and sells them at another. The client sees one blended number. This is the most common structure and the least examined. It works where the engagement is time-and-materials throughout and the client understands they are buying capacity. It fails when the client is buying a result and the firm has bought hours.
Fixed price on the whole engagement, build included. The firm quotes one number for advisory work and build together, and buys the engineering as fixed-price increments underneath. The client gets certainty. The firm carries the delta risk between what it promised and what the build costs. This is the highest-margin structure when the scope is genuinely known and the most dangerous one when it is not.
Separate contracts, coordinated delivery. The engineering firm holds its own agreement with the client. The consultancy runs the program and prices only its own work. Nothing to mark up, no delivery risk carried, and no margin on the build either. Used where independence rules require separation, where the client's capital budget funds the build separately, or where the firm simply does not want to carry construction risk.
What determines whether a resold build keeps its margin
Editorial weighting, illustrative rather than measured. The last row is deliberately low: markup protects nothing once the scope moves.
Why the markup is not where the margin lives
Consider an illustrative engagement. The advisory work is priced at a number the firm knows how to set. Underneath it sits a build the firm has bought for, say, four hundred thousand and sells for five hundred. On paper that is a hundred thousand of margin on the build, a fifth of the sell price, and it looks comfortable.
Now suppose the build runs eight weeks past the plan. If the firm bought it fixed-price against written acceptance criteria and the overrun was caused by the engineering partner, the overrun is the partner's cost and the firm's margin is intact. If the overrun was caused by scope the client added and there is no working change process, the firm absorbs it and the hundred thousand is gone by roughly week five. If the overrun was caused by a client dependency arriving late, and the contract said nothing about client dependencies, the firm absorbs that too.
The lesson is not that a fifth is too thin. It is that in a resale arrangement the markup percentage is nearly irrelevant to whether the engagement makes money, because the variance dwarfs it. What protects margin is the set of clauses that decide who pays when reality diverges from the plan. Firms spend hours negotiating a partner's rate down five percent and minutes on the change control language that will decide a swing ten times larger.
Fixed price versus time and materials, and what actually decides it
The choice is usually framed as a preference. It is not. It is a function of how much is known, and both parties can tell which regime they are in before anyone quotes.
Fixed price is honest when the work can be described as an outcome that can be tested. The target system is named and its interfaces are documented. The data exists and its shape is known. The integrations are identified. The acceptance criteria can be written as measurable statements rather than adjectives. Under those conditions a competent engineering firm can price the work, carry the estimation risk, and be held to it, and the client gets certainty they will pay a premium for. That premium is real and it is correct: a fixed price includes contingency for the estimating risk being transferred.
Time and materials is honest when the work is genuinely exploratory. Nobody knows whether the model will reach the accuracy the business needs. The data quality is unmeasured. The integration target is a system nobody has documented in a decade. Pricing that fixed forces the partner to load contingency until either the price is uncompetitive or the contingency is too thin and the project becomes an argument.
The hybrid that works better than either is a capped, staged structure. Price a short discovery increment at time and materials with a hard stop and a written deliverable, and commit to price the build fixed at the end of it. The discovery increment buys the information that makes a fixed price possible, and it costs a fraction of what a mispriced build costs. It also gives the client a natural exit that is much easier to sell than an open-ended commitment.
| Dimension | Pass-through with fee | Marked-up resale | Fixed price, build included | Separate contracts |
|---|---|---|---|---|
| Who carries overrun risk | Client, unless the fee is capped | The firm, in practice | The firm, explicitly | Client and engineering partner |
| Margin visibility to client | Explicit and negotiable | Hidden inside a blended rate | Hidden inside one number | None on the build |
| Upside if the build goes well | Fee only | Markup only | The whole delta | None |
| Needs from the partner | An accurate cost basis | A rate card and availability | A firm fixed quote to criteria | Nothing; they quote the client |
| Typical failure mode | Fee is squeezed at renewal | Client expects an outcome you bought as hours | Scope moves and change control is unused | Two vendors, one confused client |
| Fits best when | Procurement demands cost visibility | Whole engagement is time and materials | Scope is testable and known | Independence or budget requires it |
What an engineering partner needs in order to quote accurately
A vague brief produces a padded quote. That is not gamesmanship; it is arithmetic. An engineer asked to price work with five unknowns prices the unfavorable case for each, and the compounding is what makes the number look absurd. Every unknown you close before the quote comes back removes a layer of contingency, and closing them costs an hour of your time and none of your money.
Seven inputs do most of that work.
- The decision the client has already made and funded. Not the option space. If three architectures are still live, the quote covers the worst of the three.
- The target system named by product and version. Integrating with a current, documented platform and integrating with a decade-old installation that has been customized are different projects with the same one-line description.
- What data exists, where it sits, and who grants access. Plus whether a privacy or governance review is required, and roughly how long that takes at this client. Data access is the most common cause of a build sitting idle, and idle time in a fixed price is contingency someone paid for.
- The security destination. Whether the result runs in the client's cloud, needs to satisfy a specific control set, handles regulated or controlled information, or must reach an accreditation before it counts as delivered. Security work discovered late is expensive; security work known up front is planned work.
- The acceptance criteria, or a willingness to write them together. Measurable statements: a threshold on a named data set, a response time at a stated load, a workflow completed by a named role, a deployment that runs from a clean checkout. This single item moves quoted prices more than any other, because it is what converts an unbounded obligation into a bounded one.
- The dates that matter and what happens on them. A regulatory deadline, a board meeting, a client's fiscal year. A date with a consequence changes staffing and therefore price; a date without one is a preference.
- Who can approve a change, and how fast. If the answer is a monthly committee, the partner prices the delay that implies, and should.
Sending those seven is a one-page brief, and a partner who cannot turn it into a scoped, priced statement of work within about a week is telling you something useful about how they will run the build.
Change control is a pricing instrument, not paperwork
Almost every margin failure in a resold build is a change control failure. The pattern is always the same. The client asks for something small in a working session. An engineer, wanting to be helpful, does it. Three weeks later there have been eleven of those, the increment is late, and there is no record that anything was added. Nobody wants to raise it because each individual item was small and raising it now looks like relitigating goodwill.
The mechanism that prevents this is not a heavier process. It is a lighter one that actually runs. Three properties matter.
It has to be fast. A change process requiring a committee will be bypassed, and a bypassed process is worse than none because it creates the illusion of control. Aim for a written decision within about three business days, from a named person on each side who can commit.
It has to be used for small things. The temptation is to reserve it for large changes. But large changes get noticed anyway. It is the accumulation of small ones that consumes an increment, so the threshold should be low enough that the eleven small requests each generate a line, even if most are approved in a sentence at no cost.
It has to be visible to the client continuously. A running log of changes, their status and their cost impact, reviewed at the same cadence as everything else. The purpose is not to bill for every item. It is that when a change genuinely needs to move a date or a price, the conversation happens against a record the client has been watching, rather than as a surprise from someone who appears to be looking for extra money.
Mirror the change language in both contracts. If your agreement with the client allows changes at no cost within some tolerance and your agreement with the engineering partner does not, you have written yourself a liability. The scope words should be the same words, ideally copied.
Milestone billing and the cash gap nobody models
Milestones do two jobs: they release cash and they force a decision. Both matter and they are often confused.
As a decision instrument, a milestone should correspond to something demonstrable. "Design complete" is a poor milestone because nobody can say whether it happened. "The ingest pipeline processes the client's production file format end to end and the output matches the agreed reconciliation on a named sample" is a good one, because it is either true or it is not, and someone can look at it.
As a cash instrument, the milestone schedule you owe the engineering partner and the one the client owes you should be aligned, and frequently are not. If the partner bills at the end of each four-week increment on net thirty, and the client pays on acceptance of a phase completing every twelve weeks on net sixty, the firm is financing the build. That gap is a real cost that belongs in the price, and it is invisible until the first quarter closes.
Three practical adjustments. Match the milestone boundaries even if the payment terms differ, so at least the events line up. Where the client's terms are long, either build the financing cost into the price or negotiate progress payments against the same demonstrable events. And avoid a structure where the last payment from the client is contingent on something the engineering partner has finished and been paid for months earlier; that is a pure risk position with no compensating upside.
Where margin leaves a resold engineering build
Editorial weighting, illustrative rather than measured. The last row is the thing most negotiations spend the most time on.
Risk sharing that both sides can actually sign
A firm carrying delivery risk on somebody else's engineering wants that risk shared. A partner asked to guarantee an outcome that depends on the client's data, the client's systems and the client's people will decline, or will price the guarantee so high it is not worth buying. The workable middle is narrower than either side's opening position and it has three parts.
First, the partner carries estimation risk on work fully within its control. If they said four weeks to build a service against a documented interface and it takes six because they estimated badly, that is theirs, and a fixed-price increment says so.
Second, client-side dependencies are named, dated and given a consequence. Not a penalty, a consequence: if the data extract arrives more than two weeks late, the increment's dates move by the delay and the price is revisited at a stated rate. Naming this converts the most common cause of overrun from an argument into arithmetic. It also makes the client's own obligations visible, which tends to make them arrive on time.
Third, genuine technical uncertainty is handled by staging rather than by risk transfer. If nobody knows whether the accuracy target is reachable, do not price a guarantee that it is. Price a short increment that answers the question and a decision gate afterward. Trying to push unknowable risk onto a partner produces either a refusal or a price that includes a large contingency you will pay for whether or not the risk materializes.
Presenting the build inside a larger engagement price
How the number appears to the client changes how it is bought. A few practical points.
Show the build as phases with named deliverables rather than as a single line labelled implementation. A client's procurement team compares lines, and an undifferentiated line invites a competing quote against a scope nobody has defined. Phases with acceptance criteria are harder to compare against a generic bid, and that difficulty is working for you.
Put the client's own obligations in the price document, not just in the contract. Data by a date, access by a date, a named decision-maker available at gates. Clients accept these readily when they appear as part of the plan and resent them when they appear later as excuses.
And state what happens after go-live, even if the answer is that support is out of scope and available separately. A price that stops at delivery with no mention of the following six months invites the client to assume that support was included, which is a margin conversation you will have at the worst possible time.
How we quote and what you keep
Precision Federal builds AI systems, data platforms, cloud infrastructure and full-stack web and mobile software, and delivers them into production, including inside U.S. federal agencies where a system must pass security authorization, handle controlled information and meet accessibility requirements. For a consultancy, that federal delivery track is both a route to government revenue for your clients and a discipline that shows up on commercial work as predictable environments, real evidence and a handover that holds.
On pricing, we quote in the shape the certainty supports and we say which one applies rather than the one that is easier to sell. Where the scope is testable, we price fixed increments against written acceptance criteria, billed at milestones tied to demonstrable events, with a written change process that runs in days. Where the work is genuinely exploratory, we price a committed team for a fixed number of weeks with a hard stop and a written finding, and commit to price the build fixed afterward. We will name client-side dependencies with dates and a stated consequence, because that is the item that decides whether your margin survives.
You keep what matters to your business. You keep the client relationship, and we do not approach your client independently during the engagement or after it without your agreement. You keep the code and the intellectual property, transferred by a written present assignment rather than a work-for-hire recital, with our pre-existing tooling named, carved out and licensed to you perpetually. You keep the data, held inside the boundary we agree and never used to train anything. We work under your brand where you prefer it.
The first step is one email with a one-page brief: the decision the client has funded, the target system named by product and version, what data exists and who grants access, the security destination, the date that matters, and who can approve a change. We return a scoped, priced statement of work with acceptance criteria written as tests, so you have a number you can put inside your engagement price and defend. No call required.
Bottom line
The markup is the least important number in a resold engineering build. What decides whether the engagement makes money is whether the acceptance criteria are testable, whether the same scope words appear in both contracts, whether a change process runs fast enough to be used for small requests, whether client-side dependencies carry a stated consequence, and whether the money you owe your partner lines up with the money the client owes you. Price the shape to the certainty: fixed where the scope is testable, a committed team with a hard stop where it is not, and a short discovery increment to convert one into the other. Fix those and a modest markup is safe. Skip them and no markup is large enough.
Frequently asked questions
The markup percentage matters far less than the contract terms around it. In a resold build, variance from scope changes, late client dependencies and untestable acceptance criteria routinely swings more than the entire margin, so a firm that negotiates hard on rate and lightly on change control has protected the small number and exposed the large one. Set a markup the practice can defend, then spend the negotiating effort on acceptance criteria, change control speed and matched payment terms.
It depends on how much is known when the price is set. Fixed price is honest when the target system is named, the data exists, the integrations are identified and acceptance can be written as measurable tests, and the client pays a premium for that certainty. Time and materials is honest when the work is genuinely exploratory. The structure that beats both is a short discovery increment priced at time and materials with a hard stop, followed by a fixed price on the build it makes estimable.
Seven things: the decision the client has already funded, the target system named by product and version, what data exists and who grants access to it, the security or accreditation destination, acceptance criteria or a willingness to write them together, the dates that matter and what happens on them, and who can approve a change and how fast. Each unknown you close removes a layer of contingency from the quote, because an engineer pricing five unknowns prices the unfavorable case for each.
Use change control for small requests, not just large ones, since it is the accumulation of small additions that consumes an increment while nobody wants to raise it. Write acceptance as measurable tests rather than adjectives. Name client-side dependencies with dates and a stated consequence so a late data extract becomes arithmetic rather than an argument. And align the milestone events you bill the client for with the ones your engineering partner bills you for, so the firm is not quietly financing the build.
Show it as phases with named deliverables and acceptance criteria rather than one line labelled implementation. Procurement teams compare lines, and an undefined line invites a competing quote against a scope nobody has written. Phased pricing is harder to compare against a generic bid and makes the client's own obligations visible in the plan. Also state what happens after go-live, even if support is out of scope and priced separately, since silence there invites the assumption that it was included.