The quotes in front of you look alike: matching scope headings, similar durations, different totals, and nothing that explains the gap. This page moves the decision to two things you still hold once the meetings are over. One is what each company asked you. The other is what its quote was willing to commit to paper.
Why they all sound the same
Quote language converges because everyone describing the same job reaches for the same words: scope, phase, delivery, support. Those words define the work without separating the teams offering to do it. What separates them is not the part they tell you, but the part they ask you and the part they are prepared to write down.
If you want to build your own list of questions, questions to ask a software company covers that side. Here we look from the opposite direction: when your questions fail to tell two candidates apart, read theirs instead. Companies that pitch alike rarely ask alike.
Three things a company should ask you about
The screens you want will come up in the first meeting, and that is unavoidable. The separation happens over who asks about the conditions behind the list. There are three, and you know all three while the company knows none of them. Who writes the information down first: someone at a desk, a technician on site, whoever picks up the phone? Does the signal hold where that happens? Do two unlike jobs land in the same inbox?
A price set before those three answers reach the quote is a price for the average brief, not for your work. Diotek used to take both of its requests on one phone line: a survey booking is raised for a room where nothing has been fitted, a service call for a unit already on the wall, and the site gave each request its own path. AlgoKlima holds a service job on the technician’s phone when a basement takes the signal away, then hands it over as soon as the connection is back; we run the product ourselves and keep building it. In both cases the condition was asked before any code, and the answer changed how the system was put together.
We apply the same measure to ourselves. Before the description box, the scope step of our quote form names three conditions of its own: is there a system to take over, does part of the work run in the field without a connection, do different kinds of request have to be tracked apart. How to carry your own working conditions into a first meeting is the subject of how to describe what you need.
Four lines to look for in the quote
A question that never reaches the quote counts as unasked. The four lines below are where one quote separates itself from another.
The assumption line. Your brief does not say everything, and each quote closes those gaps with a guess of its own. A sentence such as “we assumed field records are captured online” lets you correct the reading before you compare totals. Which lines a brief usually leaves unwritten is set out in why software quotes differ. If you already run a system, the same line has to state the takeover scope; where that work starts and stops for us is written on the software consulting page.
The maintainer. Maintenance is decided while the system is built; a team still asking at go-live has skipped the decision rather than postponed it. How that choice shapes the tools and the build order is covered in who maintains software after launch. The line you want names who answers after launch and what that team has to know. We pay it in our own product: AlgoCar draws a part off stock the moment a work order records it, the invoice comes out of that same chain, and adding to that chain and maintaining it both sit in our own calendar.
The acceptance definition. When acceptance is not in the quote, the signature waits for demo day. A demo runs the system from one side only; your difficulty begins when a second person edits something a colleague already has open. Where the scenario should come from is explained in what to test before accepting software. What you want in the quote is that difficulty, named as the acceptance scenario.
The handover list. Code and files can sit on your own disk while only the person who read the code knows which file belongs to which job, and then the system runs but cannot be rebuilt by you. The items and the check for each are counted in what you should receive at software handover. What matters here is the timing: the list belongs in the quote, not in the delivery email. A list written at the end holds whatever its author still remembers.
Reading the choice of tools without knowing the names
You can read this decision without recognising a single name, because there are two things to read: how many separate technical foundations the company’s work stands on, and which problem forced any extra tool that went in. Work standing on one foundation keeps small the set a maintaining team has to learn. A different foundation per job is a different dependency per job, and that dependency ends up on your maintenance bill.
The legitimate entry point for an extra tool is the place where the problem requires it. For Vipkurum that place is optical mark reading: the marks are taken from the image of the sheet rather than through a reader, so a changed layout is absorbed in software. That step went in for one problem, and the institutions’ remaining work runs on the same foundation. The sentence you want has this shape: which tool, for which problem.
The table below splits the criteria into two columns: the good sign that lets you relax when you hear it, and the warning sign that leaves you with a question. Run it on every candidate, then run it on us. Write your hardest working day into the quote form in one sentence, and read the reply for the assumption line and the maintainer.