The RFP Machine

What you’re building

It’s Tuesday morning and you just got out of a kickoff meeting for the next build. The mechanical engineer hands you a one-page equipment schedule with six line items — two 2500kW diesel generators, a 480V main switchgear lineup, three 750-ton chillers, a row of CRAHs, a 2MW UPS system, and forty PDUs. Your job: write the RFPs, get them out to vendors by Friday, and start collecting bids.

You already know how this week is going to go. Each RFP takes 3-4 hours when you’re doing it honestly — which means opening the SV8 version, doing find-and-replace on the project name, pretending you’re reviewing the commercial terms even though you haven’t changed them in two years, and then spending an hour re-formatting because Word decided your table borders should be invisible now. Six RFPs. That’s your entire week gone, and you haven’t touched the Denver submittals or the SV8 budget reconciliation that accounting has been emailing you about.

What if you could type the rough specs into a command-line tool and get back a complete, CoreSite-formatted RFP in 30 seconds — delivery terms, insurance requirements, liquidated damages, all of it — while you’re still drinking your first coffee?

That’s what you’re about to build. Twenty minutes from now.

By the end of this lesson you’ll have a Node.js CLI tool that turns your chicken-scratch equipment notes into a complete RFP. The kind that used to take you half a day of copy-pasting from last project’s version while pretending you weren’t. It picks the right equipment template, staples on CoreSite’s standard commercial terms, and spits out a Markdown file ready to convert to PDF or paste into your procurement system.

Who this is actually for

• Construction procurement managers who are writing 2-5 RFPs per month and spending way too much of that time on boilerplate they’ve already written fifteen times. You know who you are. You have a folder called “RFP Templates” with versions dating back to 2019 and you’re not sure which one is current.
• Project managers who need RFPs out the door yesterday because the scope change from last week’s OAC meeting just added three more line items and nobody told procurement until this morning.
• Procurement coordinators juggling multiple simultaneous builds who are basically expected to clone themselves. This tool won’t clone you, but it’ll free up enough hours that leadership might stop asking why you need help.

The showcase

Here’s what you end up with once this thing is running — and yeah, it’s going to feel like cheating:

• Input: Your rough equipment specs, the way you’d actually write them down. "2x 2500kW diesel generators, Tier IV rated, 480/277V, with sub-base fuel tanks, EPA Tier 4 Final compliant"
• Equipment selector: --type generator, --type switchgear, --type chiller, --type crah, --type ups, or --type pdu — picks the right template so you’re not sending vendors a chiller RFP that asks about emissions tiers
• Project context: --project "SV9" and --site "Santa Clara" inject the right details throughout so you don’t have a document that says “DEN3” in the header and “Santa Clara” in the delivery section
• Output sections: Technical requirements, scope of supply, delivery requirements, commercial terms, evaluation criteria, required submittals, insurance and bonding, and response format — all eight sections, fully populated
• Delivery terms: Automatically includes CoreSite’s OFCI standard language — inside delivery, rigging, staging area access windows, crane coordination. All the shit you were going to copy-paste from the SV8 RFP anyway, except now it’s actually consistent
• Output: Clean Markdown file plus a structured JSON summary for tracking

Everything runs locally. Vendor pricing, project codenames, and equipment specs never leave your machine. Your procurement strategy stays yours.

The prompt

Open your terminal, navigate to a project folder, start your AI CLI tool (e.g., by typing claude), and paste this prompt:

Build a Node.js CLI tool called rfp-machine that generates complete RFP documents
for data center MEP equipment procurement. The company is CoreSite, a data center
operator managing OFCI (Owner-Furnished, Contractor-Installed) equipment procurement
across multiple US markets.

PROJECT STRUCTURE:
rfp-machine/
  package.json
  src/
    index.js          (CLI entry point using Commander.js)
    equipment.js      (equipment type definitions and spec templates)
    commercial.js     (standard commercial terms and delivery requirements)
    rfp-builder.js    (document assembly engine)
    formatter.js      (Markdown output formatter)
  templates/
    rfp-base.hbs      (main RFP document template)
    technical.hbs     (technical requirements section)
    commercial.hbs    (commercial terms section)

