Skip to content

What to prepare before asking for a software quotation

A copyable brief that helps a software team understand users, workflows, priorities, constraints, dependencies and how you will accept the work.

Rosaan Ramasamy · 2 min read

In short

Describe the business result, the people doing the work, the current steps and what must change. Add your priority order, existing systems, access or timing constraints, and a few real cases you would use to accept the result. You do not need to prescribe the technology.

You can ask for a quote without having every screen designed. You do need enough information for both sides to understand what is being priced. A list such as “a booking app with reports” leaves too much room for different interpretations.

Copy this brief

Use plain language. If you do not know an answer, write “unknown” rather than guessing.

  1. Business result. What should the work make possible, and why does it matter now?
  2. Users and decisions. Who uses it, who approves exceptions and who accepts the finished work?
  3. Current workflow. What happens today, step by step? Include one normal case and one difficult case.
  4. Requested change. What must work in the first release? What can wait?
  5. Existing systems and data. Name the systems involved, the records they hold and who manages access.
  6. Constraints. Note dates, operating hours, devices, security requirements, vendors and any system that cannot be interrupted.
  7. Acceptance. Give examples your team will use to check the result. State who will decide whether each example passes.
  8. Commercial context. Share a budget range or approval limit if you have one. Say who will make the purchase decision.

If the project includes an existing system, add what you know about its code, hosting, backups and release process. Our takeover checklist helps when those details are scattered.

What a good brief looks like

“Branch staff record service bookings in a shared spreadsheet. Customers message the front desk to change times. We want staff to see available slots and customers to request changes without double booking. Phase one covers two branches and existing customers. The branch manager will approve exceptions. We will test one normal booking, a cancellation and two requests for the last available slot. We still need to confirm whether our POS has an appointment API.”

In a few lines, it tells a supplier who uses the system, what must work first, how the result will be checked, and the one unknown that could change the price. Our Tit Tar Man work covered bookings and branch operations in the same system.

What happens after you send it

A good supplier asks questions before fixing a price. Expect them to inspect a current system, speak to the people who use it or propose a first phase. Ask the supplier to show the included work, exclusions, dependencies, acceptance checks, payment terms, ownership and handover position in the proposal.

If you are still deciding whether to buy or build, start with the buy, configure or build guide. If you already know the direction, this brief gives a Custom Project discussion a practical starting point.

Rosaan Ramasamy

Founder and Managing Director, Antdragon

Rosaan started Antdragon in 2020 to be the team that stays accountable once software goes live, and works with business owners on the systems they rely on every day.

Filed under Planning new software

ShareWhatsAppLinkedIn