Home Insights Pricing Case study FAQ Contact us
Proposals

Writing a civil engineering proposal takes most of a day. Most of it isn’t scope judgment.

Written by Reco Prianto, P.E., founder of Firma AI and Calichi Design Group.

Every civil engineer who runs a practice knows the technical proposal. It’s not hard. That’s the problem. It’s a long sequence of steps that are each individually reasonable, that have to be done in order, and that eat the better part of a workday for the licensed principal every time a new project comes in.

I run Calichi, a civil engineering firm with four offices across California, Oregon, and Hawaii. Proposals land on every discipline and in every state we practice. After a few years of watching principals spend most of a day on each one, I built an agent to handle the production part. Here’s the honest version of what that workflow is, what it used to take us, and what it takes now.

What a technical proposal actually involves

Start with what the client sends you. A project name, an address, a description of what they want to build, maybe an RFP or a site study attached. Before you write a single scope task, you have to know what jurisdiction the project sits in and what that jurisdiction actually requires. That’s not background reading. It changes the scope.

For a civil engineering engagement, the jurisdiction research covers eight areas: the city or county jurisdiction and which agencies have authority, the building department and its plan check process, the public works department for encroachment permits and improvement standards, the water district and will-serve letter requirements, the sewer or sanitary district and connection requirements, the fire district for fire flow and access, stormwater, and the utility franchise providers for the project’s state.

Stormwater is where proposals most often go wrong, by treating two independent regulatory programs as one. The C.3 Stormwater Control Plan triggers on total impervious area, with a threshold that varies by jurisdiction. Most Bay Area MRP jurisdictions set the Regulated Project threshold at 10,000 square feet of impervious area, but the City of Richmond triggers at 5,000 square feet, and the correct number comes from the jurisdiction’s own C.3 program manual. The SWPPP triggers on one acre of land disturbance under the federal NPDES Construction General Permit, administered by the relevant state agency. They’re independent of each other. A project can trigger one, both, or neither. Conflating them means either excluding a required deliverable from the base scope or including work the client didn’t need.

Then the document class. If the client countersigns this letter, it’s a letter agreement: full execution block, client acceptance at the bottom. If you’re responding to a formal RFP or task order solicitation, it’s an RFP response: an offer submitted for evaluation, no signature block, because the notice to proceed is issued separately by the agency or prime under its own terms. The wrong closing on a formal solicitation reads as amateurish to the reviewing agency.

Then the scope, task by task. For a full civil design engagement, that means seven tasks: Schematic Design, Design Development, Construction Documents, Agency Permitting, Bidding Phase, Construction Administration, and Project Close-Out. Each task carries a narrative, a deliverables list, and a summary deliverable line. Scope terminology adjusts for the jurisdiction and client type: DSA language on a school project, encroachment permit language for city right-of-way work, county improvement standards for county-jurisdicted projects, state DOT language when work touches a state-route.

Then assumptions and exclusions. Assumptions are prose paragraphs, not a bulleted list, because they carry legal weight in the agreement. They cover the stormwater program basis, applicable codes, client-furnished data requirements, and coordination assumptions. CEQA and permit payments belong in Exclusions because they’re genuinely someone else’s scope. Structural, traffic, and specialty engineering belong in Additional Services, so the client sees them as potential add-ons rather than permanent out-of-scope items.

Then the compensation section. You calibrate against comparable project history: what was the scope and compensation on a similar project type, similar site area, similar complexity? You allocate by task, verify the task amounts sum to the grand total, and pair the task table with an hourly schedule for additional services beyond the lump sum scope. The workplan is the internal document that justifies each task: per-subtask hours by role, verified to reconcile against the compensation table within a rounding tolerance. If it doesn’t reconcile, the hour allocations are wrong.

Then the document build. DOCX from the CDG proposal template, never from scratch. Starting from scratch produces formatting failures that are hard to catch until a reviewer opens the file in a different environment: wrong body fonts, missing brand section banners, broken header and footer references, corrupt section properties. The template carries all of that correctly. Then a PDF render. Then Exhibit A, the Standard Provisions, appended verbatim from the canonical reference file. Then QC.

Then the engineer reviews it and decides whether it goes to the client.

What it used to take us

At Calichi, writing a technical proposal, from jurisdiction research through the finished agreement, ran 4 to 6 hours of the principal’s time. That’s our own production-measured result. The same workflow now comes back in 40 minutes.

The frustrating part wasn’t the hard part. Setting the scope, calibrating the compensation against comparable projects, deciding what belongs in base scope versus Additional Services: that requires the licensed principal’s judgment and deserves their time. The frustrating part was everything else. The jurisdiction research done from scratch on every project. The section-by-section assembly. The workplan arithmetic. The template formatting. Same structure, every proposal, done by the most expensive person in the firm.

How the agent does it now

