Solar Design RFP Response Guide: What EPCs Should Ask For (and Provide)

Most solar design RFPs (requests for proposal) fail before a single vendor responds. The document asks for “engineering services” without defining scope, sets a submission deadline with no stated evaluation weighting, and treats price as the only comparable line item. Vendors respond with proposals that are impossible to compare side by side, procurement picks the cheapest one, and the project finds out three months later that the winning bid never included structural calculations.

Direct answer. A solar design RFP should define exact deliverables (PVsyst report, single-line diagram, structural calculations, permit set), specify format and revision terms, state a scored evaluation rubric with weighted criteria, and require references from projects of comparable size and jurisdiction. A strong vendor response mirrors that structure line by line: scope confirmation, a deliverable-by-deliverable breakdown, a firm timeline with named milestones, transparent pricing by phase, and named project references the buyer can call. Procurement teams that skip either half of this end up comparing incomparable bids.

This guide is for the procurement lead or project development manager running a formal RFP process to source a solar design and engineering vendor, whether for a single utility-scale project, an ongoing design panel, or a multi-project framework agreement. It assumes you already know why you are outsourcing engineering. For that decision, see our guides on how to choose a solar design partner and how to choose a solar engineering partner. This article is about the mechanics of the RFP itself: how to write one that produces comparable bids, and how to evaluate what comes back.

Why Solar Design RFPs Produce Bad Comparisons

The core problem is scope ambiguity. Public procurement guidance from the US General Services Administration and standard practice at agencies like NYSERDA treat scope definition as the single highest-leverage step in any RFP, because every downstream evaluation problem traces back to it, according to GSA acquisition policy guidance. When an RFP says “provide engineering design services for a 10 MW ground-mount solar project” without listing deliverables, three vendors will interpret that sentence three different ways.

One vendor prices a bid-stage package: yield report, layout, high-level single-line diagram. Another prices a full IFC (issued-for-construction) package: structural calculations, detailed electrical drawings, BOQ, and a stamped permit set. A third prices somewhere in between. All three numbers land on the same spreadsheet next to each other, and the lowest number wins, even though it represents a fraction of the engineering work the other two bids include.

The difference between bid-stage and IFC-stage scope is not a minor technicality. It changes deliverable count, review cycles, and price by a factor of three to five on a typical project, as covered in our breakdown of bid-stage vs IFC-stage engineering. An RFP that does not specify which stage it is buying cannot produce comparable bids.

Section 1: Scope Definition, What to Ask For

Write the scope section as a deliverable checklist, not a paragraph of prose. At minimum, specify:

• Design stage. Bid-stage (preliminary yield and layout for financial close or auction submission) or IFC-stage (construction-ready drawings and calculations).
• Deliverable list. Name each document: PVsyst or equivalent yield simulation report, general arrangement layout, electrical single-line diagram (SLD), structural calculations and drawings, civil and foundation drawings, bill of quantities (BOQ), permit package (jurisdiction-specific), as-built drawing set if post-construction survey is included.
• File formats. AutoCAD DWG, PDF, editable CAD source files, PVsyst project files (.PAN/.OND if applicable). State whether you need editable source files or final PDFs only. This matters more than it sounds. Some vendors deliver locked PDFs by default and charge extra for source files.
• Revision terms. Number of included revision rounds per deliverable and the turnaround time per revision cycle.
• Applicable codes and standards. For US projects, cite the specific code cycle (NEC 2023, local AHJ amendments). For Indian projects, cite CEA regulations, the relevant DISCOM’s technical requirements, and IS structural codes (IS 875 for wind and seismic loading). Vendors who ask clarifying questions about which code cycle applies are showing you they read the RFP carefully.

Section 2: Evaluation Criteria, Build the Rubric Before You Send the RFP

Public-sector procurement bodies score RFP responses against a published rubric because scoring after the fact invites bias and disputes. The same logic applies to private developer and EPC procurement, even without a regulatory requirement to do so.

A workable weighting for a solar design RFP:

Criterion	Typical weight	What to score
Technical capability	30-35%	Team credentials, software stack, sample deliverables, portfolio relevance
Timeline and delivery track record	20-25%	Stated turnaround, cited on-time delivery rate, revision SLA
Pricing	20-25%	Total cost, cost-per-deliverable, payment terms
References and track record	15-20%	Verified references on comparable projects
Communication and process fit	5-10%	Responsiveness during the RFP process itself, clarity of proposal

Publish this weighting, or at least the criteria list, in the RFP document. Vendors who know what you are scoring write more useful proposals, and you avoid the common failure mode where price ends up as the de facto only criterion because it is the only number everyone can easily compare.

Set a minimum technical threshold that must be met before price is even considered. A common approach: score technical and reference criteria first, disqualify any bid below a stated minimum (for example, 60 out of 100 technical points), then compare pricing only among bids that clear the bar. This stops a technically weak vendor from winning purely on being the cheapest.

