Principles
What truths constrain how this product operates?
← Spec · PRD · Performance · Platform · Protocols · Players
The Job
When a construction sales team has 3 weeks to respond to an RFP and half the questions have been answered before, help them find those answers, auto-fill from the library, get SME review, and submit on time — so the team writes once and auto-fills forever.
| Trigger Event | Current Failure | Desired Progress |
|---|---|---|
| RFP lands with 3-week deadline | Copy-paste from old Word docs, hope someone saved the right version | Upload RFP, auto-fill 70% from library, human reviews the rest |
| Monday pipeline review | Chase reps for updates, reconcile spreadsheets, guess pipeline health | One screen shows every deal, stage, value, next action |
| Meeting prep with client | Search email, spreadsheets, memory to reconstruct relationship | Open contact → see company, deals, activity history |
| Follow-up needed after site visit | Mental note, calendar reminder, hope | Tasks linked to deals with due dates, assignees, overdue alerts |
| New project with multiple parties | Relationships in salesperson's head, not the system | Venture page: property + companies + deals + contacts |
The job: "I need to win more bids with less admin. Every bid I write should make the next one easier."
The hidden objection: "I don't want to enter data just so a system can show it back to me." The answer library solves this — answer once, the system learns, and auto-fills next time. The data entry IS the value creation, not the price of admission.
Why This, Why Now
22% win rate (industry average: 20-30%)
3-5 tools per deal (CRM + spreadsheet + email + file share + notebook)
20-40 hours per RFP response (70% copy-paste from previous bids)
0 approved answers in the library (auto-fill returns nothing)
$1,150 estimated value per RFP saved (from analytics page)
The product is 49% live. The demand generation isn't. The win rate doesn't move because the answer library is empty, and the library stays empty because auth is broken. Fix auth → seed library → prove compound → recruit pilot.
The Vertical CRM Thesis
Generic CRMs can be configured for construction. None are designed for it. Configuration tax compounds:
- Every new hire needs custom field setup
- Every report needs field mapping
- Every integration needs configuration
- Industry-specific entities (Property, Venture, multi-company deals) require custom objects
This CRM has these natively. The competitive advantage is not "more features" — it's "less configuration."
Competitive Position
| Capability | Salesforce | HubSpot | Pipedrive | This CRM |
|---|---|---|---|---|
| Contact/Company management | Yes | Yes | Yes | Yes |
| Visual pipeline | Yes | Yes | Yes | Yes |
| Property/site registry | No (custom objects) | No | No | Native |
| Multi-company deals | Yes (complex setup) | Limited | No | Native |
| RFP/tender workflow | No (add-on) | No | No | Native |
| AI answer auto-fill | No | No | No | Native |
| Go/No-Go scoring | No | No | No | Planned |
| Construction-aware stages | Custom config | Custom config | Custom config | Default |
| Price per seat/month | $75-300 | $0-150 | $15-100 | Target: $30-80 |
The gap: Generic CRMs can be configured for construction. None are designed for it. The compound rate of the answer library creates a moat that configuration can't replicate.
Context
- Construction Industry — Domain context
- Solar Industry — Parallel vertical with RFP-driven sales
- Vertical SaaS — The vertical software playbook
- Jobs To Be Done — Demand-side thinking
- CRM Software — Generic CRM feature baseline