What to ask before requesting a software quote
Before requesting a software quote, almost everyone prepares the question ("how much would it cost me to...?") and almost nobody prepares the answers. Then the industry replies "it depends", and it looks like the industry's fault. It only half is: a quote is an answer, and without information it can only be one of two things: a made-up number or an "it depends".
These are the questions worth having answered. They are not for the vendor: they are for you. They are the ones any serious team will ask you on the first call (us included), and arriving with them thought through turns an exploratory chat into a real quote.
One note before we start: you do not need documentation, a written scope or technical jargon. All six answers fit in a note on your phone, and they are worth more than a twenty-page RFP, because they describe how your business really works. And they work just as well with us as with any other vendor: they are yours, not ours.
The six questions
1. Do you sell from a catalog or made to order? It sounds like a question for a store, but it defines half the architecture. A catalog is a list of things that exist, with a price and stock. Made to order is a different story: options that combine, prices that are calculated and an order that has to reach production without anyone typing it in again. They are different projects, with different budgets, and the word "store" covers up both.
2. What system do you use today, and will the new one work alongside it or replace it? "None" is almost never true: a spreadsheet is a system, email is a system, the notebook next to the printer is too. If the new one works alongside what you have, we are talking about integrations. If it replaces it, we are talking about migrating data and years of history. Both paths are legitimate, but each comes with its own work, and knowing which one is yours changes the number.
3. Who will operate the system day to day? Not who signs for it: who types into it. How many people, how comfortable with technology, with what permissions. A system for three people who see everything does not cost the same as one with roles, approvals and a record of who changed what. And training the people who will use it is part of the project, not an extra that shows up at the end.
4. If it fails on a Saturday night, who wants to know, and what do they expect to happen? It is the question nobody arrives with an answer to, and the one that says the most about the project. Can it calmly wait until Monday? Does it need to alert someone on its own? Does it need to recover by itself? Each answer defines a different level of monitoring and alerts, and separates an office tool from a system the business runs on. None of them is wrong; what gets expensive is not having chosen. And you will be asked for this answer again the day something really fails: it is much cheaper to have it beforehand. Why this question matters more and more, we explain in the difference is how you handle failures.
5. What three things are done by hand today that should be automatic? Three, not thirty. The limit is what makes it valuable: it forces you to rank the pain, and that short list is the best starting point for deciding where to begin. The first module of almost all our projects comes out of this answer.
6. What would it mean for this to have gone well a year from now? Ask for a number. "Everything running better" cannot be built. "Closing the month in two days instead of ten" or "no longer hiring extra help for the busy season" can. The number turns a wish into a criterion: you will know whether the software worked, and the team building it will know what to optimize for. It is the version with numbers of the question we open every project with: what would success look like for you in this development?
What changes when you arrive with this
Two things. First: the quote you get can be a real one. Line items with their reasoning, a thought-out order, a first module that makes sense. Without these answers, any number you are given was made up before anyone met you, and we have already told how made-up numbers end.
Second: you spot the template seller sooner. Whoever asks you none of this is not quoting your project: they are pricing an imaginary one they brought from home. The number of questions you are asked before getting a figure is the best indicator of how serious the figure is. It is the same lesson as the locksmith's quote: you do not need to be technical to judge whether someone has thought about your job before putting a price on it.
Our side of the deal is published: rate and minimum in plain sight, itemized proposals and these same six questions on the first call. If you want to save a round trip, come with them answered: that conversation produces an honest plan, not an "it depends".