What a quoting system costs to run

The proposal for a quoting system carries one number, and it is the number for building it. The build is the cheapest part of a quoting system. The cost that decides whether it was a good purchase starts the week after go-live, and it never fully stops. For a multi-brand machinery dealer that cost has a concrete shape: five manufacturers, price books in five formats — sometimes a different format for each product series from the same factory — photos for every model, mast, and attachment, and a new price list landing every few months that someone has to load, check, and approve before a salesperson can trust it. None of this is in the proposal's number. Most of it is not in any number yet, because at signature nobody has seen a full year of the dealer's price books.

That is not vendors hiding the ball. It is a fact about what is knowable before the system meets the operation — and about which questions, asked before signing, make the unknowable part smaller.

The number every offer gets compared on

Comparing offers on the build price is not a mistake anyone should be embarrassed by. It is the one number that is fixed, comparable across vendors, and easy to defend in front of the owner. And the habit comes from equipment, where it works. A machine has a list price, a service schedule, and a parts catalog; the running cost is printed before the purchase. A dealer who has bought machines for twenty years has a well-earned instinct that the big number on the offer is the decision.

Vendors lean into the same instinct. Maintenance appears as a small percentage of the build price, or as "support included," and the offer reads as complete.

Software that runs on live catalog data does not behave like a machine. There is no service schedule printed by the factory, because the factory in this case is five different manufacturers changing their price books on five different rhythms. So the dealer compares three offers, picks one, signs — and somewhere around month seven meets the costs that were never in any of the three: how many source formats there really are, who resolves a price the system read but is not sure about, how fast somebody has to pick up the phone when quotes will not generate on a Friday afternoon. These were not left out of the offers through carelessness. They are not properties of the software — they are properties of the operation the software lands in.

Where the comparison breaks

Wherever anyone has measured software over its whole life, the same picture comes back. IEEE's engineering literature puts maintenance at 60 to 80 percent of total software cost across a system's operational life. A U.S. government audit found about 80 percent of a roughly $90 billion annual IT budget going to operating and maintaining what already existed, not to building anything new. Government systems are not a dealership's quoting tool, and the numbers should not be carried over literally. But the direction never flips: the build is the part you can see, and it is not the part you mostly pay for.

For a quoting system the recurring part is not even software work, mostly. It is data work, and it arrives on the manufacturers' schedule, not the vendor's. ETIM International — the standards body for technical product data, not a software company — describes the work exactly: retyping from PDFs, converting formats and units, renaming fields, chasing suppliers about missing values. Then it asks the question that decides everything downstream: who owns each part of this data. A proposal that never forces that question gets whatever answer the company improvises in month seven, usually in the middle of a price update.

The three layers of running cost

The useful move is to stop treating running cost as one line and split it into three, because the three behave differently — and only two of them are obligatory.

Layer	What it actually is	What drives the size	Optional?
Infrastructure	Databases, storage, media handling	Whether quotes carry product photos, how many, how often the range changes, how many versions accumulate — and whether images were optimized at build time or merely stored	No
Availability	Checking the system works, keeping it current, being reachable when it is not	The response-time commitment, not the headcount. How fast someone has to answer is the price variable	No
Development	New capability, automation, optimization	What the business decides is worth doing next	Yes

The first layer looks like a technical detail and behaves like a business decision. A machinery quote carries photographs — the model, the mast options, the attachments — and every new price book can bring a new set, while the old set has to stay retrievable because old quotes still reference it. Versions pile up. And storage is not one meter: Cloudflare's published pricing, to take one public example, bills stored images, delivered images, and image transformations as three separate line items. Whether the build optimized those images or just loaded them changes the bill permanently — modern formats like AVIF show better than 50 percent savings against JPEG in Google's own tests. None of this shows up in a demo. All of it is decided during the build, by someone who either asked the question or did not.

The second layer is a commitment, not a quantity. A dealer who needs an answer within the hour on a quoting day is buying something structurally different from a dealer who can wait until Tuesday — and the difference is not how much software exists, it is what the vendor has to keep staffed. This is the one running cost the buyer can genuinely dial, which is why it belongs in the scoping conversation and not in the small print.

The third layer is the one worth understanding best, because it is discretionary. New features, further automation, another integration — these get bought because someone sees a way to work faster, not because the system decays without them. A vendor who folds development into "maintenance" has merged a choice with an obligation, and the buyer loses the ability to say "not this quarter."

Where all three layers meet reality is the price-list cycle. Forklift price books change roughly every six months, in whatever format each manufacturer uses — and the formats differ between product series from the same factory, not just between factories. On our current builds we run the updates ourselves for the first three to six months, which covers one real cycle, and use that window to build the extraction tooling. Only after roughly 80 percent of the update cycles have gone through by hand is there enough ground to judge whether automating them is honest engineering or a promise. What one update cycle actually contains is worth its own article, because "the system updates the price list" turns out to describe eight or nine distinct pieces of work — and someone owns each one.

