How software work should be priced

The spread is not noise

A food distributor with forty trucks asks three firms to quote the same thing: stop the order desk from retyping customer purchase orders that arrive as email attachments. The quotes come back at $48,000, $130,000 and $310,000. The instinct is to assume two of the three are wrong. They are usually all approximately right, about three different jobs. The cheap one quoted the parser. The middle one quoted the parser plus the exceptions plus the integration into the order system. The expensive one quoted all of that plus rebuilding the order entry screen, because they looked at it and concluded it could not be integrated with. Whether that third read was correct is the single most valuable thing you learned that week, and it arrived disguised as a number you did not like.

Most pricing advice starts from the supplier's side: cost, margin, utilization. That is a real subject and it is not this one. This is about what you should be attaching a price to, what actually moves the number, and how to compare bids that are not describing the same work. If you take one thing: a price is only meaningful attached to a described boundary, and most of the money in a software project is spent on the things that live just outside whatever boundary got described.

What you are actually paying for

Hours times rate is how the invoice is produced. It is a poor way to think about what you are buying, because it implies the hours are mostly typing. On a project of any size, writing new code is somewhere between a fifth and a third of the effort. The rest goes into understanding a process nobody has written down, negotiating with systems that were not built to be talked to, handling the cases the process owner forgot to mention, and making the result survive contact with the people who have to use it every day.

You are paying for the removal of ambiguity. A six-clinic dermatology group asks for a tool that flags patients due for a follow-up. Simple, until you find that "due" means one thing for a surgical excision and another for a routine skin check, that two of the six clinics record the procedure in a note field rather than a code, and that one physician's follow-up intervals are deliberately different from the group's protocol and everyone knows it and nobody has written it down. That discovery is the work. The code that comes out the other side is short.

You are paying for integration surface. Every system your new tool must read from or write to is a negotiation with software you do not control. A modern application with a documented interface and an access token might cost two days. A twelve-year-old order system whose vendor charges for interface access, or has none, and where the only reliable path is a nightly file drop, can cost three weeks and constrain the design of everything downstream. The number of systems touched predicts cost better than the number of screens.

You are paying for the exceptions. The happy path is cheap. A specialty insurer's claims intake works fine for the ninety-one percent of submissions that arrive on the standard form. The remaining nine percent — the fax, the adjuster's email, the broker who sends a spreadsheet with merged cells — is where most of the build hours go and all of the value sits, because those are the ones consuming a person's afternoon.

You are paying for someone to be wrong in a recoverable way. Nobody gets a design right the first time. What you are actually buying is the ability to find out it was wrong in week three rather than week twenty, and to change it without starting over. That capacity has a price and it does not show up as a line item.

Rate ranges, stated plainly

Rates are the least interesting part of the price and the part buyers ask about first. They are worth knowing mostly so an outlier registers as an outlier. These are the ranges we see in the United States market in 2026 for engineering work of professional quality. They are broad on purpose; anyone quoting you a single national number is guessing.

The in-house figure is the one people miscompute. A senior engineer at $190,000 salary costs roughly $240,000 to $265,000 loaded once payroll taxes, benefits, equipment and a share of overhead are counted, and delivers somewhere near 1,500 to 1,700 productive engineering hours a year after holidays, sick days, meetings and the two months of ramp. That is $140 to $175 an hour, before recruiting. A contract rate of $200 is not four times the cost of an employee. It is roughly a third more, with no ramp and no severance, and it stops the day you stop it.

Notice the bottom row. Buyers describe projects by counting screens, and screens are the cheapest thing in the list. Two firms quoting the same twelve screens can differ threefold because one of them noticed the twelve screens sit on top of four systems and the other assumed one.

Price the uncertainty before you price the build

The most useful structural change a buyer can make is to stop asking for one price. Ask for two, in sequence. Buy a short, separately priced piece of work whose only output is a description of the real job, then price the build against that description.

A discovery engagement on a mid-sized business system runs one to three weeks and typically $8,000 to $35,000. It should produce a written process walkthrough, a list of every system to be touched with the access method for each, a sample of real data with the exception rate counted rather than estimated, a definition of done in a paragraph, and a build estimate with the assumptions written next to the number. If it produces a slide deck and a range, you bought a proposal, not discovery.

Two things make this worth doing even though it feels like paying to be quoted. First, a build price written after discovery is dramatically tighter, and the reduction in padding usually exceeds what the discovery cost. Second, discovery is the cheapest place to find out the project should not happen. A restaurant group with fourteen locations wanted a labor forecasting tool; two weeks of looking found that the schedules were already good and the overtime came from three managers who overrode the schedule on Fridays. That was a conversation, not a system, and it cost four figures to learn instead of six.

Three shapes, and what each one costs the buyer

Once the work is described, the pricing shape follows from how well it is described. There are only three shapes that matter and each one moves risk somewhere.

Fixed price transfers risk to the supplier, and they charge you for it. A competently priced fixed bid on genuinely ambiguous work carries fifteen to forty percent contingency, and you pay it whether or not it is needed. It also creates an incentive that becomes visible around week six: every question you ask becomes a negotiation about whether it was in scope. Fixed price is right when the requirement is genuinely nailed down and the value of budget certainty exceeds the contingency, which is most often true for a defined replacement of something that already exists.

Time and materials transfers risk to you, and removes the contingency and the argument. It is the honest shape for work where discovery continues into the build, which is most work involving data whose condition is unknown. Its failure mode is not overcharging; it is drift, where nobody notices that a four-week job is in week nine because each individual week looked reasonable.

