How to Scope a Custom Application Before Asking for Quotes

When a company asks three developers for quotes and gets numbers that differ by a factor of five, the usual conclusion is that developers are unpredictable. The real cause is usually that each one quoted a different imagined project.

Write down the workflow, not the features

Start with the process as it runs today: who does what, in what order, using which spreadsheets and inboxes, and where it breaks. A developer reading a workflow can propose the right tool. A developer reading a feature list can only price your guesses.

Ten questions that shape the price

• Who are the user types, and what should each be allowed to see and do?
• What existing systems must it read from or write to?
• Where does the current data live, and how messy is it honestly?
• What volume are we talking about: records, users, transactions per day?
• What absolutely must be in version one, and what can wait?
• What happens today when the process fails, and what does that cost?
• Are there compliance or privacy rules touching this data?
• Who on your team will own it after launch?
• What does success look like in numbers, six months in?
• What is the budget range you can actually approve?

That last one makes people flinch, but hiding the budget does not produce better quotes. It produces proposals scoped for a project you cannot buy, and a slower path to the version you can.

Smaller version one, always

The single best cost control in custom software is ruthless version one scoping. Build the piece that removes the most painful double entry, get it into real hands, and let actual usage set the roadmap. Software shaped by users beats software shaped by a requirements document written before anyone had touched it.

What a good quote looks like

Plain language description of what will exist, staged delivery, a firm price, and named assumptions. If a quote cannot be explained back to you simply, the project inside it is not clear to the people who wrote it either.