Why "just buy a platform" does not close the question

A subscription platform is the standard answer to all of this: let the vendor maintain it. That is true of one layer and false of the rest. The platform vendor patches their software, runs their servers, keeps their product alive — genuinely valuable, and genuinely theirs. What they do not maintain is the dealer's catalog, the mappings from each manufacturer's format, the price rules, the quote templates, the user permissions, the queue of values somebody has to verify. That work transfers to whoever the dealer assigns, inside a data model the dealer does not control. The distinction to hold onto is between platform maintenance and business-system maintenance. The subscription covers the first. The second is the subject of this article, and it does not appear on the invoice.

The other standard answer is the buy-don't-build rule: buy commodity software, build only what makes you different. As a rule it is sound — Martin Fowler's utility versus strategic split is the canonical version, and we apply it ourselves. The complication is that "quoting" sounds like a commodity while the dealer's input data is anything but. Multi-brand catalogs with per-series formats are precisely the case where a bought package still leaves you building and maintaining the translation layer indefinitely — only now inside someone else's schema. Whether that trade is worth it is a real calculation, not a slogan, and it deserves to be run per company rather than answered from a blog post.

Three fair objections

"You are describing your own retainer." Fair, and worth saying plainly: a company that sells ongoing engineering support benefits when buyers believe ongoing support is necessary. Two things make the argument checkable anyway. The three-layer split names one of the three layers as optional — which is not what someone maximizing a retainer would tell you. And the lifecycle evidence comes from IEEE and a government audit office, measured on systems we never touched.

"We will maintain it ourselves." Often the right answer — especially where the dealer has an internal IT lead who already owns the Comarch or SAP integration and knows the data. It stops being the right answer when it is assumed instead of staffed. Maintaining the catalog is a named job with a named person and a recurring slot in the calendar, or it is the thing that quietly does not happen in the quarter when everyone is busy. Doing it in-house is a legitimate decision. Leaving it implicit is what costs money.

"Our vendor quoted maintenance as a percentage, so this is handled." A percentage of the build price is a convention, not a measurement. It prices maintenance off how much software was written — but the running cost follows how much data changes and how fast someone must respond, and those two are what actually vary between dealers. We do not quote a maintenance figure before we know how many source formats a dealer carries and what response time the business expects. Any number offered before that is a guess.

The shift in plain terms

What a system costs over five years is set by two decisions made before the build: who maintains the data, and who operates it. This is not a refinement of how software offers are usually compared; it is a change in what the comparison is for. A cost estimate, as normally practiced, is a calculation performed once, to pick a vendor. A system that has to live five years needs something closer to an operating ledger: a short document naming who owns the catalog, who approves a price change, how fast an incident must be answered, and what happens to each of those when the person currently doing it gets promoted. Once those four are named, the estimate becomes something you can check against reality every quarter. Until they are named, it is a number that stops being true the week after signature. The question stops being what does this cost and becomes who is doing this, and for how long.

What changes from Monday morning

Here is what a dealer can do with this before the next vendor conversation.

Ask for the three layers separately. Infrastructure, availability, development — described apart, with development identified as optional. A vendor who cannot separate them has not thought about the second year.

Name the response-time commitment out loud. Not "good support" — how fast, on which days, for what kind of problem. That one sentence moves the availability cost more than any technical choice in the build.

Count your formats before you compare anything. How many manufacturers, how many product series, how many distinct file formats, how many refresh cycles a year. It takes an afternoon, it is the single input that most determines running cost in either direction, and it makes every offer on the table comparable for the first time.

Ask who does the price-list update in month fourteen. By name and by role. If the answer is a shrug, that is the finding — and what happens when that person leaves is the risk nobody writes into a proposal.

Count your manufacturers, product series, file formats, and refresh cycles — multiplied out, they are the running cost no proposal prints. The interactive version of this count runs here with JavaScript on; the four inputs are the four questions above.

What to stop doing: comparing totals built on different assumptions about who does the data work. Two five-year estimates are not comparable unless both name an owner for the catalog. Usually only one of them does — and it is not always the more expensive one.

We have been on the wrong side of this once ourselves, in a small way worth telling. An early customer of our previous platform asked when the monitoring features we had described during sales would arrive; the honest internal answer was about three months of engineering. We proposed a thirty-minute screen-share of the internal admin view instead. Thirty minutes in, they had checked everything that mattered to them, and the topic never came back. The cheapest maintenance is the work nobody had to build — and we nearly missed it by taking a feature request at face value.

If you are working out what a quoting system would cost your dealership to run, start by counting your formats and putting a name against the catalog. Bring both to a discovery call and the estimate stops being a guess.