How to scope a software project before you ask anyone for a quote

A common story: a business owner sends the same two-line message to three software companies. “We need an app for our sales team to log visits and orders.” The quotes come back at ₹2 lakh, ₹6 lakh and ₹15 lakh. The owner concludes that software pricing is arbitrary, picks the middle one, and hopes for the best.

Pricing is not arbitrary. Each vendor imagined a different app. One pictured a simple form that emails the office. Another pictured offline support, GPS check-ins and a manager dashboard. The third pictured all of that plus integration with the accounting system, role-based approvals and an iOS version. Each quote was reasonable for what its author had in mind. The problem is that nobody knew what the client had in mind, possibly including the client.

The fix takes an afternoon. Write a short scope before you ask anyone for a price. Here is how.

Start with the problem, not the feature list

Open with one paragraph describing what is going wrong today, in business terms. Not “we need a CRM”. Something like: “Our twelve field salespeople record visits in notebooks and WhatsApp orders to the office, where two people retype them into Tally. Orders get missed, and we cannot see which customers have not been visited in a month.”

That paragraph does more work than any feature list. It tells a vendor who the users are, what the current tools are, where the cost sits (two people retyping) and what “better” looks like (no missed orders, visibility of visit gaps). A good vendor will start asking useful questions from that alone.

List the people who will use it

Write down every type of user and roughly how many there are. For example:

• Field salespeople: 12, Android phones, often in areas with weak signal.
• Office order team: 2, desktop computers.
• Sales manager: 1, wants a weekly view on phone and laptop.
• Owner: 1, wants a monthly summary.

Each user type usually means a separate set of screens and permissions, so this list is one of the biggest drivers of cost. It also surfaces requirements people forget to mention, such as the weak signal, which means the app has to work offline. Offline support adds real effort to a mobile app, because data has to be stored on the phone and reconciled later, so it matters whether a vendor knew about it.

Walk through one real example, step by step

Pick a typical piece of work and describe it from start to finish. “Ravi visits a shop, checks shelf stock, takes an order for 40 cartons across six products, notes that the shop wants a credit extension, and moves on. Today he writes it down and sends a photo of the page to the office WhatsApp group in the evening.”

Then describe what should happen instead. Where should the order go? Who approves the credit request? Does Ravi need to see the shop’s outstanding balance before taking the order? Should the shop get a confirmation message?

Concrete examples flush out the rules that make software complicated. Credit approval is a workflow. Seeing outstanding balance means an integration with your accounts. A confirmation to the shop means messaging, which has a running cost. None of these are visible in “an app to log visits and orders”.

Separate must-haves from nice-to-haves, honestly

Make two lists. Must-haves are the things without which the system is not worth using. Nice-to-haves are everything else. Be strict. If you could live without a feature for the first three months, it belongs in the second list.

This is the single most effective way to control cost. Most first versions are overloaded with features that sound important in a meeting and turn out to be rarely used. A tight first release also launches sooner, and real usage tells you far more about what to build next than any planning session.

When you share the scope, ask vendors to price the must-haves as a first phase and give a rough figure for the nice-to-haves separately. You will see quickly who has understood the difference.

Name the systems it has to talk to

List every existing tool that holds relevant data or needs to receive it: your accounting software (and which version), your website, any CRM, payment gateway, WhatsApp number, spreadsheets that act as unofficial databases. For each, note whether the connection needs to be one-way or two-way, and how fresh the data must be.

Integrations are where estimates most often go wrong, because their difficulty depends on what the other system allows. A modern cloud tool with a documented API is straightforward. An old desktop accounting installation with no API may need a workaround, and sometimes the honest answer is a daily file export. A vendor who quotes confidently for an integration without asking about the other system is guessing.

Say what “done” means

Add a few lines on what a successful launch looks like. “All twelve salespeople log every visit in the app for four consecutive weeks. The office stops retyping orders. The manager can see visits per customer for any date range.”

This gives both sides a shared definition of success, and it is the best protection against the drawn-out ending where a project is “almost finished” for months.

Share constraints and a budget range

Include anything that limits the options: a hard deadline (and why it exists), data that must stay in India, the phones your staff carry, the person on your team who will make decisions and how quickly they can respond.

Many people are reluctant to share a budget, worried that vendors will simply quote up to it. In practice, a range helps more than it hurts. A ₹3 lakh budget and a ₹20 lakh budget lead to different, equally valid approaches to the same problem. Without a range, vendors guess, and you get quotes for three different projects again.

What to expect back

With a one or two page scope like this, good vendors will respond with questions before they respond with a price. That is a positive sign. Their quotes should then show:

• what is included, broken down by module or feature;
• what is explicitly excluded;
• the assumptions they made, especially about integrations and content;
• a timeline with milestones;
• running costs after launch, such as hosting, messaging and support.

If one quote is far lower than the others, read its exclusions and assumptions carefully. The difference is usually there.

For larger or less certain projects, some vendors, ourselves included, will suggest a short paid discovery phase before giving a fixed price. That is not a sales trick. It is a recognition that some questions can only be answered by sitting with your team and looking at real data. A good discovery phase produces a specification you own and can take to anyone.

A template to start from

If you want a starting point, use these headings in a single document: the problem today; users and devices; one real example, now and after; must-haves; nice-to-haves; systems to connect; what done looks like; constraints, deadline and budget range; decision-maker on your side.

Fill in what you can. Gaps are fine and are useful in their own way, because they show you and the vendor where the questions are. You will find that the quotes you get back are closer together, easier to compare and far more likely to hold once the work begins.

Two related reads: what to agree for support after launch, and, if the quotes still look far apart, how an independent technical review can compare them line by line.