A business sends the same brief to four software houses and receives quotes of 800,000, 1,400,000, 2,900,000 and 6,000,000 rupees. The instinct is that somebody is overcharging. Usually nobody is. They have each imagined a different product, because the brief did not describe one.
A good request for proposal is not longer. It is more specific about a smaller number of things.
What must be in it
1. The business problem, not the solution
Start with what is going wrong today and what it costs. “Our three branches keep separate stock records, so we oversell items and lose roughly two hundred thousand rupees a month in cancelled orders.”
That single paragraph tells a competent vendor more than ten pages of feature lists, and it lets them propose something you had not thought of.
2. Who uses it and what each of them does
List every user type and their main tasks. This is the single largest driver of cost, far more than screen count.
“Branch manager: receives stock, transfers to other branches, approves discounts up to ten percent. Cashier: rings up sales, processes returns with manager approval. Owner: sees consolidated figures across branches.” Three roles, clearly bounded.
3. The processes that are specific to you
Every business has two or three workflows that are not standard. Describe those in detail and let the vendor assume the rest is normal.
If your pricing depends on customer category, order volume and a negotiated rate per client, say so. That one sentence can be a third of the build.
4. Integrations, named
List every system this must talk to, by name, and what data moves in each direction. Integration count is the most common reason quotes differ.
5. Volumes and scale
Number of users, transactions per day, products, locations, and expected growth. A system for fifty orders a day and one for five thousand are different builds.
6. What you will provide
Content, data for migration, a decision maker, testing time from your staff. Vendors price differently depending on whether they are also writing your content and cleaning your data.
7. Budget range and timeline
Say the range. Withholding it does not get you a better price; it gets you proposals aimed at the wrong product, and wastes everyone’s time.
What to leave out
- Technology choices, unless you have a real constraint such as an existing team or a compliance requirement. Specifying the stack without a reason narrows your options and signals inexperience.
- Screen by screen descriptions. That is design, and it comes after a vendor is chosen.
- Feature lists copied from competitors. You will pay for features nobody uses.
- “Must be scalable, secure and user friendly.” Every proposal will agree and it distinguishes nothing.
What to ask each vendor to provide
Ask for the same structure from everyone, or you cannot compare.
- Their understanding of the problem, in their own words. This is the most revealing part of any proposal. A vendor who restates your brief has not thought about it.
- Scope broken into phases, with what is in phase one and what is deliberately deferred.
- A cost breakdown by area: discovery, design, build, integrations, testing, deployment, training. A single number tells you nothing and cannot be negotiated sensibly.
- Timeline with milestones and what they need from you at each.
- Assumptions and exclusions. The most useful section in any proposal. Vendors who write none have not thought about risk.
- Post launch support terms and annual cost. See what maintenance actually costs.
- Two references from similar projects, with permission to contact them.
How to compare what comes back
Put the cost breakdowns side by side by area rather than comparing totals. Patterns appear immediately:
- Very low on testing means testing is your problem after launch.
- No line for data migration means it is excluded, and it is never trivial.
- No discovery phase means the first change request will be expensive.
- Integrations priced as one item means they have not counted them.
- A total far below the others is usually a different scope, not a better price. Ask what they assumed.
The three questions to ask in the meeting
- “What part of this worries you most?” An honest vendor names something. A vendor who says nothing is a risk has not read the brief.
- “What would you cut to save thirty percent, and what would we lose?” Tests whether they are thinking about your outcome or their invoice.
- “Show me something you built two years ago that is still running, and tell me what it has cost to maintain.” Anyone can show a launch. Few can show longevity.
Related reading: how to choose a software company in Pakistan and the requirements document checklist.
Frequently asked questions
How long should an RFP be?
Three to eight pages for most business systems. Longer documents are usually padded with generic requirements that add nothing and hide the specific parts that matter.
Should I include my budget?
Yes, as a range. It lets vendors propose something achievable instead of guessing, and it saves you reading proposals for a product you cannot afford.
How many vendors should I approach?
Three to five. More than that and you cannot evaluate the responses properly, and good vendors deprioritise briefs sent to a crowd.
What if I do not know what I need technically?
That is normal and it is fine. Describe the business problem precisely and let vendors propose solutions. Their proposals will teach you what the options are.
Ezitech has responded to hundreds of briefs and scoped 650 or more delivered projects. Send us what you have, even if it is rough, and we will tell you what is missing before you send it elsewhere.