Section 3: Deliverable Specs, Getting Specific Enough to Compare Bids

Beyond naming the deliverables, specify the acceptance standard for each one. Examples:

• PVsyst report: state the required loss categories to be itemized (soiling, mismatch, wiring, inverter, availability), whether a P50/P90 exceedance analysis is required, and whether the report must be bankable-grade for lender review. See our guide on bankable PVsyst reports for what lenders actually check.
• Structural calculations: specify the wind and seismic load standard, the design software (STAAD Pro or equivalent), and whether a PE stamp or equivalent local certification is required.
• Permit set: for US projects, specify whether the vendor is responsible for AHJ resubmission cycles if the first submission is rejected, and how many resubmission rounds are included at no extra cost.
• BOQ: specify the level of detail required (item-level quantities with unit pricing references, or quantities only).

A vendor response that answers each of these specs point by point, rather than with a generic “we will provide industry-standard deliverables,” is doing your evaluation work for you.

Section 4: Timeline and SLA Requests

Ask for milestone-level timelines, not a single completion date. A useful format:

1. Kickoff and site data confirmation: within X business days of contract execution
2. Draft deliverable 1 (yield report): X business days
3. Draft deliverable 2 (layout and SLD): X business days
4. Client review and comment period: X business days
5. Final revised package: X business days after comments received
6. Permit or IFC submission-ready package: total elapsed time from kickoff

Ask each vendor to quote their standard revision turnaround as a stated SLA (for example, “revisions returned within 48 business hours”) rather than an open-ended “we will get back to you promptly.” A vendor unwilling to commit to a number is telling you something about how they manage capacity during busy periods.

For US permit-focused scopes, ask vendors to state their historical first-pass AHJ approval rate and their average resubmission turnaround, since AHJ plan set rejections are one of the largest hidden causes of project delay.

Section 5: Pricing Structure, Ask for a Breakdown Not a Lump Sum

Request pricing broken out by phase and, ideally, by deliverable. This does three things: it lets you compare vendors on individual line items rather than one opaque total, it lets you descope items you do not need without renegotiating the whole contract, and it exposes vendors who pad one phase to make their headline number look competitive.

Ask for:

• Fixed price per deliverable phase (bid-stage, IFC-stage, permit set, as-built survey)
• Hourly or per-drawing rate for change orders and out-of-scope revisions
• Payment milestone schedule (percentage due at kickoff, at draft delivery, at final delivery)
• Whether pricing is per-project or per-MW, and how pricing scales for a multi-project framework agreement

Our overview of solar design pricing models covers the tradeoffs between per-project, per-MW, and retainer pricing structures in more depth, which is useful background before you decide which structure to request in the RFP. For the milestone schedule itself, our guide to milestone billing in solar design contracts covers exactly what a deposit, preliminary-design, permit-ready, and as-built milestone schedule should look like, and why payment triggers should never be tied to AHJ or DISCOM approval.

Section 6: Reference Checks That Actually Tell You Something

A reference list of client names and phone numbers is close to worthless if the referenced projects do not match your project’s size, market, or jurisdiction. A vendor with strong references on 200 kW rooftop installs is not a validated source for a 30 MW utility-scale ground-mount design, even if every reference call goes well.

When checking references, ask specifically:

• Was the project comparable in size and jurisdiction to ours?
• Did the vendor hit the milestone dates in the original proposal, or did the timeline slip? By how much?
• How many revision rounds did the deliverables actually take, compared to what was quoted?
• Did the design pass AHJ or DISCOM review on the first submission, or did the project need resubmissions?
• Would you re-engage the same vendor for a project of this scale again?

Call at least two references per shortlisted vendor, and prioritize a reference from within the last 18 months. Engineering teams change, software stacks change, and a five-year-old glowing reference tells you less than a recent one about current capacity and delivery quality.

What a Strong Vendor Response Looks Like

A response that is easy to score mirrors the RFP’s own structure. Look for:

• A scope confirmation section that restates the requested deliverables in the vendor’s own words, flagging anything ambiguous rather than silently assuming an interpretation.
• A deliverable-by-deliverable table, not a narrative paragraph, matched to the RFP’s own list.
• A named project team with credentials (PE license numbers where applicable, years of solar-specific experience, software certifications).
• Sample deliverables or a link to a sample pack, not just a claim of quality. Vendors who cannot show a redacted sample SLD or PVsyst report on request are asking you to take capability on faith.
• A stated timeline with named milestones, matched to the RFP’s requested format.
• Pricing broken out by phase, with payment terms stated explicitly.
• Named references with project details, not just contact information.

