A request to a software company becomes quotable when it describes processes rather than screens, reports real volumes such as orders per day, users and data size, lists the systems to integrate with name and version, and names who decides. Technology choices and database design are the supplier's job, not the brief's.
Two kinds of request land in our inbox. One is a spreadsheet with forty numbered features, written by someone who has clearly spent a weekend on it. The other is three lines: we need to digitise the warehouse, can you give us a ballpark. Neither can be quoted seriously, and for the same reason.
Both describe a solution someone has already imagined instead of the work that needs to change. The feature list hides what those forty items are for, so we cannot tell which five carry the value. The three-line version hides everything. In both cases the first two meetings get spent recovering information the company already had.
The problem is not length
We have received thirty-page tender documents that told us nothing and one-page emails that let us price a project accurately. A request works when it lets an outsider reconstruct three things: what happens today, what should happen instead, and how often. Everything else is detail.
This matters for you more than for us. A vague request produces quotes that are impossible to compare, because each supplier fills the gaps with different assumptions. Then you pick the cheapest number, which is usually the one that assumed the least work.
Describe the process, not the screen
"We need a button that exports to Excel" is a solution. What we need to read is closer to this: every Monday morning someone in accounts pulls the week's orders out of two systems, reconciles them by hand in a spreadsheet, and sends it to the sales manager. It takes about three hours and once a month something gets missed.
That paragraph tells us who does the work, how long it takes, where the data lives, what goes wrong, and what a fix is worth. It also leaves room for a better answer than the export button: maybe that report should not exist at all, because the reconciliation only exists to compensate for two systems that never talked to each other.
Write down the exceptions. The normal path is rarely the expensive part. The expensive part is the customer who pays in three instalments, the order that ships from two warehouses, the price agreed by phone that overrides the list. Those cases are where estimates go wrong, and they are the ones companies forget to mention because everyone internally already knows them.
The numbers a real quote needs
Volumes change the architecture, and therefore the price. Fifty orders a day and five thousand orders a day are different projects even when the screens look identical. The same goes for the number of users, how many of them work at the same time, how much historical data has to be migrated, and where the peaks are: a company that does forty per cent of its year in November is not building the same system as one with flat demand.
You do not need precision here. Orders of magnitude are enough, as long as they are real ones taken from the systems you already run rather than the numbers you hope to reach next year. If both matter, write both, and say which one the software has to survive.
Integrations carry most of the risk
In our experience the difference between a project that lands on time and one that drifts is almost never the interface. It is the other systems. So name them: which management system, which version, on premise or hosted, does it have documented APIs, does anyone in the company have credentials for them, and does the vendor charge for access.
That last question saves more projects than any technical choice. We have seen integrations blocked for two months not by a protocol but by a licence: the software the company owned did not include the module that exposes the data, and nobody had checked before signing. Ask your current vendors in writing, before you ask us for a price.
What to leave out
Do not pick the technology. A brief that requires a specific language or database, without a reason tied to your own infrastructure or your own team, rules out good answers for no gain. If the constraint is real, say why it is real: our IT people maintain SQL Server and will not take on a second database. That is a constraint we can work with.
Same for table structures and screen layouts. Sketches are welcome as a way of explaining what you mean, not as a specification. And avoid asking for a fixed price on a scope nobody has defined yet: what you get back is either a padded number or an optimistic one that turns into change requests by month three. For unclear work, pay for the analysis first, as a small separate piece with its own deliverable, then price the build on that.
Reading the quotes that come back
Compare exclusions, not totals. A quote that does not mention data migration, user training, the test environment, or what happens in the weeks after go-live is not cheaper, it is shorter. Ask every supplier the same four questions: what is excluded, who owns the code and the repository at the end, what maintenance costs per year, and what happens if we want to change supplier in three years.
A request written this way takes an afternoon, and most of that afternoon is spent talking to the people who actually do the work. It is the cheapest part of the whole project and the one that decides the quality of everything you receive back. If you want a second pair of eyes on yours before you send it out, write to us: reading it costs nothing and usually takes twenty minutes.
