Why the system will not price your work

Four customers in four unrelated sectors have asked. The answer is no, and it is worth explaining why rather than saying so politely.

From the workshop · Platform team · 6 September 2026

The request arrives in different forms. Rate models and competitor mapping. Documents in, priced quotation out. One estimator put it directly: is this a bid tool or an estimating tool? A property developer asked whether it could assess commercial viability, and when told it could not, gave a fair verdict — “unless it can help answer that question, you’ll only be contributing to 30% of any bid.”

He is right about the proportion. We still are not going to do it.

The honest reasons

We would be wrong in ways nobody could see. Pricing is judgement applied to conditions — your supply chain, your current utilisation, the relationship, what you know about the site that is not in the documents. A system that produced a number from a tender pack would produce a confident number, and confidence is precisely the wrong property for a figure that is unverifiable until it is too late.

An answer that reads well and misses a requirement is recoverable at review. A price that reads well and is wrong is a job you deliver at a loss for three years.

The failure would be invisible until it was expensive. Everything else the system does can be checked against a document. Somebody can look at what a requirement says and confirm the flag was right. A price has no such check available at the point it is submitted.

It is a different product. Estimating software exists, integrates with your rates and your supply chain, and is built by people who have thought about nothing else for years. Doing a worse version of their job inside a bid tool serves nobody.

Where the line actually sits

The distinction we hold is between finding the requirement and pricing it.

The system will tell you that a requirement exists, that it applies to you, that it is qualified somewhere else in the pack, and that your response does not currently address it. That is a document problem, and documents are checkable.

What it costs to do is yours. That is a judgement problem, and judgement is not checkable in advance.

Put another way: it is very good at telling you what you have not priced. It will not tell you what to price it at.

Why we say this out loud

Because the alternative is worse for everyone.

If our marketing implies pricing capability, the demonstration collapses in the first ten minutes when somebody asks to see it. If it stays ambiguous, a customer buys expecting one thing and gets another, and we have bought a renewal problem with a signature.

Saying no clearly is cheaper than both, and it makes the yes more credible. A vendor with no boundaries has no boundaries you can rely on either.

The part where we might be wrong

The developer’s 30% figure is a real limitation, honestly stated, and worth sitting with rather than arguing away.

There is likely a version of this where the system does more to support the commercial side without producing numbers — surfacing what drives cost in a pack, flagging where a requirement has commercial consequence, making the estimator’s read faster. That is a document problem too.

We have not built it. If you have a view on what would actually help, we would rather hear it than guess.