When you need a formal RFP
A formal RFP pays off when the requirement is large, the budget is board-level or several developers compete. It also helps when internal teams (infrastructure, finance, legal, security) must agree on one decision. For a quick start, a one-page requirement is enough for a first call, and many projects begin that way.
Whatever the format, the goal is the same: give developers enough information to propose a real solution, and give yourself a way to compare solutions fairly. Start by choosing the delivery model, since it changes what you ask. Our guide to colocation vs build-to-suit vs powered shell compares the options.
The eleven parts of an RFP
Use the same eleven headings for every respondent.
| Part | What to include |
|---|---|
| 1. Company and purpose | Who you are, what the cluster will run (training, inference, enterprise hosting) and who decides. |
| 2. Capacity requirement | Critical IT load in MW, split into initial and expansion phases, with the ramp by quarter. |
| 3. Timeline | Target energization date, first-rack date and the date after which the project loses value. |
| 4. Market and site criteria | Preferred regions, latency needs, data residency rules and any excluded locations. |
| 5. Delivery model | Build-to-suit, powered shell, hall lease or rack colocation, and your preferred ownership of fit-out. |
| 6. Density and cooling | kW per rack at start and at full build, and the cooling approach you want: air, rear-door or direct liquid. |
| 7. Power and resilience | Redundancy target, A+B feeds, ride-through needs and any energy sourcing requirements. |
| 8. Network | Carrier-neutral needs, cloud on-ramps, number of diverse routes and cross-connect volumes. |
| 9. Security and compliance | Physical security layers, audit rights, certifications you require and incident process expectations. |
| 10. Commercial terms | Term length, price structure you want to compare, expansion rights and exit terms. |
| 11. Response format | What the response must contain, how it is scored, who to send it to and the deadline. |
Write the requirement in numbers
Numbers drive the proposal. Provide these in the first page.
- Critical IT load: the megawatts the racks will draw, not the utility capacity of the building.
- Ramp: megawatts live by quarter, for example the first block and each expansion.
- Density: kW per rack at start and at full build.
- Dates: energization, first rack and full occupancy.
- Redundancy: the target for power and cooling, such as N+1 or 2N.
If you are unsure how many megawatts your cluster needs, work backwards from the rack count and density. Our guide to what 50 MW of AI capacity looks like shows how load turns into halls and rows.
Ten questions to ask every developer
| # | Question | Why it matters |
|---|---|---|
| 1 | What is the energization date, and which steps do you control? | Separates a power plan from a power hope. |
| 2 | What power sources serve the campus on day one and at full build? | Shows whether the plan depends on a single utility step. |
| 3 | How do you handle a failed engine, feeder or battery string? | Tests the redundancy design against your target. |
| 4 | What rack density is the hall built for, and what is the cooling design? | A hall built for air cooling cannot host a dense GPU cluster later. |
| 5 | How do I add the next block, and what is reserved for me? | Expansion rights decide whether growth is guaranteed. |
| 6 | Who designs, who builds and who operates? | One accountable team reduces hand-off gaps. |
| 7 | What is included in the price, and what is metered or passed through? | Lets you compare offers on one basis. |
| 8 | What are the acceptance tests before I take possession? | Commissioning evidence protects your schedule. |
| 9 | What does remote hands cover, and what are the response times? | Operations support shapes cost after go-live. |
| 10 | What are the exit and step-in rights if something goes wrong? | Defines your options before you need them. |
How to score responses
Agree the scoring before the responses arrive. A simple model uses five categories with weights that reflect your priorities.
- Power and schedule: credibility of the energization date and the power sources behind it.
- Technical fit: density, cooling, redundancy and expansion.
- Operations: support model, security and remote hands.
- Commercial: price on a common basis, flexibility and exit.
- Team and delivery: accountable owner, construction partners and references available to share.
Score each category from 1 to 5, write one sentence of evidence per score and review the top two or three respondents in a design session. Power and schedule usually deserve the highest weight for AI workloads, since a late hall costs more than a higher rate.
A realistic timeline
Plan three to four weeks from issue to shortlist.
- Week 0: issue the RFP and hold a Q&A call.
- Weeks 1 to 2: respondents prepare answers; allow site visits where useful.
- Week 3: responses due, scoring and clarifications.
- Week 4: design sessions with the top respondents and shortlist.
A developer with a power plan and a standard hall design can reply faster. PacinfraX replies within two business days to any capacity request, then follows the path below.
What to bring to the first call
Even before the RFP is final, bring five facts to a first call: load, timeline, market, delivery model and cooling approach.
With those, a developer can say which market, block size and power path fit. Read the standards context in the glossary if any term is unfamiliar. For servers already in hand, how to move your servers into colocation covers the steps.
Common RFP mistakes
- Asking for total building power instead of critical IT load. Respondents quote different things, and comparison breaks.
- Fixing the cooling design too early. State the density target and let respondents propose how to reach it. Dense GPU racks usually point to liquid cooling.
- Leaving expansion until after signature. Reserve the next block in the first agreement, with a date and a price basis.
- Scoring only on price. A cheaper hall that energizes six months late costs more than it saves.
- Skipping the design session. Paper answers hide differences that a one-hour review with engineers exposes.
How PacinfraX responds to an RFP
PacinfraX develops and operates power-first AI data center campuses. We respond to an RFP with a named market, a power path, a block size and a hall design from one team. We offer AI data centers in hyperscale blocks of 10 to 50 MW and colocation for smaller GPU deployments, in South ERCOT, Texas, and Vietnam, plus a powered industrial site in Minnesota.
Send your RFP to [email protected] or use Request capacity. We reply within two business days and hold a first call, a design review and a proposal in that order.
RFP questions, answered
How long should an RFP for AI capacity be?
Five to ten pages is enough. Put the load, dates and density up front, and attach technical annexes separately. A short, precise RFP gets better responses than a long, vague one.
Should I send the RFP to many developers?
Send it to three to five developers who can meet your timeline. More than that adds noise. Fewer risks leaving you without a comparison.
What if I do not know my final density yet?
State a range and the date you will decide. Ask each respondent to show how the hall adapts if density rises, for example from air or rear-door cooling to direct liquid cooling.
Can PacinfraX respond to an RFP?
Yes. Send it through Request capacity or to [email protected]. We reply within two business days, then hold a first call and a design review before sending a proposal.
What is the difference between critical IT load and utility power in an RFP?
Critical IT load is the power the racks draw. Utility or total facility power adds cooling and losses, so it is larger. State your requirement as critical IT load and ask each respondent to show how they get from the IT load to the total power the site needs.
Is an RFP required to start a conversation?
No. A one-page requirement is enough for a first call. Use this guide when you want a formal comparison.
Sources and further reading
- TIA-942 data center standard, a common reference for facility design requirements.
- US Department of Energy: data centers and servers, public guidance on energy use and efficiency.
