← Ilumax Systems blog
Buying Software
What to Write Down Before You Ask for a Quote
The most useful hour in a software project is unpaid, and it happens before anyone is engaged.
If you do not write the specification, someone else writes it for you. Usually that is a vendor, usually while preparing a quote, usually from a half-hour conversation in which you described the business and they nodded. They will fill the gaps with assumptions, because they have to price something. You will find out which assumptions were wrong during the build, when changing them is most expensive.
None of what follows requires technical knowledge. It requires knowing your own business, which you already do, and writing it down, which is the part everybody skips.
One: pick one workflow, not the business
"We want to modernise our operations" cannot be priced by anyone honest. "From the moment an enquiry arrives to the moment a quotation is sent" can.
Choose the one that costs you the most in repeated effort, or the one that most often goes wrong. Write it as a start point and an end point, so it is obvious what falls outside. Everything you leave out is a decision you have made deliberately rather than a gap someone else fills in.
If you cannot choose, that is worth noticing. It usually means the pain is spread thin, and a build is the wrong first move.
Two: write what actually happens today, in order
Not the tidy version. The real one, including the parts that are slightly embarrassing: the figure retyped into a second system, the WhatsApp message chasing an answer, the folder someone checks because they do not trust the list.
Number the steps. Name who does each one. And record where things wait — waiting is a step, and in most service businesses it is the expensive one. A workflow with four working steps and three waits is a workflow with seven steps, and the waits are usually what the owner actually wants removed.
Do this by watching one real job go through, not from memory. Memory produces the process as it was designed. Watching produces the process as it runs.
Three: mark every point where a person decides
Go back through the list and mark each step where somebody exercises judgement rather than following a rule — approving a discount, deciding a job is unusual enough to price differently, choosing which supplier to ask.
These matter more than any other part of the document. They determine how much of the workflow can be automated at all, they are where the exceptions live, and they are the steps most likely to be quietly designed out by someone who did not realise a judgement was happening.
For each one, write down what the person is weighing. If you cannot articulate it, that is not a failure of the exercise — it is the discovery that this step needs a human, which is a useful thing to know before someone quotes you for automating it.
Four: inventory the data, and whether it can get out
List what information the workflow touches and where it currently lives: which spreadsheet, which system, whose inbox, which filing cabinet.
Then, for each system, answer one question: does it have an API, an export, or neither? You may need to ask your supplier or look at the settings screen. It is worth the phone call, because as we wrote in what actually moves the price of a build, that single answer changes a quote more than any feature you add or remove.
Note the condition of the data too. If customer names are entered three different ways, that is not a detail to sort out later — it is a decision someone in your business will have to make, case by case, and no developer can make it for you.
Five: write a definition of done in your own terms
Not "a CRM". Not "an automated system". Something you could check without opening the software.
Every enquiry has an owner within the working day. I can see what is outstanding without asking anyone. A quotation can be produced without opening last year's file. The rate is changed in one place.
This is the part that protects you. A build can satisfy a feature list completely and still fail a sentence like that, and the sentence is the thing you actually wanted. It also gives whoever builds it a way to disagree with you early, which is the cheapest moment for them to do so.
What this gets you
Quotes that can be compared, because everyone is pricing the same described thing rather than their own interpretation of a conversation.
A faster and more honest scoping discussion, because the questions a developer would spend the first week asking are already answered.
And a document you own. If you change supplier, or wait a year, or decide to buy a product instead, the work does not evaporate.
When the list tells you not to build
Sometimes the exercise answers the question by itself, and it is worth respecting that answer.
If the steps have changed twice while you were writing them down, the process is not stable enough to build against. Anything built now is a bet on a description that is already out of date.
If the list is four steps long and none of them waits, you probably do not have a software problem. You have a workflow that works.
If every problem on the list traces back to one person being too busy to approve things, software will make that bottleneck permanent rather than fix it.
And if the list looks exactly like something thousands of businesses do — invoicing, payroll, basic scheduling — the answer is to buy a product and adapt to it.
None of those outcomes wastes the afternoon. Deciding not to spend twenty or fifty thousand dollars is a good return on a few hours and a sheet of paper.
If a recurring administrative task is costing your business more time than it should, we offer a 20-minute workflow conversation — one task, and an honest answer about whether automation is appropriate. Get in touch.
More from the blog
Buying Software
What Actually Moves the Price of a Custom Build
Five things decide what a custom system costs, and a feature list is not one of them. What scope, integrations, data migration, approvals and support each do to a quote — and what you can do to lower it honestly.
Buying Software
Custom Software vs Off-the-Shelf: When Not to Build
We build custom software, and most businesses that ask us about it should buy something existing instead. Here is the line between the two, and the costs on both sides that get left out of the comparison.