Time and materials under a cap is what most business software should use. You pay for time actually spent, the supplier commits not to exceed a ceiling without a written conversation, and both sides review burn against remaining scope every two weeks. You give up a little of the supplier's contingency and you keep the flexibility. The clause that makes it work is boring: if the cap will be reached before the scope is done, the supplier must say so with at least fifteen percent of the budget remaining, not on the last day.

Change orders, and the honest number

Expect scope to change. On a project of three months or more, ten to twenty-five percent of the final scope will be something nobody wrote down at the start, and most of it will be a good idea. A process improves when people finally see it working. The question is not how to prevent change orders but how to make them cheap to agree.

Two provisions do nearly all the work. Set the change rate at the same rate as the build, in writing, so nobody is negotiating a premium mid-project. And carve out a small allowance — five to ten percent of the budget, described as such — that the project owner can spend on small changes without a new signature. Most change-order friction is not about money. It is about a $2,800 adjustment needing the same approval path as the original $130,000, so it waits three weeks and the momentum dies.

The running cost nobody quotes

The build price is a one-time number for a thing that then costs money every month. Ask for the annual running cost in writing before you sign, itemized, because a supplier who has not thought about it has told you something about the design.

For a typical internal business system serving twenty to two hundred people, expect hosting and managed database in the range of $200 to $2,500 a month depending on data volume and whether anything runs continuously. Third-party services — document processing, email delivery, address validation, mapping, a language model behind a feature — usually land between $50 and $1,500 a month and are the line that surprises people, because usage grows with adoption. Certificates, monitoring and backup are small but not zero. And maintenance labor, which is a subject of its own, generally runs twelve to twenty-two percent of the build cost per year.

A $130,000 build with a $2,000 monthly infrastructure bill and $22,000 of annual maintenance has a three-year cost near $270,000. That is not an argument against building it. It is the number the decision should have been made against.

How to make three bids comparable

Bids arrive describing different work, which is why the spread looks irrational. Four questions, sent to all three, normalize them faster than any scoring matrix.

1. Which systems will you read from or write to, and by what method for each? This is the question that separates the $48,000 bid from the $130,000 one. If a bidder has not asked what the order system's interface looks like, they have assumed an answer.
2. What percentage of records do you expect to fall outside the standard path, and what happens to those? A bidder who says "we will handle exceptions" has not looked. A bidder who says "we assumed under five percent and we would want to count it in week one" has.
3. What is in the price that is not code? Testing, deployment, training the people who will use it, documentation, the first weeks after go-live. A cheap bid is often cheap because these are absent, and they are not optional; they are simply moved onto you.
4. What would have to be true for this number to double? The answer is the risk register, obtained in one sentence. Anyone who says nothing would has not priced the job.

When a bid is very low, it is usually one of three things and they are distinguishable: the bidder is buying a first project deliberately, which is fine if you know it; the bidder is quoting the demo and expecting change orders to make the margin, which is not; or the bidder does not understand the integration surface, which is the most common and the most expensive to discover in month four.

When the honest answer is that you should not buy software

A meaningful share of the requests that reach us should not be built, and saying so early is cheaper for everyone than saying it in month three. Three patterns come up repeatedly.

The problem is volume that does not exist yet. A metal fabricator wants a quoting system. They produce eleven quotes a week, each takes about twenty minutes, and the estimator is good at it. That is under four hours a week. A $90,000 system that saves half of it pays back in something like a decade. Buy the estimator a better spreadsheet template and revisit at fifty quotes a week.

An off-the-shelf product already does eighty percent of it. Custom work earns its price when your process is genuinely different in a way that matters commercially. If it is different because of habit, the honest recommendation is to buy the product, change the habit, and spend a fraction of the budget on the one integration the product does not have.

The real problem is a decision nobody has made. Two departments disagree about who owns a number, and the proposal is to build a dashboard that shows both. The dashboard will get built, and the disagreement will move into the dashboard. Software makes a settled process faster. It does not settle an unsettled one.

Where the money gets wasted

• Buying a fixed price for work nobody can describe yet, then paying the contingency and the change orders both
• Comparing hourly rates across bids that assume different amounts of work
• Leaving training, deployment and the first month out of the budget, so they get done badly or not at all
• Approving the build without the annual running cost, and finding it in the following year's budget
• Making every small change need the original approval path, which stalls the project rather than saving money
• Choosing the low bid on an integration-heavy job where the low bid is low because the integrations were not counted
• Paying for a rebuild of something that works because it is unfashionable rather than because it is failing

Before you sign

• The boundary is written down, including what is explicitly out
• Every system to be touched is named, with the access method for each
• The exception rate has been counted on real data, not estimated
• Testing, deployment, training and documentation are line items, not assumptions
• The annual running cost is itemized in writing
• Change work is priced at the build rate, with a small allowance the owner controls
• There is a stated point at which the supplier must warn you about the cap
• You own the code, the data and the accounts on day one, not at final payment
• One named person on your side can answer questions within a day

Bottom line

Price follows description. Work that is described precisely can be priced precisely, and work that cannot be described precisely should be priced in two steps rather than guessed at in one. The rate is the least informative number in the conversation; the integration surface, the exception rate and the availability of the person who knows how the process actually runs will move the total far more than any negotiation over an hourly figure. When three bids disagree by a factor of six, do not pick one. Ask all three what they assumed, and buy from whichever answer teaches you the most about your own business.

Frequently asked questions