The engineer describes the project the way they’d describe it to a junior: project name, address, project type, which phases to propose, any attachments. From there:

  • It extracts project data from any PDF attachments: RFPs, site studies, prior plan check letters, preliminary plans.
  • It researches the jurisdiction via web search, covering all eight areas. It analyzes the C.3 SCP and the SWPPP separately, pulling the jurisdiction-specific impervious area threshold from the actual C.3 program manual for that jurisdiction, not a generic default.
  • It resolves the correct CDG office address for the project’s state: Hawaii to the Maui office, Oregon and Washington to the Hood River office, all other states to Oakland.
  • It resolves the utility franchise providers for the project’s state and uses those names throughout the scope references.
  • It determines the document class: letter agreement if the client countersigns directly, RFP response if the proposal goes to an agency or prime under a formal solicitation. The closing and signature section branches accordingly. The RFP response omits any execution block because the award decision belongs to the agency.
  • It presents a scope summary to the engineer before generating anything: project, client, document class, jurisdiction, phases, key assumptions and exclusions. It waits for the engineer’s confirmation or corrections before building the document.
  • It builds the scope task by task, calibrates the compensation against comparable CDG project history, allocates by task, and generates the task-by-task lump sum compensation table.
  • It builds the workplan with per-subtask hours by role, verified to reconcile against the compensation table grand total.
  • It builds the DOCX from the CDG Proposal Template, renders the PDF via LibreOffice, and appends the Exhibit A Standard Provisions from the canonical reference file.
  • It logs all externally-sourced values to an audit trail PDF: jurisdiction research, stormwater thresholds, agency names and requirements, each with source, URL, and quoted text.

The QC gate

The agent doesn’t send its first draft to the engineer. Every output runs through a validation gate before a person sees it.

The gate checks five categories of requirements. All five required artifacts must be present: delivery note PDF, proposal DOCX, proposal PDF, workplan XLSX, and audit trail PDF. The CDG template logo must have survived the body swap in the DOCX header, confirmed by reading the raw OOXML: if the header XML has no logo element, the document was built from scratch rather than from the template, and the gate fails. The CDG brand banners must be present on the major sections: project understanding, scope of services, and compensation. No placeholder text can remain anywhere in the DOCX or the workplan. The workplan grand total must reconcile against the DOCX compensation table within rounding tolerance. The gate prints a pass or it doesn’t.

The jurisdiction research and agency requirements are in the audit trail PDF alongside the proposal text. If a reviewer asks where the C.3 impervious area threshold came from, the audit trail has the source, the URL, and the quoted text from the program manual. Contractual documents need traceable inputs.

I built this gate after shipping output without an independent pass and learning that "the engineer will catch it" is not a quality system when the document gets signed. The gate catches the mechanical failures so the engineer’s attention goes to the ones that need judgment.

What stays human

The engineer reviews the scope summary before the document is built. The agent waits. The engineer corrects the scope, adjusts assumptions, or confirms. Then the agent builds. Then the engineer reviews the output before it goes to the client.

The scope decisions are the engineer’s: which tasks to include, what the project actually requires versus what the client thinks it requires, which conditions belong in assumptions. The compensation is the engineer’s: comparable project history is a calibration starting point, not a mandate. The engineer knows this client, this project risk, and this market, and those factors aren’t captured in a project history database. The stamp is the engineer’s.

The agent resolves the jurisdiction, assembles the section structure, builds the document, and checks the output. The licensed engineer owns the scope, the compensation, and the final call. Every proposal that leaves the firm is PE-reviewed.

That division isn’t a disclaimer. It’s the design. The agent handles the production pattern-work. The principal handles the judgment.

Where it applies

Proposals come in on every project type: civil, grading, SWPPP, hydrology and hydraulics, fire flow, construction administration, site due diligence. They repeat on phased projects. They vary by state, by agency type, and by whether you’re responding to a solicitation or engaging a developer directly.

A multi-office firm runs a Hawaii project and a Portland project the same week. The agent resolves the correct office address, the correct jurisdiction, and the utility franchise providers for each one from the project location. Scope terminology adjusts for each: DSA language on a California school, Caltrans encroachment permit language on a state highway project, county improvement standards on a rural site. Document class adjusts: letter agreement on the Hawaii project, RFP response on the Oregon solicitation.

The hardest part of a multi-jurisdiction practice is consistency. Each office develops its own scope habits and its own language, and over time proposals start to reflect whoever wrote them rather than a firm standard. An agent that runs the same research process and the same document structure on every project produces more consistent output than a team where each proposal sounds different.

What this means for your firm

I’m not going to promise a number for your firm. We measured our result at Calichi, on our proposals, with our templates and our project history. Your number depends on how your principals write proposals today, how you calibrate your compensation, and how much of the jurisdiction research is currently done by hand.

The honest way to find it is to measure it on your real workflows.

That’s what the first two gates of how I deploy are for. An AI Readiness Audit to identify where the highest-value automation sits across your operations, then a Strategic AI Discovery that puts my team alongside yours on your actual workflows and produces the time-saved picture by workflow. Every gate is a stop or go. You only go further once you’ve watched the last step work on your own projects.

I built this inside my own firm before I offered it to anyone. Proposal writing was one of the earlier agents, because it was one of the clearest cases of the licensed principal doing production work that didn’t require them.

The first step

Start with an AI Readiness Audit, scoped to firm size ($5K–$12K).

1–2 weeks, scoped to firm size. We map your workflows, identify 5–7 highest-value opportunities, and hand you a written report with hours saved and P&L impact. The audit fee is credited toward deployment if you proceed.

Request an audit →