REQUIREMENTS:

1. CLI INTERFACE (src/index.js)
   - Usage: node src/index.js --type <equipment> --project <name> --site <location> "<specs>"
   - Also accept piped input: echo "specs here" | node src/index.js --type generator --project SV9 --site "Santa Clara"
   - Options:
     --type <generator|switchgear|chiller|crah|ups|pdu> (required)
     --project <project-code> (e.g., "SV9", "CH2", "DEN3")
     --site <location> (e.g., "Santa Clara", "Chicago", "Denver")
     --due <date> (RFP response deadline, default: 3 weeks from today)
     --contact <name> (procurement contact, default: "Noah Salvato")
     --output <path> (output directory, default: ./output)
   - Generate RFP document as Markdown and also a JSON metadata summary
   - Write files to output/<project>-<type>-rfp.md and output/<project>-<type>-rfp.json

2. EQUIPMENT TEMPLATES (src/equipment.js)
   Export equipment type definitions, each containing:

   a. "generator" -- Diesel generators
      - Key spec fields: kW rating, voltage, fuel type, emissions tier, enclosure type,
        sub-base fuel tank capacity, ATS (automatic transfer switch) requirements
      - Typical vendors: Caterpillar, Cummins, MTU, Kohler
      - Special requirements: EPA Tier 4 Final compliance, sound attenuation,
        seismic certification, remote monitoring capability

   b. "switchgear" -- Medium/low voltage switchgear
      - Key spec fields: voltage class, bus rating, interrupting capacity,
        number of sections, metering, relay protection
      - Typical vendors: Eaton, Schneider Electric, ABB, Siemens
      - Special requirements: arc-flash rated, IR window ports, NETA testing

   c. "chiller" -- Water-cooled or air-cooled chillers
      - Key spec fields: tonnage, chiller type (centrifugal, screw), refrigerant,
        efficiency (kW/ton), condenser water temps, redundancy config
      - Typical vendors: Trane, York/Johnson Controls, Carrier, Daikin
      - Special requirements: variable speed drives, low-load operation, BMS integration

   d. "crah" -- Computer Room Air Handlers
      - Key spec fields: cooling capacity (kW), airflow (CFM), coil type,
        fan type (EC vs AC), raised floor vs overhead
      - Typical vendors: Liebert/Vertiv, Stulz, Schneider/APC
      - Special requirements: hot-aisle containment compatibility, variable speed EC fans

   e. "ups" -- Uninterruptible Power Supply
      - Key spec fields: kVA/kW rating, topology (double conversion online),
        battery type, runtime at full load, scalability
      - Typical vendors: Vertiv/Liebert, Eaton, Schneider/APC, Mitsubishi
      - Special requirements: parallel redundancy, unity power factor, remote monitoring

   f. "pdu" -- Power Distribution Units
      - Key spec fields: input voltage/amperage, number of circuits, monitoring
        (per-circuit, per-outlet), form factor (rack mount vs floor mount)
      - Typical vendors: Server Technology, Raritan, Vertiv, CPI
      - Special requirements: SNMP monitoring, color-coded outlets (A/B feed), tool-less mounting

3. COMMERCIAL TERMS (src/commercial.js)
   Standard CoreSite OFCI procurement terms:
   - Payment terms: Net 30 from delivery and acceptance
   - Warranty: minimum 1 year parts and labor from substantial completion
   - Insurance: $2M general liability, $1M auto, $5M umbrella, workers comp per state requirements
   - Liquidated damages: $1,000/day for late delivery (configurable per equipment type)
   - Delivery requirements: inside delivery to final position, rigging included,
     coordinate with GC for crane/staging/elevator access
   - Submittal requirements: shop drawings within 4 weeks of PO, O&M manuals
     at delivery, factory test reports prior to shipment
   - Change order process: written approval required for any scope/cost/schedule changes

