What to put in a custom enterprise software development RFP
What should a custom enterprise software development RFP include?
A custom enterprise software development RFP needs nine things: business outcomes, an integration inventory with named owners, data volumes and quality, non-functional thresholds, acceptance criteria per slice, migration and cutover expectations, support SLAs, IP and data terms, and a fixed response format.
A custom enterprise software development RFP needs nine things to produce comparable bids: business outcomes, an integration inventory with named owners, data volumes and known quality problems, numeric non-functional thresholds, acceptance criteria per delivery slice, migration and cutover expectations, support SLAs, IP and data-protection terms, and a fixed response format. Everything else is optional.
Most enterprise RFPs fail at the comparison stage rather than the writing stage: six bids arrive with six different scopes and the only comparable number is the total, so the cheapest wins and the change requests start in month two. This article sets out each section, the specific numbers to put in it, and how to score what comes back.
Why most RFPs produce bids you cannot compare
An RFP is a specification for the responses, not just for the software. If it does not say what a response must contain, suppliers will each structure their own, and the differences between them will be presentational rather than substantive.
The second failure is that the risk lives in what the document leaves out. Bidders price what they can see. An RFP silent on integration count, data volumes or environment availability gets optimistic numbers from honest suppliers and deliberately optimistic numbers from the rest. The gap becomes change requests, and the buyer concludes that fixed price does not work when what actually happened is that the scope was never fixed.
The third is asking for effort instead of outcomes. A schedule of day rates by role tells you nothing about whether the supplier can deliver. Ask for a fixed price against a defined scope with named acceptance criteria, and ask how change is priced. The reasoning behind that preference is in what a fixed-price quote should contain.
The nine sections, and what each one prevents
Write each section as statements of fact about your environment, not as questions for the bidder to research.
| Section | What you must state | What it prevents |
|---|---|---|
| Business outcomes | The two or three measures that must move, with today's baseline | Feature lists that nobody can prioritise later |
| Integration inventory | Every system, its owner by name, protocol, and whether a test environment exists | The month-three discovery that half the interfaces are file drops |
| Data profile | Record counts per entity, years of history, known quality problems, who cleanses | A migration priced as a line item and delivered as a crisis |
| Non-functional thresholds | Concurrent users, peak hour, response time target, retention, recovery time | Architecture chosen for a load nobody specified |
| Acceptance criteria | How a slice is accepted, by whom, within how many working days | Acceptance becoming a second requirements exercise |
| Migration and cutover | Number of trial loads expected, parallel-run period, rollback expectation | An unrehearsed go-live with no way back |
| Support and SLAs | Cover hours, response against resolution targets, patching cadence | A build team informally becoming an unpriced helpdesk |
| Commercial and legal | IP ownership, data residency, subprocessors, exit and handover | Discovering at renewal that you do not own the code |
| Response format | Page limits, a mandatory price breakdown table, named team CVs | Six bids that cannot be laid side by side |
The numbers to put in the document
Bidders can only price what is quantified. These eight figures change a quote more than any feature does.
- Interface count and protocol per interface. Say how many are REST, how many are files, and how many belong to a third party with their own release calendar.
- Record volumes per entity and years of history. Two hundred thousand customers with eight years of transactions is a different migration from twenty thousand with two.
- Known data quality problems. Duplicates, missing tax identifiers, dead product codes. Disclosing these gets you a real price; hiding them gets you a change request.
- Concurrent and peak users. Including the month-end or season peak, because that is what the architecture must survive.
- Recovery point and recovery time objectives. These decide the infrastructure bill and belong in the RFP, not in a later architecture review.
- Acceptance turnaround you commit to. If you promise 48 hours, say so; it is a genuine input to the supplier's schedule.
- Freeze windows. Year end, audit season, an academic term or peak trading. A go-live date that lands in one of these is not a date.
- Expected parallel-run period. How long the incumbent stays live alongside the new system, and who does duplicate entry during it.
How to write acceptance criteria bidders can price
Per delivery slice
State the journey, the role that performs it, the record that must exist in the system of record afterwards and the audit entry that must accompany it. A slice is accepted or rejected as a whole. Partial acceptance is how scope disputes begin.
Per interface
For each interface, state the payload, the error behaviour, the retry policy and what the new system does when the other side is unavailable at month end. Interfaces accepted without a failure behaviour are accepted twice: once on the happy path and again in production.
Per migration entity
State the reconciliation rule and who signs it. Financial balances are signed by finance, not by engineering. Specify the number of trial loads you expect and that the mapping document is a deliverable, because it is the artefact your team will maintain for years.
What to ask about price, and what a realistic answer looks like
Ask for a fixed price against the defined scope, a separate line for each interface, a separate line for migration, a named change-request rate, and three years of support priced explicitly. Published Eazyware figures give you a reference point: custom and enterprise software development starts at $24,500 or ₹16,00,000 and runs to $175,000 or about ₹1.2 crore for multi-module platforms, custom ERP and CRM starts at $28,000 or ₹18,40,000, and API and integration work starts at $7,000 or ₹4,40,000. Every starting price is on the pricing page, and an indicative range for your own scope can be built through the estimate tool.
Require support to be quoted as part of the bid rather than agreed after go-live. Care Plans run at $1,000 or ₹68,000 a month for Essential with business-hours cover in IST and an eight-hour response, $2,500 or ₹1,60,000 for Standard with 24x5 cover and a four-hour response, and $5,250 or ₹3,40,000 for Enterprise with 24x7 cover, a one-hour response and a named engineer. Ask bidders to distinguish response from resolution explicitly, a difference set out in SLA response versus resolution and in our maintenance and support page.
Ask one more question that separates suppliers quickly: what would you not build, and why. A bid that proposes buying two of your nine modules from a product vendor is usually the more competent one.
Commercial and legal clauses worth being specific about
State that the client owns the code, the infrastructure configuration, the documentation and, where AI components are involved, the prompts and model choices. Eazyware works this way as standard, and the code and IP ownership definition sets out what that covers. Ambiguity here is only discovered when you want to change supplier, which is the worst moment to find it.
For Indian data, state your obligations under the Digital Personal Data Protection Act 2023 and ask bidders how they meet them. The Ministry of Electronics and Information Technology publishes the data protection framework and the Act itself, which is the document to cite in the RFP rather than a vendor summary of it. Specify data residency, subprocessor disclosure, and what happens to your data at the end of the contract.
When an RFP is the wrong instrument
An RFP works when you know the scope well enough to describe it. If you cannot yet write the integration inventory or state the record volumes, an RFP will simply transfer your uncertainty into the bids as padding, and the supplier who pads least will win and then fight you.
In that case, run a short paid discovery first and use its output as the RFP. Eazyware runs a ten-day Sprint Zero at $3,250 or ₹2,00,000, credited against the build, which produces exactly the artefacts an RFP needs. Equally, if the programme is small, a single module with two interfaces, the RFP process can cost more in everyone's time than the work itself; a scoping conversation through contact is proportionate.
Two clauses are worth adding that buyers often forget. The first is an exit and handover clause: what the supplier must deliver if the relationship ends, including source repositories, environment definitions, runbooks and a handover period. The second is a key-person clause naming the architect and lead engineer, with a right of approval over substitutions. Enterprise programmes are won and lost on two or three individuals, and a bid that will not name them is telling you something.
Scoring what comes back
Weight the evaluation before the bids arrive, and keep price under half the total. Score the integration approach, the migration plan, the acceptance model, the named team and the support proposal separately. A supplier who quotes the migration as a single number and one who breaks it into entities, trial loads and reconciliation sign-off are not offering the same thing, whatever the totals say. Questions to ask a vendor before you sign covers the interview stage that follows shortlisting.
Related reading
The practical implementation guide describes the delivery model an RFP should be asking for, and five ways these projects fail lists the risks your document exists to price.
Write the RFP so that a supplier who reads it carefully cannot produce a cheap number honestly, and the bid you can trust will be obvious.
Frequently asked questions
How long should a custom enterprise software RFP be?
▾
Fifteen to twenty-five pages is usually right, with the integration inventory and data profile as appendices. Length is not the point: an RFP that states record volumes, interface owners and non-functional thresholds in eight pages beats a fifty-page document of aspirational requirements every time.
Should an RFP specify the technology stack?
▾
Only where a genuine constraint exists, such as an approved cloud, an existing identity provider or a database your team already operates. Specifying a stack for preference removes the supplier's ability to propose something cheaper to run, and gives you no protection you did not already have.
How many suppliers should be invited to bid?
▾
Four to six, shortlisted to two for a working session. Beyond six the evaluation effort exceeds the value and good suppliers decline, because the probability-weighted return on a serious bid stops justifying the days it takes to write one properly.