Commissioning custom software: what to prepare so vendor quotes are accurate and comparable
Before asking vendors for a software quote, prepare a one-page brief covering outcome, users, must-have scope, integrations, acceptance criteria, IP, support and budget; if key questions are still open, start with a paid discovery phase.
By UNIXDEV Team · 5 min read
Original published · English edition
Imagine an organisation that emails three vendors a single line: "we need an online ordering system connected to our ERP". Two weeks later it has three quotes that differ several times over, with different timelines and different scope. Procurement cannot compare them, and management starts wondering who is overcharging.
Usually the problem is not the vendors but the brief. This guide covers what to prepare before asking for a software development quote so that every vendor estimates on the same assumptions and the quotes can be compared. For vetting the vendors themselves, see how to choose a software development company.
Why do software quotes differ so much?
When the brief leaves gaps, each vendor fills them with its own assumptions: one assumes a nightly file export, another a real-time API integration. In Software Development's Cone of Uncertainty, Steve McConnell describes estimates made at the initial-concept stage as potentially wrong by 4x on the high side or 0.25x on the low side, a 16x total range, which narrows as the product definition, requirements and UI design are settled. He also notes that more estimation time does not help: accuracy depends on how well the software is defined, and the only way to reduce variability in the estimate is to reduce variability in the project. The cone is the best case for skilled estimators: it is easy to do worse, and not possible to be more accurate, only luckier. Its figures come from errors observed in skilled estimates, not from any particular project.
What should a brief contain?
The GOV.UK discovery guidance is a useful frame: understand your users and their context, constraints such as legislation, contracts, legacy technology and existing processes, and how you will measure success. A one-page brief should cover ten items:
- Problem and outcome: what is going wrong today and which number should change.
- Users and roles: user groups, approximate numbers and permissions.
- Current process: process map, forms and frequent exceptions.
- Scope: must-haves for the first release and nice-to-haves that can wait, written as user stories ("As a… I need… So that…").
- Integrations and data migration: target systems, available interfaces, direction and frequency, data volume and years to migrate. See legacy modernization for complex sources.
- Non-functional needs: performance, availability, security and personal data.
- Acceptance criteria: "it's done when…" for every must-have, plus who signs off.
- Code ownership and hosting: whose repository, where it runs, who pays for cloud and licences.
- Support after go-live: expected service level, priced as a separate line.
- Budget and timeline: a budget range, truly fixed dates and how much time your team can give each week.
Where something is unknown, write "unknown" so vendors propose how to find out rather than guess.
How detailed should non-functional requirements be?
Make them testable. The ISO/IEC 25010:2023 product quality model, summarised on iso25000.com, is a good checklist: performance maps to time behaviour and capacity, availability to reliability and recoverability, integrations to interoperability. For web applications, reference the OWASP Application Security Verification Standard so every vendor prices security on the same basis. In Thailand, if the vendor will process personal data, say so: a draft data processing agreement (PDPA-DPA-6601), which Thailand's Office of the National Digital Economy and Society Commission uses for its own service contracts, treats the hiring organisation as data controller and the vendor as data processor, attached to the main contract under section 40, paragraph three, of the Personal Data Protection Act B.E. 2562 (2019). This is planning guidance, not legal advice.
Who should define acceptance?
The buyer. Define it before quoting, because acceptance criteria are the vendor's definition of done. The guide published by 18F, a former US GSA digital services team, expects delivered code to be complete, tested, accessible, deployed, documented and secure, and strongly advises against letting the vendor write its own quality surveillance plan. 18F also recommends that all code goes to a buyer-owned repository. Handover details are in our vendor handover checklist.
Fixed price, time and materials, or discovery first?
Fixed price works once scope, integrations and acceptance are clear. Time and materials with a spending ceiling suits work that will be learned along the way; 18F argues it protects public-sector software buyers better than firm fixed price, because invoices must show exact billing data, and notes that US government T&M contracts always require a dollar ceiling. That is US government advice rather than a universal rule. When key questions remain open, buy a short discovery first. GOV.UK says not to start building in discovery, and to expect to throw away any code written in alpha, along with many of the ideas tested. The discovery output then becomes the brief for a narrower, comparable build quote.
Budget for maintenance too. 18F notes that custom software is never "done" and that budgeting maintenance as a separate activity from building is a mistake. See our MA and SLA contract checklist.
A hypothetical example
These figures are invented to illustrate the reasoning; they are not client results or market prices. A fictional distributor sends a one-line brief and receives quotes of 0.8, 2.4 and 4.5 million baht. The vendors assumed, respectively, a web-only system with a nightly file, a real-time ERP API with data migration, and a mobile app with full history migration. After a one-page brief fixes web-first scope, three roles, an existing documented ERP API and migration of active customers only, the new quotes fall between 1.7 and 2.3 million baht and can be compared. Matching quotes mean the vendors now share the same assumptions, not that the final cost is certain: per McConnell, cost can still move until requirements and UI design settle, so keep a contingency or use phased or capped time-and-materials terms. Always ask each vendor to list its assumptions and exclusions.
Start with a clear brief
The best quote is not the cheapest but the one whose assumptions match your real problem. If you cannot yet answer parts of the brief, UNIXDEV's custom software development team can work through the problem, scope and assumptions with you, including a phased discovery. Send us your project brief.