4. RFP BUILDER (src/rfp-builder.js)
   Assembles the full RFP document from components:
   - Header: RFP title, project name, site, date issued, response deadline
   - Section 1: Introduction and project overview
   - Section 2: Technical requirements (from equipment template + user specs)
   - Section 3: Scope of supply (what vendor must include)
   - Section 4: Delivery and logistics requirements
   - Section 5: Commercial terms and conditions
   - Section 6: Evaluation criteria (technical compliance 30%, pricing 30%,
     delivery schedule 20%, vendor experience 10%, warranty/support 10%)
   - Section 7: Required submittals and documentation
   - Section 8: Response format and deadline
   - Appendix: Site-specific logistics (dock hours, staging areas, crane access)

5. OUTPUT FORMAT
   - Primary output: Markdown file, suitable for conversion to PDF
   - Secondary output: JSON file with metadata (project, type, date, specs summary,
     estimated value range, key dates)
   - Markdown should use proper headers, tables for spec matrices, and bold for key terms
   - Include a cover page section with CoreSite logo placeholder and RFP number

DEPENDENCIES: commander, handlebars, chalk

SAMPLE RUN:
node src/index.js --type generator --project SV9 --site "Santa Clara" \
  --due "2026-04-15" \
  "2x 2500kW diesel generators, Tier IV rated, 480/277V, with sub-base
   day tanks with connection point for bulk fuel storage, EPA Tier 4 Final compliant, sound
   attenuated enclosures, seismic Zone 4 certified, Caterpillar or approved equal"

Should output a complete RFP document with all 8 sections filled in, the
generator-specific technical requirements populated from the template plus
the user's specs, CoreSite standard commercial terms, and a JSON summary.

What you get

After the LLM finishes (typically 60-90 seconds — less time than it takes to find the right version of last project’s RFP in your folder structure), you’ll have this:

rfp-machine/
  package.json
  src/
    index.js
    equipment.js
    commercial.js
    rfp-builder.js
    formatter.js
  templates/
    rfp-base.hbs
    technical.hbs
    commercial.hbs

That’s it. A complete tool. No Jira ticket, no sprint planning, no “let’s circle back after the holidays.” Just a thing that works.

Fire it up

cd rfp-machine
npm install
node src/index.js --type generator --project SV9 --site "Santa Clara" \
  --due "2026-04-15" \
  "2x 2500kW diesel generators, Tier IV rated, 480/277V, sub-base fuel tanks, EPA Tier 4 Final"

You should see output confirming the RFP was generated, with files landing in output/SV9-generator-rfp.md and output/SV9-generator-rfp.json.

Open that Markdown file. All eight sections — technical requirements populated with generator-specific specs, CoreSite commercial boilerplate, evaluation criteria, response instructions. The whole thing. Thirty seconds ago this didn’t exist, and now it’s more consistent than the one you spent four hours on last month.

If something is off

Don’t panic. These are the most common hiccups, and each one is a quick follow-up prompt away from fixed.

How it works (the 2-minute version)

You don’t need to understand JavaScript to use this tool, but here’s what’s happening under the hood so you’re not just blindly trusting the magic box. We’re glorified logistics coordinators, not wizards — it’s good to know what the machine is doing.

1. Commander.js reads your command-line flags — --type, --project, --site, --due — and the specs text you typed in quotes. Turns all of it into a clean data object. Nothing fancy; it’s just organized input.
2. Equipment templates are the secret weapon. They’re JavaScript objects that know what spec fields matter for each equipment category. The generator template knows about kW ratings, emissions tiers, and ATS requirements. The chiller template knows about tonnage and refrigerant types. This is why your generator RFP won’t accidentally ask about refrigerant compatibility — something that has definitely happened when someone copy-pasted the wrong template at 4pm on a Friday.
3. Commercial terms are a static module with CoreSite’s standard procurement language baked in. Payment terms, insurance minimums, LD rates, submittal timelines — the stuff that basically never changes project to project but somehow still takes you 20 minutes to verify every time because you’re paranoid you missed something. Now it’s in code, and it’s the same every time.
4. The RFP builder takes your rough specs, grabs the right equipment template, staples on the commercial boilerplate, and runs it all through Handlebars templates to produce the final document. All the shit you were going to copy-paste anyway, except now it’s actually consistent.
5. Output is Markdown and JSON. Markdown for humans (convert to PDF, paste into your procurement portal, email to vendors). JSON for machines (feed it into the next tool in this module). Two formats, one command.

