What to have ready before you ask for a software quote

Most software estimates go wrong before anyone writes a line of code. The developer guesses at the parts nobody mentioned, the guesses turn out wrong, and the project grows. The fix isn’t a hundred-page specification. It’s an hour of preparation on your side, so the first conversation covers what actually matters.

Here’s what we find most useful when someone asks us for a quote. You don’t need all of it, and none of it needs to be polished. Notes and screenshots are fine.

1. The problem, in your own words

Start with what’s wrong, not with the solution. “We need an app” is hard to estimate. “Our staff spend hours every week typing online orders into our inventory system, and mistakes slip through” tells a developer what success looks like, and leaves room for a simpler fix than the one you had in mind.

If you can, put a rough number on it: hours per week, orders per day, calls you can’t return. That number makes it much easier to judge whether a project is worth doing at all.

2. Who will use it, and where

List the people who will touch the software: staff, managers, customers, partners. Roughly how many of each? Are they at a desk, on a phone in a warehouse, or on a tablet at a customer’s house? A tool for five office staff and an app for five thousand customers are very different projects, even when they do similar things.

3. How the work happens today

Walk through the current process step by step, including the workarounds. The spreadsheet someone keeps on the side, the sticky notes, the weekly export: those are often where the real requirements hide.

Screenshots of the tools you use now, and samples of the forms, invoices or reports involved, are worth more than a long description. Remove anything confidential first.

4. The systems it needs to connect to

Make a list of the software the new tool will need to work with: your point-of-sale, accounting, payments, email, scheduling, website. Include the vendor names, and your plan level if you know it.

This matters more than people expect. When we built a warehouse routing platform for a multi-store retailer, connecting to their Revel point-of-sale system was central to the whole project. Whether a system has an API, and what it allows, can change an estimate more than any feature on your wish list. (Read the case study.)

5. What “done” looks like

Split your ideas into two lists:

• Must-haves: the things that solve the problem in section 1. Without them, the project isn’t worth doing.
• Nice-to-haves: the things that would be great later.

A first version built around the must-haves gets you value sooner, costs less and teaches you what the second version should be. Most good software is built this way.

6. Your timeline, and what’s driving it

Is there a real deadline, like a busy season, a contract start, an event or a system being retired? Or is it “as soon as reasonably possible”? Both are fine. Knowing which one helps a developer plan the work and tell you early if a date isn’t realistic.

7. A budget range

This is the one people are most reluctant to share, but it’s one of the most useful. A range isn’t a commitment, and a good developer won’t treat it as a target to spend up to. It tells them which approaches are worth proposing. The same problem can often be solved with a small integration, a focused internal tool or a full platform, at very different prices.

If you have no idea what’s realistic, say so. That’s a perfectly good starting point.

8. Who decides, and who will be involved day to day

Who signs off on the project, and who will answer questions and test the software as it’s built? On many projects these are different people. Having the day-to-day contact in the first conversation saves a lot of back-and-forth later.

9. Your data

What information will the software use, and where does it live today? Roughly how much is there? Does it include anything sensitive, like customer details, payment information or health records? Sensitive data shapes how a system is built and hosted, so it’s better to raise it at the start.

10. Life after launch

Think about who will look after the software once it’s live. Do you have someone in-house, or will you want the developer to host, maintain and improve it? Who should own the code? There’s no wrong answer, but deciding early avoids surprises.

What you don’t need

You don’t need a full specification, wireframes or technical vocabulary, and you don’t need to pick the technology. That’s the developer’s job. If a conversation leaves you feeling you should have arrived with a technical document, that’s a sign the developer isn’t doing the listening.

A checklist you can copy

• The problem, with a rough number on it
• Who will use it, how many, and on what devices
• How the work happens today, with screenshots and sample documents
• The systems it needs to connect to
• Must-haves and nice-to-haves
• Timeline, and what’s driving it
• A budget range, or “not sure yet”
• Who decides, and who’s the day-to-day contact
• What data is involved, and whether any of it is sensitive
• Who will look after it after launch

What happens next with us

When you get in touch, we read every inquiry and reply within two business days. We start with a short call about the problem, and then send you a written scope and estimate before any work begins, so you know exactly what you’re getting and what it costs.

---

Have some of this ready already? Tell us about your project. Our contact form asks for the essentials, and anything you leave out, we’ll cover together on the first call.