How to Price Custom Software Work Without Underselling or Losing the Deal
- Fixed price puts the client and the agency on opposite sides of every change request: the client has no marginal cost for adding scope, the agency has no reward for delivering more than the minimum. Use it only when scope is genuinely locked and change risk is low.
- Rate-times-hours estimates miss because early estimates carry a documented uncertainty factor of roughly 4x in either direction, before requirements are complete. The fix is not a bigger number — it is a ceiling with a scheduled review point.
- Value-based pricing charges against the outcome the software creates for the client, not the hours it took to build. It is the highest-margin model and the hardest to sell without a credible, client-stated number behind it.
- The deal is usually lost at the presentation, not the estimate. A single number invites a yes/no answer; three priced options move the conversation to which one, not whether.
Pricing custom software has no formula, only frameworks, judgment, and pattern recognition built from watching projects succeed and fail. Most agencies start with hourly rate times estimated hours, learn that estimates are wrong roughly half the time, and spend years evolving toward something more nuanced. This guide covers the three pricing models that actually work for custom NetSuite and WooCommerce integration work, how to load risk into a number before you quote it, and how to present that number so a real buyer signs it instead of shopping it against three other bids.
Contents
- Fixed price puts the client and the agency on opposite sides
- Rate times hours fails because the hours are unknowable early
- A ceiling turns time and materials from a risk into a ledger
- Risk-load the estimate instead of guessing a bigger number
- Value-based pricing charges for the outcome, not the hours
- Which model fits this engagement
- Present three numbers, not one, or you negotiate against yourself
Fixed price puts the client and the agency on opposite sides
When a client buys a fixed-price integration project, they are incentivised to add scope (“while you’re in there, can you also…”) because there is no marginal cost to them for each addition until the contract fights start. The agency, having fixed the price, is incentivised to cut scope and deliver the minimum that technically satisfies the spec. Both parties are optimising for their own interest, not the shared outcome — this is why fixed-price projects generate change-order disputes; the model builds the conflict in rather than removing it.
Fixed price still has a legitimate place: well-understood, bounded work where the spec will not move — a documented API integration against a stable third-party contract, a data migration with a fixed record count, a compliance change with an external deadline. The test is not “can we estimate this” (you can estimate almost anything); it is “will the client’s understanding of what they need change once they see the first working version.” For integration work touching a live ERP and a live storefront, it almost always does. Pricing pressure is also a common reason corners get cut on the estimate itself — see the real cost of a bad ERP implementation for what that costs downstream, in limits you can read before you sign anything.
Rate times hours fails because the hours are unknowable early
The default pricing method — multiply an hourly or day rate by an estimated hour count — fails for a specific, documented reason: early estimates are not slightly wrong, they are wrong by a predictable multiple. Software estimation research popularised by Steve McConnell as the “Cone of Uncertainty” and traced to Barry Boehm’s original work states that, before requirements are complete, “estimates have in general an uncertainty of factor 4 on both the high side and the low side” — the real effort can land at four times the first estimate or one-quarter of it. That is not a rounding error; it is a 16x spread between the low and high case, and it narrows only as the team locks requirements, then design, then code.
Quoting a single rate-times-hours number at the “initial concept” stage of that cone is quoting a number you already know is probably wrong, in either direction. Two responses work. First, pad the rate-times-hours estimate with contingency scaled to how early in the cone you are quoting from — heavier padding at “we’ve read the ticket” than at “we’ve written the technical spec.” Second, and better for anything longer than a two-week job: stop pricing the whole project from the wide end of the cone and price the discovery phase alone, fixed and cheap, with the build priced separately once requirements have narrowed the cone.
A ceiling turns time and materials from a risk into a ledger
Time and materials is transparent — the client sees exactly what they are paying for — but pure T&M creates anxiety for a client who cannot predict the final invoice, and it gives an unscrupulous agency no incentive to work efficiently. A budget ceiling fixes both problems without reintroducing fixed price’s misaligned incentives: the client gets an upper bound they can plan around, and the agency is still paid for the hours actually worked, not penalised for an accurate estimate.
The ceiling is not a cap on quality — it is a trigger for a scope conversation. At roughly 80% of the ceiling, both parties review: is the remaining work still necessary, has anything been learned that changes the plan, and does the ceiling need to move. If yes, extend it with shared agreement, in writing, before the work continues. If no, cut scope together rather than let the agency either eat the overage silently or pad future estimates to compensate. Bain & Company documents a version of this incentive-alignment problem from the buyer’s side: one company that “switched from paying service contractors on a time-and-materials basis to output-based contracts that aligned the company’s economic interests with its suppliers” cut its service costs by 10% as a direct result. A ceiling with a review point is the seller-side equivalent: it moves the conversation from “how many hours” to “what outcome,” which is where the T&M-ceiling and value-based models start to converge.
Risk-load the estimate instead of guessing a bigger number
“Add 20% for safety” is not risk loading — it is a guess wearing a percentage sign. Real risk loading ties the contingency to a named, specific unknown, so the client can see what they are paying for and the agency can defend the number in a scope-change conversation later. Three categories cover most integration work:
- Discovery risk — the target system’s actual field mappings, custom records, and edge cases have not been confirmed against a live account. Load this when the estimate was written from documentation or a sales call, not a sandbox.
- Integration-surface risk — the number of systems the code has to stay correct against (ERP, storefront, payment gateway, tax engine). Each additional system is not linear cost; it is a new set of failure modes and retry logic.
- Data-quality risk — historical data that has to migrate or reconcile is rarely as clean as the client believes. Load this whenever a migration or backfill is in scope and no one has run a sample export yet.
State each load as a line item against a named risk, not folded silently into the rate. A client who sees “discovery risk: 15%, because field mappings haven’t been confirmed against your sandbox” can act on it — get you sandbox access and the number can come down — where a client who sees a single padded total has nothing to negotiate but the whole price.
Value-based pricing charges for the outcome, not the hours
Value-based pricing sets the fee against the value the software creates for the client, not the cost to build it. Paddle, which absorbed the pricing-strategy practice ProfitWell built, frames the underlying method plainly: value-based pricing means you “set the price of your product or service in accordance with how much your target customer base or segment believes it’s worth” rather than pricing from internal cost or competitor rates. Applied to a services engagement, that means anchoring the fee to a number the client already owns — hours of manual work eliminated, error-driven refunds avoided, revenue a new sales channel unlocks — not to the agency’s day rate.
Work through a hypothetical, not a specific engagement, to see the arithmetic: a custom NetSuite-to-WooCommerce integration automates a reconciliation task that currently costs a client $8,000 a month in manual staff time — $96,000 a year at that run rate. A rate-times-hours quote for six weeks of standard integration work might land around $20,000. A value-based quote instead prices against the $96,000 the client already spends: $35,000–$45,000 is still well under half of one year’s cost of the manual process, so the client gets more than 2x its money back in year one, and the agency earns 75–125% more revenue for the same six weeks of delivery. Neither side is bluffing — both numbers are anchored to figures the client can verify from their own books. For what comparable integration work actually costs by order volume, see our NetSuite–WooCommerce integration cost breakdown.
Value-based pricing only works with a number the client trusts. Thoughtbot, a long-running software consultancy, publicly rejects fixed-scope pricing for a related reason — its own playbook states plainly that “we don’t do fixed-bid, fixed-feature-set proposals” because the right features are learned through prototyping and real user feedback, not guessed upfront. The same discipline applies to value-based pricing: you cannot credibly price an outcome you have not confirmed the client can measure.
| Dimension | Fixed price | T&M with a ceiling | Value-based |
|---|---|---|---|
| Client’s risk | Low on cost, high on scope disputes | Bounded — the ceiling is the worst case | Low if the value estimate is honest |
| Agency’s risk | High — absorbs every estimate miss | Low — paid for hours worked, capped by shared agreement | High until the client relationship earns trust |
| Best-fit scope | Locked spec, stable third-party contract | Evolving scope, discovery not yet complete | Outcome the client can measure and already spends against |
| What sets the final number | The estimate at signature, right or wrong | Actual hours, bounded by the ceiling | The client’s own cost or revenue baseline |
Verdict: default to a T&M ceiling for anything where requirements are still moving — which is most integration work — and graduate to value-based pricing only once you can state the client’s baseline number in their own terms. Reserve fixed price for the minority of engagements where scope genuinely will not change.
Which model fits this engagement
The three models are not competitors for the same job — each fits a different combination of scope certainty and outcome measurability. The decision reduces to two questions, asked in order: is the scope actually fixed, and can the outcome be priced in the client’s own numbers with the trust to back it.
Most integration engagements start in the bottom branch — a T&M ceiling — because trust and a verified baseline number both take a working relationship to establish. Value-based pricing is where the relationship graduates to once the first engagement has proven the outcome; it is rarely the right model for a first project with a new client. If you are the buyer rather than the agency in this conversation, the pricing model on offer is itself a signal worth reading — see how to choose a NetSuite integration partner for the rest of that vetting checklist.
Present three numbers, not one, or you negotiate against yourself
The deal is usually lost at the presentation, not the estimate. A single quoted number invites a binary answer — yes or no — and a “no” ends the conversation with nothing left to negotiate but the whole price. Presenting three priced options (a minimal scope, a recommended scope, and an expanded scope) changes the question from whether to buy to which option to buy — and where the choice lands is not neutral. A peer-reviewed synthesis of consumer-choice research, published via PubMed Central, describes the finding this way: “an option is more likely to be chosen by consumers and attracts a larger portion of choices when it is a compromising or middle option in a choice set”, tracing the effect to Simonson (1989) and Simonson & Tversky’s 1992 Journal of Marketing Research study — the well-documented compromise effect behind “good, better, best” pricing structures used across software, hardware, and professional services.
Three practical rules follow from this. First, the middle option should be the one you actually want to sell — most buyers gravitate there, so build your recommended scope, not your minimum, as the anchor. Second, show the arithmetic behind each number rather than presenting a bare total; a client who can see “discovery risk,” “integration-surface risk,” and the value baseline can negotiate scope instead of demanding a discount on a number they cannot decompose. Third, never present the cheapest option as free of trade-offs — pair it with the specific capability or risk protection it gives up, so picking it is a genuine decision, not a default.
Scoping a NetSuite or WooCommerce integration
We price engagements against the same three models covered here — a T&M ceiling by default, value-based once the baseline number is verified. If you want a scope reviewed before you quote it, that is where we start.
Get the working checklists
The runbooks and decision checklists from these guides, as printable PDFs — free in the SoftXone guide library.
References
- Paddle — A Guide to Value-Based PricingPaddle (which absorbed ProfitWell’s pricing-strategy practice) — value-based pricing methodology for software and subscription businesses.
- Bain & Company — Unearthing the Hidden Treasure of ProcurementBain & Company — documented case of a buyer moving contractors from time-and-materials to output-based terms, with the resulting cost reduction.
- Thoughtbot — Business Development PlaybookThoughtbot — a working software consultancy’s own public pricing and engagement structure.
- Construx — Software Development’s Cone of UncertaintyConstrux (Steve McConnell) — documented estimate-accuracy ranges across a project’s lifecycle, originating in Barry Boehm’s research.
- Compromise Effect in Consumer Choice — PubMed CentralPeer-reviewed synthesis, tracing to Simonson (1989) and Simonson & Tversky (1992), of the middle-option preference behind tiered-option pricing.
Frequently asked questions
Why does fixed price create bad incentives?
It removes the client’s marginal cost for adding scope and removes the agency’s reward for delivering more than the contracted minimum, so both sides optimise against each other instead of the outcome. Fixed price only avoids this when the spec is genuinely locked and the client’s understanding of the requirement will not change once they see working software — true for a small minority of integration work.
What is the T&M ceiling model?
Time and materials billing with an agreed upper bound and a scheduled review point, usually at 80% of the ceiling. The client gets budget certainty without paying for unnecessary padding, and the agency is paid for actual hours instead of being penalised for an accurate estimate. Extending the ceiling requires a written, shared agreement, not a silent overage.
How does value-based pricing work in practice?
You price against a number the client already owns — money saved, revenue unlocked, cost avoided — rather than the hours the work took. It only works once the client trusts the baseline figure, which is why it usually follows a T&M-ceiling engagement rather than opening a new relationship.
How much contingency should I add to a fixed-price quote?
Enough to cover the specific unknown you can name, not a flat percentage. Load discovery risk when field mappings haven’t been confirmed against a live sandbox, integration-surface risk for each additional system the code has to stay correct against, and data-quality risk whenever historical data has to migrate and no one has sampled it yet. Name each load against its risk so the client can negotiate the risk, not just the price.
How do I present three pricing options without the client just picking the cheapest?
Make the middle option the one you actually want to sell — most buyers default toward it — and attach a specific trade-off to the cheapest option instead of presenting it as the same thing for less. Showing the risk and value arithmetic behind each tier gives the client something to negotiate other than a straight discount.
Leave a Reply