A vendor whose proposal ignores the RFP’s requested structure and instead sends a generic capabilities deck is signaling how they will handle project communication later. RFP responsiveness is a leading indicator of engagement responsiveness.

Common RFP Mistakes That Slow Down the Process

No stated budget range. Vendors price blind without a reference point, which produces a wider spread of bids than necessary and wastes both sides’ time on offers that were never going to be in range. A stated range, even a wide one, tightens responses.

No clarifying-question window. A short Q&A period before the submission deadline, with answers shared with all bidders, surfaces scope ambiguity before it turns into incomparable bids. Skipping this step pushes the ambiguity into the proposals themselves.

Evaluating price before technical fit. Reviewing every bid’s price column first anchors the evaluation team, even when a formal rubric exists. Score technical, timeline, and reference criteria first, then bring in pricing.

Treating the RFP as a one-way document. The best RFP responses come from vendors who were allowed to ask questions and, where useful, propose an alternative scope structure with a stated rationale. A rigid RFP that forbids any deviation from the exact requested format can filter out strong vendors who would have delivered better value with a slightly different approach.

How Heaven Designs Responds to RFPs

We treat every RFP as a scoring document, not a negotiation starting point. Our standard response includes a deliverable-by-deliverable breakdown matched to the buyer’s own scope language, named engineering leads with software and certification credentials, a milestone timeline with stated revision SLAs, and phase-level pricing. If your RFP scope is ambiguous on stage (bid vs IFC) or code cycle, we ask before we quote, because a fast wrong answer costs both sides more than a slower right one.

If you are drafting an RFP and want a second set of eyes on the scope section before it goes out, or you want to see what a full deliverable-by-deliverable proposal from us looks like, our team is available through contact us. You can also review sample design deliverables before you finalize your RFP’s deliverable specs, which is useful for calibrating what “complete” should mean in your own scope language.

Conclusion

Building a solar design RFP that produces comparable bids comes down to three disciplines: define scope as a deliverable list with formats and revision terms, publish a weighted evaluation rubric before bids arrive, and check references on projects that actually match your project’s size and jurisdiction. Do those three things and a lowest-price bid stops being able to hide missing scope behind an attractive number.

Next steps for a procurement lead running this process:

1. Rewrite the scope section of your draft RFP as a deliverable checklist before it goes out, using the categories in Section 1 above.
2. Build and publish a weighted scoring rubric with a minimum technical threshold, so pricing only gets compared among bids that already clear a quality bar.
3. Call at least two recent references per shortlisted vendor and ask about actual milestone performance, not just satisfaction.

FAQ

What should a solar design RFP include at a minimum?

A solar design RFP should specify the design stage (bid-stage or IFC-stage), an itemized deliverable list, required file formats, the number of included revision rounds, applicable codes and standards for the project jurisdiction, a stated evaluation rubric, and a submission deadline with a clarifying-question window.

How long should a solar design RFP process take from issue to vendor selection?

For a single mid-size project, a typical timeline runs 3 to 5 weeks: 1 to 2 weeks for vendors to prepare responses after the RFP is issued, 1 week for evaluation and reference checks, and 1 to 2 weeks for contract negotiation. Larger framework agreements or multi-project panels often run longer because more stakeholders are involved in the evaluation.

Should pricing be weighted as the top evaluation criterion?

No. Pricing is best weighted at 20-25% alongside technical capability, timeline, and references. Weighting price above 30-40% tends to select vendors on cost alone and increases the risk of change orders later when missing scope surfaces.

What is the difference between an RFP, an RFQ, and an RFI in solar design procurement?

An RFI (request for information) is used early to gather vendor capability information before scope is finalized. An RFP (request for proposal) is used once scope is defined and asks vendors for a full proposal including approach, timeline, and pricing. An RFQ (request for quotation) is used when scope is already fully specified and price is the primary differentiator, which is less common for solar design services because scope interpretation still varies vendor to vendor.

How many vendors should be invited to bid on a solar design RFP?

Three to five vendors is a workable range. Fewer than three limits price and capability comparison. More than five increases evaluation time disproportionately without meaningfully improving the outcome, since most RFP processes converge on a similar shortlist of qualified vendors regardless of how many were invited.

What reference questions matter most when evaluating a solar design vendor’s RFP response?

Ask whether the referenced project matched your project in size and jurisdiction, whether milestone dates were met, how many revision rounds were actually needed against what was quoted, and whether the design passed AHJ or DISCOM review on first submission. A reference who answers vaguely on timeline performance is a signal worth following up on directly.

Should an RFP require a fixed price or allow hourly billing?

Request fixed pricing per deliverable phase for the core defined scope, with a separate stated hourly or per-drawing rate for change orders and out-of-scope revisions. This combination gives budget certainty on the known scope while keeping a transparent, pre-agreed rate for anything that comes up outside it.