Two quotes for the same software project differ because they price two different definitions of the job under identical line items. The reading that closes an open line is settled before any price exists, and the quote shows the difference without explaining where it came from. Line item names will not tell you which reading was priced; a quote that never mentions the fate of the existing code priced no reading at all.
Three quotes read one brief and priced three different jobs
The gap between quotes for the same brief comes from the lines the brief leaves open, because each supplier closes those lines with an assumption of its own. No brief contains every decision a quote has to price. The ones it misses do not stay missing on the supplier’s side; they get closed, quietly, one at a time, before a number can be written down.
There are only two ways to close a gap in a brief: ask about it, or assume something about it. Asking costs days, and while the answer is coming back the quote is late; a late quote in a competitive process often goes unread. Assuming costs nothing. That is why an assumption is not an exception in quoting work but the default, and the quieter the brief, the wider the assumption behind the number.
The assumption itself is never written into the quote. A quote is a pricing document rather than a decision document. It carries line items, durations and a total; it does not carry the reading that produced them. You are handed the document that shows the difference and never handed the document that explains it.
The practical effect is that you have no shared unit of comparison. The line item names look alike and so do the totals. The only thing that differs is the definition of the job behind them, and that definition appears nowhere on the page.
One concrete version of this sits on the corporate website side of our portfolio. The job that came in for KGM SsangYong was not to build a new site; it was to lighten the site that was already standing. That sentence has two legitimate readings. Rewriting the site and replacing it with a lighter version satisfies it. Leaving the existing code in place and touching only the parts that carry the weight also satisfies it. The two are not the same job, and they do not land on the same number.
Our own quote form closes this gap before it asks for a figure. The step where you describe the project opens with a note: “Each detail decides something: an existing system to take over moves the scope, records captured with no connection move the architecture, and requests that must stay apart move the data model.” The description box in the same step asks for scope rather than a figure: “Tell us the problem, goals, and anything that helps us understand scope.” The budget range field comes after that box, not before it.
The counter-case belongs here rather than at the end. If a brief genuinely settles every decision and the quotes still disagree, the difference sits in what the work costs each supplier. This article does not go there. Its subject is what happens where the brief says nothing.
Why company size and industry do not move the price
When a price gap needs explaining, the first place buyers look is usually not the supplier but themselves. Are we being quoted high because the company is large? Because the sector is specialised? Both of those details live in an optional step of our own form.
The step that asks for company details is labelled optional next to its heading, and its note reads: “Company details do not move the architecture; the next step’s answers do.” Industry and company size are the fields inside that step. The step can be skipped; skip it and the review screen says “No company information provided.” while the request stays complete.
Two jobs from the same industry can carry entirely different scopes: Diotek’s website keeps survey appointments and service requests in separate flows, while AlgoKlima’s field app opens a record without a connection. Both belong to heating and ventilation work. One is a decision about the data model behind a website; the other is a decision about what a phone does when it has no signal. The industry label predicts neither.
Technology names produce a similar misreading. The name of a stack does not set the price; it sets who will be able to keep the system running after launch, which is a question about the years after the invoice rather than the invoice itself. Who ends up carrying maintenance is a separate subject with its own answer.
There is exactly one place where company size touches a quote, and it is indirect: size sometimes changes how many surfaces hang off the same core. How many interfaces a single core has to serve is a real architectural decision with a real cost. But the answer to that lives in the scope lines of the brief, not in a company size field.
So the place to look is not the industry label. It is the lines that describe scope. The next three sections take those lines one at a time. All three are named in the step of our own form where you describe the project, and all three produce two separate jobs whenever a brief stays silent about them.
What “we already have a system” leaves unsaid
When a brief does not say how much of an existing system is to be taken over, one quote prices a rewrite from scratch and another prices reading the code first and touching only the parts that carry the load, and both readings satisfy the brief. A buyer with a working system usually writes this line in a single clause: we already have a system. The clause does not say how much of that system survives.
The first reading rewrites everything, and nothing in the brief forbids it: saying that a system exists is not the same as saying it stays. Under that reading the old code sits outside the pricing entirely. The second reading starts by reading the code, leaves the working sections where they are, and limits the work to the places carrying the weight. Under that one the old code sits inside the pricing, because someone has to go through it before anyone can say which parts get touched.
The name of the line is identical in both quotes. The content is not. The visible symptom is that one quote carries reading as its own item and the other carries no such item at all.
There is a way to find it. Ignore the line item names and look for what happens to the existing code. If its fate is not mentioned anywhere in the quote, no reading was priced. That one line puts two quotes on the same scale for the first time.
In the KGM SsangYong corporate site, where the code was read first and the working sections were left in place, the work followed the second reading: changes stayed inside the parts carrying page weight, and the site runs in that shape today. That is the only face of that project this article uses. How such a reading is carried out, and what constraints an inherited system brings with it, is a subject of its own.
Taking over a system that is already standing and improving it starts with the same question: which reading of that line does the buyer want? When the answer is written down, a quote prices one job. When it is not, two suppliers can price two different jobs and both remain faithful to the brief.
The limit is worth stating. If the source code is not in your hands, the second reading is not on the table at all, because there is nothing to read. Who holds the code is a separate question, but its answer needs to be known while the brief is being written.
When the brief never mentions working without a connection
A company with field engineers usually writes the line like this: the technician enters the record from the phone once the job is done. Nothing in that sentence mentions a signal. In that silence one quote prices a form that waits for a signal and another prices an app that opens a record where the coverage ends.
A capture form that waits for a signal writes straight to the server. There is a form on the screen and no durable local storage behind it, so with no connection there is no send step either. An app that opens a record where coverage ends writes to the device first and delivers the record to the office once the connection returns. On screen the two look much alike. In terms of where the data goes, they are two different applications.
Where that difference shows up is predictable. Not in the quote; on site. A boiler room is outside coverage, and so is a lift shaft. With a form that waits for a signal the technician cannot open the record there, so it waits until they are back outside, or gets typed up in the evening from memory. The assumption that made one quote cheaper only surfaces once the software is in use.
There is a second face of the same line on the office side. Under the waiting form, nobody can say when a record was actually created; an entry typed in the evening carries the hour the technician remembers. Under the other arrangement the record is created where the job was done and only its delivery is delayed.
The field app that opens a record where coverage ends is part of AlgoKlima, which we build and run: the technician opens the record where they are standing, and the record reaches the office when the connection returns. How a record waits on the device and in what order the queue drains is a design subject in its own right. What matters here is that none of this gets priced when the brief does not ask for it.
The counter-case is real. If your field team works inside coverage every day, this line produces no gap, and writing “with no connection” into the brief adds a requirement you will pay for and never use. The line exists to name a condition; it imposes no feature on anyone.
”Take requests from the website”: one form or two flows
This tends to look like the most harmless line in the brief: the site is being built anyway, and adding a field to a form is not a big job. Yet when “take requests from the website” does not name the request types, one quote prices a single contact form and another prices two flows that keep survey appointments and service requests apart from the start.
One form means one record type. Every request lands on the same list, carries the same fields and waits in the same order. Two flows mean a distinction inside the data model: the request carries its own type from the moment it is created and arrives at the operations desk already sorted. The gap between the two quotes is not on the visible face of the form. It is in where the record is written.
The timing of the bill is predictable too. In a quiet week one form is enough; requests arrive slowly and the office sorts them by hand. At the start of a season, when two kinds of request land on top of each other, that sorting turns into phone calls asking the customer which one they meant. The saving bought those phone calls.
In Diotek’s website, where a survey appointment and a service request are two separate flows from the start, the distinction was built into the data model, and the site runs with that separation. Why the two request types do not share one form has been written about separately. The point here is not whether the separation is correct. The point is that when the brief stays silent, two suppliers price two different jobs.
The reverse holds as well. If the site only ever receives one kind of request, a single form is the correct reading, and the quote that priced two flows priced work you did not want. Being more expensive does not make it more right.
Three lines, two assumptions, one closing sentence
On every line a brief leaves open, two quotes will assume two different jobs, and what closes the gap is one sentence saying which reading is wanted. The table below puts the three lines side by side. They are not taken from an invented checklist; they are the conditions named in the step of our own quote form where the project gets described.
| The line the brief left out | What quote A assumed | What quote B assumed | The sentence that closes the gap |
|---|---|---|---|
| Scope of the system being taken over | The existing site is rewritten from scratch; there is nothing to read in the inherited code, so the whole system is priced | The code is read first and that reading is its own item in the quote; working sections stay in place and changes are limited to the parts carrying page weight | ”Take over the system that is already standing: working sections stay where they are, and only the parts carrying the weight are touched.” |
| Records captured where there is no connection | The capture form waits for a signal; the technician sends the record once back inside coverage | The app opens a record where coverage ends, and the record reaches the office when the connection returns | ”A technician must be able to open a record where coverage ends, and that record must reach the office when the connection returns.” |
| Request types that must stay apart | Every request from the website lands in one form; the sorting happens in the office, by phone | A survey appointment and a service request are two separate flows from the start and arrive at operations already sorted | ”Survey appointments and service requests must arrive through separate flows, so nobody has to phone the customer to find out which is which.” |
The last column does not say that B is correct. Each sentence states which reading is wanted, and the reading you want may well be the opposite one, in which case you write the opposite sentence. What settles the gap is not which side you pick. It is that the line exists in writing at all.
The table is meant to be read against your own brief. Take whichever line applies to your work, look for its equivalent in what you sent out, and if it is not there, write the last column in your own terms. If none of the three applies, your brief is silent somewhere else and the same method still works.
There is a second reading of the table. A line that never enters a quote does not leave the job. The record in the boiler room still has to be captured. The survey appointment still has to be told apart from the service request. The weight in the old code still has to be carried somewhere. None of these disappear because nobody priced them; the bill is paid in use rather than in the quote, and often in the shape of a hand-kept second ledger.
What the three lines have in common is that each is an architectural decision wearing a commercial disguise. The takeover line decides where the code gets touched, the connection line decides where a record is written first, and the request type line decides how many record types the data model carries. All three are settled before any price exists.
Ask each supplier for its assumptions
Asking each supplier to list what it assumed turns the price gap into an address: the line missing from one list is the line that supplier priced without saying so. The move has two steps. First you write the sentences from the last column of the table, in your own terms, into the brief. Then you send that same brief to every supplier and ask each of them for exactly one thing: write down what you assumed while pricing this.
The request is deliberately singular. You are not sending a questionnaire or a technical specification; one demand that makes the supplier’s own reading visible is enough. Once you have it, every quote arrives with a decision document beside it, and for the first time the numbers sit on the same plane. The missing lines announce themselves: a line absent from a list is a line that supplier priced without telling you.
The second benefit is that you stop eliminating the lowest quote on reflex. A low number may have skipped something, or it may have priced a narrower reading of an open line, and that narrower reading may be precisely the job you want. With the assumption lists in front of you, the distinction is read off the lists rather than guessed from the figures. A supplier who declines to produce a list has also answered you.
Our own form follows the same order. The three conditions are named in the subheading of the step where you describe the project, the free description box where you set out scope comes next, and the budget range field comes after that box. Once a request is sent it is filed under a reference: “The reference is that record’s name; you never explain the request twice.”
The lines your brief leaves open are decisions that belong before the first line of code: what a record attaches to, which read comes from where, how many interfaces hang off one core. Where each of those decisions gets made is what the system architecture page sets out.