Customize it

This is where it gets dangerous — in a good way. You’ve got a working tool. Now you can bolt on features one prompt at a time, and each one makes the tool more useful. No planning meetings required.

Add a multi-equipment batch mode

For those kickoff meetings where you walk out with an entire equipment schedule and need six RFPs by Friday. This is that Friday-saver.

Add a --batch flag that accepts a CSV file path. The CSV should have columns:
type, project, site, specs, due_date. The tool reads each row and generates a
separate RFP for each line item. Print a summary table showing how many RFPs
were generated, which equipment types, and the total estimated value range.
This is for kickoff meetings where you get an entire equipment schedule at once.

Add a vendor distribution list

Because you’re going to send these to actual humans eventually, and keeping track of who got what is its own special hell.

Add a --vendors flag that accepts a comma-separated list of vendor emails.
When provided, append a "Distribution" section to the RFP showing which vendors
received the document, and generate a separate cover-letter.md for each vendor
with personalized greeting and the RFP attached as reference. Also create a
tracking entry in a vendors-log.json file.

Add historical pricing reference

The “stop guessing whether this bid is reasonable” upgrade. Past bids are data. Use them.

Add a --compare flag that checks a pricing-history.json file for previous bids
on the same equipment type. If found, add a "Historical Reference" section to
the RFP showing the price range from past projects (without naming vendors).
This helps you set realistic budget expectations and identify outlier bids later.

Try it yourself

1. Open your CLI tool in an empty folder.
2. Paste the main prompt from above. Go get coffee while it generates. Actually, don’t — it’ll be done before you stand up.
3. Run npm install and test with the sample generator command.
4. Try different equipment types — generate a chiller RFP and a PDU RFP and compare them side by side. Notice how the technical requirements sections are completely different even though you used the same tool. That’s the equipment template doing its job.
5. Now the real test: write specs for a piece of equipment from your actual current procurement log and run it through. See how close it gets to what you would have written manually. Spoiler: it’s close enough that you’ll spend five minutes tweaking instead of four hours writing.
6. Pick one customization from the list above and add it. The batch mode is the most immediately useful if you’ve got a kickoff coming up.

If this saves you two hours on one RFP — and it will — you’ve already made back the 20 minutes you spent building it. Use the extra time to do literally anything else. Go check 203.

Key takeaways

• One prompt, one tool. A detailed, specific prompt produces a working RFP generator in under 2 minutes. You spent more time in that kickoff meeting listening to the mechanical engineer explain things you already knew.
• Equipment templates solve the “wrong copy-paste” problem — every RFP includes the right spec fields for that equipment category. No more generator RFPs asking about refrigerant types because you grabbed the chiller template by mistake.
• Commercial boilerplate is baked in, not remembered — you never forget insurance minimums or LD clauses because they’re in the code, not your head. Your head already has enough in it.
• Markdown output goes everywhere — convert to PDF, paste into your procurement portal, feed into the next tool. It’s a format, not a prison.
• Local-first means your procurement strategy stays private — vendor pricing, project codenames, and equipment specs never leave your machine. Your competitive intel stays yours.

What’s next

You’ve got a machine that builds RFPs. Great. But RFPs go out, and bids come back — and then you’re staring at four PDFs from four different vendors, each one formatted differently, with pricing buried on a different page, and your VP wants a recommendation by Thursday. In the next lesson, you’ll build The Vendor Scorecard — a tool that takes those bid responses, runs them through a weighted scoring engine, and spits out a defensible recommendation memo. No more “I like Caterpillar because I’ve always used Caterpillar” justifications. Actual math. Same pattern — showcase, prompt, output, customize.