What to prepare before asking for a software quote
Two companies ask for a quote on the “same” system and get proposals that look nothing alike. It is almost always because each provider imagined a different system. This is what to have in writing before asking for the first quote, so every proposal answers the same question.
Why software quotes look nothing alike
Custom software has no list price: its cost depends on how many processes it covers, how many kinds of user it has, which rules it applies and which other systems it talks to. If that is not written down, each provider assumes it, and you end up comparing assumptions instead of proposals.
You do not need a technical document. You need someone at your company to put into plain words what happens today, what should happen and who will use it. What people call “requirements” is, in practice, a description of your operation.
The seven things to have in writing
- The problem, in one sentence and with its cost: “quotes are slow and get lost between WhatsApp and email”, not “we want a system”.
- Who will use it: each kind of user (sales, warehouse, credit, leadership, your customer, your distributor) and what each one needs to see or do.
- Today's process, step by step, however messy: where it starts, who touches it, where it gets stuck and where something gets re-keyed.
- The rules that live in someone's head today: discounts, approvals, combinations that cannot be sold, per-customer exceptions.
- The data: what information exists, where it is (Excel, ERP, accounting system, email) and who keeps it up to date.
- The integrations: which systems the new one has to talk to (invoicing, ERP, inventory, payments) and in which direction.
- What a good outcome looks like: how you will know, a few months in, that the system worked. Less re-keying, faster answers, a report that does not exist today.
If you can only prepare one thing, make it today's process. It is what a good provider will ask about first, and what changes the proposal most.
A one-page template
You can copy this table into a document and fill it in. One page filled in well is worth more than a long document nobody finished:
| Topic | What to write | Example |
|---|---|---|
| Problem | What hurts today and what it costs | Every formal quote is assembled by hand and takes hours |
| Users | Kinds of user and what each one does | Salespeople quote; the manager approves discounts; the customer checks status |
| Process | Today's steps, start to finish | Request on WhatsApp → Excel → PDF → email |
| Rules | What is applied from memory | Maximum discount per salesperson; per-distributor pricing |
| Data | What exists and where it lives | Catalog in Excel; customers in the accounting system |
| Integrations | What it has to connect to | Invoicing system; ERP inventory |
| Outcome | How you will know it worked | Numbered quotes and the pipeline in view of leadership |
What you do not need to bring
- Drawn screens. Designing them is the provider's job, and if you arrive with them it is easy for your drawing to be quoted instead of your problem.
- The technology. Which language or which cloud is a technical decision; your part is to say what has to happen.
- Everything decided. Open questions (“we don't know whether the customer should see their credit”) are good information: say them as they are.
Ask for the proposal in stages
With the description ready, ask for the proposal to be split into stages, each one ending in something your team uses in production. That way you can compare providers stage by stage, and start with the part that hurts most without committing to the whole project up front.
That is how we work at Gridarco: each stage goes live with real users. Kit Machinery today brings together the configurator, quoting, credit, contracts, customer portal and after-sales on one record, and the platform has kept evolving since 2025: whatever is new joins that record instead of living in a separate system.
A proposal that is one fixed price for everything, with no stages and no scope per stage, is a sign the provider does not yet know what they will build either.
What to ask when the quote arrives
- What is in each stage, and what is left out?
- Who will design and write the code, by name?
- Are the code, the database and the accounts in my company's name?
- How are changes requested and priced after launch?
- Can I see a similar system working today?
For the rest of that conversation, the guide to choosing a software development company has the full list of questions and the warning signs.
Frequently asked questions
How long should the requirements document be?
As long as it takes to describe the process and no longer. For a first quote, one or two pages filled in well are enough; the fine detail is worked out with the provider you choose.
Should I sign a non-disclosure agreement before sharing it?
If the description includes sensitive customer or pricing data, it is reasonable to ask for one. Describing the process in general almost never requires sharing real data.
What if the process changes halfway through the project?
It almost always does: seeing the first stage working makes the rest clearer. That is why stages help: the change goes into the next one instead of breaking everything before it.
Has your operation outgrown spreadsheets?
Tell us how you sell, quote and serve today. We'll tell you what we would build, and in what order.