Synthesized research outputs from 4 parallel researcher agents: - STACK.md: 7 new npm packages (dnd-kit, TanStack Table, RHF, BullMQ), React 19 compat verified - FEATURES_v2.0.md: Feature landscape (table stakes, differentiators, anti-features), MVP breakdown - ARCHITECTURE.md: Schema additions (services, offer_phases, leads, quotes), 5-phase build order - PITFALLS.md: Critical/moderate/minor pitfalls + prevention strategies Ready for roadmap planning and phase-by-phase execution. Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
30 KiB
Feature Landscape: Business Operations Suite v2.0 (New Features)
Domain: Proposal generation + lightweight CRM for solo personal-branding consultant
Researched: 2026-06-10
Research Mode: Ecosystem (proposal software + lightweight CRM patterns)
Confidence: MEDIUM-HIGH
Scope: ONLY new v2.0 features (does NOT review v1.0 table stakes already shipped)
Executive Summary
The Business Operations Suite adds three interconnected workflows to ClientHub:
- Proposal Generation & Delivery — Sales call → multistep proposal page (2-hour delivery) → lead selects tier A/B/C → acceptance triggers automation
- Lead Pipeline Management — Minimal CRM for tracking prospects through 5 stages (Contacted → Qualified → Proposal Sent → Negotiating → Won/Lost)
- Onboarding Automation — When lead is marked Won, auto-create client + project with phases copied from chosen offer + configurable payment schedule
For a solo consultant, this is radically different from team CRMs (Pipedrive, HubSpot, GoHighLevel). Avoid: territory management, team routing, email automation, role-based access, forecasting rollups, lead scoring algorithms. Instead: minimal data entry, follow-up reminders based on last-contact date, and seamless handoff from proposal acceptance to project setup.
Core insight: Solo consultants manage long-term relationships across years, not one-time deals closed in 30 days. Pipeline stages should reflect relationship milestones (Contacted, Qualified, Proposal Sent), not sales rep activity (Attempted, Left Message). Follow-ups are "who did I talk to recently?" not "assign task to rep."
Table Stakes Features (New v2.0)
Features users expect when adopting a proposal + CRM system. Missing these = product feels incomplete.
Proposal Generation & Delivery
| Feature | Why Expected | Complexity | Notes |
|---|---|---|---|
| Pick client + 1–3 offers, set per-quote prices | Core value: sales call → proposal in 2 hours. Prices set per quote, not from catalog (allows price increases over time without updating service catalog) | Medium | Depends on existing offers & clients (Phase 5). Quote prices override offer base prices. |
| Generate public multistep HTML/CSS page | Leads need clickable link, not PDF email. Interactive engagement beats static documents (Qwilr/Proposify standard). Reduces abandonment. | Medium | Responsive, mobile-first, branded with consultant name/logo. No login required. |
| Multistep flow (intro → pricing tiers → CTA) | Reduces cognitive overload vs. single long page. Step 1: offer overview. Step 2: A/B/C tiers with pricing. Step 3: accept/decline button. | Low | Conditional logic hides irrelevant sections; simple progressive disclosure. |
| Public acceptance button (no e-signature) | Lead confirms tier choice WITHOUT entering hub. Triggers: timestamp capture + email record + lead status update. | Low | Simple "Accept this offer" button → records accepted_at + accepted_by_email. E-signature deferred (design ready, v1 constraint). |
| Proposal URL shareable & public | Lead receives link in email, opens in browser, no friction. | Low | Generate unique slug (/proposal/[uuid]). No auth. Optionally expires after N days or on acceptance. |
| Acceptance proof (signer + timestamp) | Documentation for dispute resolution. Downloadable PDF or stored audit record. | Low | Store: accepted_by_name, accepted_by_email, accepted_at, accepted_offer_id. |
Lead Pipeline
| Feature | Why Expected | Complexity | Notes |
|---|---|---|---|
| Pipeline stages: Contacted → Qualified → Proposal Sent → Negotiating → Won/Lost | Core tracking. Each stage requires buyer action, not just rep activity. Termination: Won or Lost. | Low | Minimal for solo: 5 stages max. More = data entry overhead. Stages are immutable enums. |
| Move lead between stages (UI) | Basic pipeline UX. See all leads grouped by stage at a glance. | Low | Dropdown per row (simple) or kanban board (polish). Dropdown sufficient for MVP. |
| Lead details: name, email, company, phone, last_contact_date, next_action, notes | Minimum context for follow-ups. | Low | Notes = freeform text (call outcomes, concerns, personality notes, next steps). |
| Lead created manually OR auto-created from proposal send | Manual: import prospects. Auto-create: when proposal sent to unknown email, create lead record automatically. | Low | Auto-create is convenience; manual is fallback. Both supported. |
| Log activities: calls, emails, meetings, notes | Track interactions without leaving dashboard. Auto-updates last_contact_date. | Low | Activity types: [call, email, meeting, note]. Log date, duration, description. Displayed as feed. |
Follow-Up Reminders
| Feature | Why Expected | Complexity | Notes |
|---|---|---|---|
| Dashboard widget: "Follow up today" sorted by last_contact_date | Solves core pain: "who did I talk to recently that I should check in with?" | Low | Query: WHERE last_contact_date <= TODAY - 7 days AND stage NOT IN (Won, Lost). Red badge. |
| Proposal stall detector: if Proposal Sent >3 days, no response | Flags silence = red flag for follow-up. | Low | Simple dashboard alert; no email automation (consultant checks dashboard in morning). |
| Auto-update last_contact_date on activity | Keeps reminders accurate. Prevents "I called them but forgot to log it" drift. | Low | Trigger: on call/email/meeting/note creation OR stage change → update lead.last_contact_date = NOW. |
Project Auto-Creation (Won → Onboarding)
| Feature | Why Expected | Complexity | Notes |
|---|---|---|---|
On lead.stage = Won: auto-create client + project with copied phases |
Closing automation. Proposal acceptance → instant hub readiness for delivery. | Medium | Requires: chosen offer known, project_offers finalized (Phase 5), 1-4 configurable installments. |
| Copy offer phases → project phases (modifiable) | Project inherits offer structure but can be customized per client without mutating offer template. | Medium | Phases are modifiable in hub (Phase 1). Creation source logged: "Copied from Offer X on [date]" for audit. |
| Set payment installments per project (not per offer) | Payment plan configured case-by-case: some 50/50, others 4-part. Allows flexibility. | Medium | Templates: 50/50 (acconto/saldo), 3-part, 4-part, custom. UI: choose template during Won → project creation. |
| Lead → Client transition: copy email, create token, link to existing client if repeat | Avoid duplicate clients. Allow linking Won lead to existing client (repeat engagement). | Medium | Check email collision. If exists: "Add project to existing client X?" vs. "Create new client". Generate secret token. |
Differentiators (New v2.0)
Features that set ClientHub apart from generic proposal software + CRM. Not expected, but valued for solo consultant use case.
| Feature | Value Proposition | Complexity | Notes |
|---|---|---|---|
| Tier-independent offer structure (Signature A/B/C as separate offers) | Each tier has own URL, phases, pricing. A = professional, B = budget—same catalog, different scope. No cloning, no inheritance logic. | Medium | Requires flexible offer builder (drag services between phases), offer status (draft/active/archived). Built in Phase 5. |
| Proposal phases visible in public page (lead sees what they're buying) | Lead sees not just price, but scope: "4-week branding sprint, 3 revision rounds, monthly retainer". Transparency builds confidence. | Low | Proposal page shows phase names, deliverables summary (text), timeline (start + duration). |
| Dashboard follow-up list filterable by offer type + stage | "Show all Signature A leads in Negotiating" to spot bottlenecks by tier. | Low | Filter buttons: by offer type, stage, last_contact_date range. Dropdown or toggle buttons. |
| Activity feed per lead (call notes, email log, meetings, searchable) | Context without leaving dashboard. "Last contact: 2026-05-28, 11am call—timeline concerns". | Medium | Depends on activity logging system. Store type, date, duration, description. Searchable. |
| Proposal pages branded with consultant info (not generic SaaS) | Proposal is part of sales process; branding reinforces personal brand. | Low | Logo, consultant name, brand colors, professional typography inherited from admin settings. |
| Email integration hint (design ready, defer to later batch) | Send proposal via dashboard; auto-log email send as activity. | Medium | Deferred per PROJECT.md (v1 constraint). Placeholder: manual copy-paste OK for MVP. |
Anti-Features: What NOT to Build (v2.0)
| Anti-Feature | Why Avoid | What to Do Instead |
|---|---|---|
| Multi-user team collaboration, role-based access | Solo consultant is single admin. Team features add auth complexity, sync issues, notification storms. Overhead >> value. | Stay single-admin. Architecture with permission flags but don't build UI/logic. If team joins later, migrate incrementally. |
| CRM email automation, drip campaigns, email sequences | Solo consultant sends proposals + checks in manually. Automation-heavy workflows are for outbound prospecting funnels (not this use case). Lead generation not in scope. | Keep simple: dashboard reminder = "check in with X". Consultant sends email manually, logs it as activity. |
| Forecasting with rollups, quota tracking, team capacity planning, territory assignment | These are team sales metrics. Solo consultant cares: "How many leads in pipeline?" and "What's revenue if all Negotiating deals close?" | Simple dashboard: shows total value by stage (e.g., "Negotiating: $45k"), breakdown by offer type. No forecast math. |
| Lead scoring, MQL → SQL qualification algorithms, scoring rules | Solo consultant qualifies leads manually (call + gut feel). Scoring requires training data and tuning. | Keep manual: stage = Contacted, Qualified, Proposal Sent. "Qualified" is consultant's call. No automation. |
| Calendar sync, email sync, call recording, Slack/Teams integration | Adds external dependency surface area. Consultant logs calls + emails manually. | Fallback: freeform "Call notes" text field per activity. No attempt to auto-log from email/Slack. |
| Multi-currency support, tax calculation, invoice generation, accounting system integration | Accounting is out of scope (PROJECT.md locked). Payment tracking only. | Keep simple: amount_accepted in EUR, payment schedule in local currency. No conversion logic or invoicing. |
| Proposal version control, edit history, detailed audit trail | Overkill for solo consultant. One proposal per client, accept or decline. | Simple: created_at, updated_at timestamps. Accepted version is locked (immutable once accepted_at set). No versioning. |
| Client can reverse/un-approve acceptance | Creates ambiguity in closing. | Once accepted_at is set, proposal is final. Consultant can move lead back to Proposal Sent if needed. |
Feature Dependencies (v2.0)
Proposal Generation:
├─ clients (exists, Phase 1)
├─ projects (exists, Phase 1)
├─ offers (Phase 5: id, name, offer_type [Entry/Signature/Retainer/custom], created_at)
├─ services catalog (Phase 3: id, name, price, duration_days)
└─ offer_services (Phase 5: junction table, offers ↔ services)
Lead Pipeline & CRM:
├─ leads table (NEW: id, name, email, company, phone, created_at, last_contact_date, stage, offer_id FK, next_action text)
├─ activities table (NEW: id, lead_id FK, type enum [call/email/meeting/note], log_date, description, duration_minutes)
├─ lead_stage enum (NEW: Contacted, Qualified, Proposal Sent, Negotiating, Won, Lost)
Project Auto-Creation (Won → Onboarding):
├─ leads.stage = Won (from pipeline, not auto-set)
├─ projects (exists, must be creatable via API/trigger)
├─ phases (exists, must be copyable from offer phases)
├─ payments (Phase 5: must support project_id FK, amount, due_date, status)
└─ clients.token (exists, Phase 1/4: rotatable secret)
Proposal Public Pages:
└─ proposals table (NEW: id, client_id, lead_email, offers [JSON array], created_at, public_url, accepted_at, accepted_by_name, accepted_by_email, accepted_offer_id)
Critical dependency: Phase 5's project_offers relationship must be finalized. If not, proposal generation cannot proceed. Phase 7 proposal work is blocked by Phase 5 completion.
Feature Categorization by Component
Component 1: Proposal Builder & Public Pages
Responsibility:
- Admin UI: select client, pick 1–3 offers, confirm per-quote pricing, set lead email, generate shareable link
- Public page: multistep form (intro → tiers → CTA), responsive, no login, branded
- Acceptance: simple "Accept" button, no e-signature
- Database:
proposalstable
Features in scope:
- Proposal generation from client + offers + prices
- Public multistep page with interactive tier selection
- Conditional phase visibility (show/hide sections based on tier)
- Acceptance button + timestamp + email capture
- Auto-create lead on proposal send (if lead email not in DB)
- Proposal expiry (optional, default: never)
Database schema:
proposals:
id UUID PK
client_id FK → clients
lead_email VARCHAR (recipient)
offer_ids JSON array (which offers are included)
quote_prices JSON {offer_id: price} (per-quote override)
created_at timestamp
updated_at timestamp
public_url slug
accepted_at timestamp nullable
accepted_by_name VARCHAR nullable
accepted_by_email VARCHAR nullable
accepted_offer_id FK nullable (which tier was chosen)
Component 2: Lead Pipeline & Dashboard
Responsibility:
- Lead table with name, email, company, stage, last_contact_date, notes
- Dashboard: table or kanban view of all leads grouped by stage
- Activities: log calls, emails, meetings, notes
- Follow-up reminder widget: leads not contacted in 7+ days
Features in scope:
- Create/edit/delete leads manually or auto-create from proposal
- Move lead between stages (dropdown or drag/drop)
- Log activities: type [call/email/meeting/note], duration, description
- Auto-update last_contact_date on activity
- Follow-up reminders: "Follow up today" widget, proposal stall detector
- Lead notes: freeform text, searchable
- Filter by offer type, stage, date range
- Activity feed per lead (searchable)
Database schema:
leads:
id UUID PK
name VARCHAR
email VARCHAR (unique or indexed)
company VARCHAR nullable
phone VARCHAR nullable
stage enum [Contacted, Qualified, Proposal Sent, Negotiating, Won, Lost]
offer_id FK → offers nullable (which offer was sent)
created_at timestamp
last_contact_date date
next_action text nullable (next step consultant plans)
notes text (accumulated call notes, concerns, personality)
activities:
id UUID PK
lead_id FK → leads
type enum [call, email, meeting, note]
log_date timestamp
duration_minutes INT nullable
description text
created_at timestamp
Component 3: Project Auto-Creation & Onboarding Flow
Responsibility:
- On lead.stage = Won, trigger creation: new client (if not exists), new project, copy phases, set payment schedule
- UI: lead moves to Won → modal: "Which offer was chosen?" → "Confirm project creation?" → choose payment template → create
- Result: lead archived, project appears in /admin/projects, client gets dashboard URL
Features in scope:
- Auto-create client from lead details
- Auto-create project with copied phases
- Copy phases from offer (modifiable in hub)
- Payment installments: choose template → creates N payment records
- Generate client secret token + dashboard URL
- Optional: link to existing client instead of creating new
- Notification: "Lead X → Project Y created on [date]"
Database schema:
No new tables needed. Uses existing: clients, projects, phases, payments.
When lead → Won:
1. Check if lead.email in clients table
2. If not: create new client, generate secret token
3. If yes: ask to link to existing client or create new
4. Copy phases from offer_id to new project
5. Create N payment records based on chosen template
6. Update lead.stage = Won (already set by UI)
7. Record: project creation_source = "Lead X, offer Y"
MVP Recommendation
Phase 7 (MVP): Core Proposal Generation + Basic Pipeline
Priority 1: Must-Have (Launch features)
- Proposal builder UI: client + offer(s) + per-quote prices → generate public multistep page
- Public proposal page: Step 1 = offer overview, Step 2 = A/B/C tiers + pricing, Step 3 = "Accept this Offer" CTA
- Acceptance flow: "Accept" button → timestamp + email capture, marks proposal as accepted
- Lead auto-creation: when proposal sent to unknown email, auto-create lead record
- Basic lead pipeline: Contacted, Qualified, Proposal Sent, Negotiating, Won, Lost stages
- Lead dashboard: table view, move stage via dropdown, lead details sidebar
- Follow-up reminder widget: leads not contacted in 7+ days, sorted by last_contact_date, dashboard badge
- Activity logging (basic): create call/email/meeting records, auto-update last_contact_date
Estimated effort: 5–7 days (proposal builder UI + public page + lead CRUD + follow-up reminders)
Launch readiness: Solo consultant can generate proposal in 2 hours, track lead through pipeline, see follow-up reminders.
Phase 8 (Enrichment): Lead Context & Polish
Priority 2: Features
- Lead notes: freeform text per lead, searchable
- Activity feed: display recent activities per lead (call, email, meeting, note), searchable
- Dashboard filters: by offer type, stage, date range (last_contact_date)
- Proposal stall detector: flag if Proposal Sent >3 days with no activity
- Lead detail card: expand to show full context (notes, activities, next_action) without leaving dashboard
Estimated effort: 3–4 days
Value: Consultant has full context for each lead without switching views.
Phase 9+ (Automation & Onboarding): Project Auto-Creation
Priority 3: Features
- Project auto-creation: on lead → Won, auto-create client + project with copied phases
- Copy phases from offer: phases inherit name, duration, deliverables from offer template; modifiable in hub
- Payment installments: choose template (50/50, 3-part, 4-part, custom) → create N payment records
- Client token generation: auto-generate secret token, send dashboard URL to client
- Duplicate client check: if lead.email exists in clients, ask to link or create new
- Won lead notification: dashboard shows "Lead X → Project Y created", activity logged
Estimated effort: 3–4 days
Value: Closing automation. Lead acceptance → instant project setup in hub, ready for delivery.
Complexity Assessment (Effort & Maintenance)
| Feature | Dev Effort | Maintenance Burden | Deferability | Phase |
|---|---|---|---|---|
| Proposal generation (builder UI + logic) | 2–3 days | Low (static) | No—core | 7 |
| Public multistep page (HTML/CSS template) | 1–2 days | Low (static) | No—core | 7 |
| Acceptance flow (button + timestamp) | 1 day | Minimal | No—core | 7 |
| Lead pipeline (CRUD + stage transitions) | 1 day | Low | No—core | 7 |
| Follow-up reminders (dashboard query) | 4 hours | Minimal | No—core | 7 |
| Activity logging (calls, emails, meetings) | 1 day | Low | Yes—Phase 8 | 8 |
| Activity feed (search + timeline) | 1 day | Low | Yes—Phase 8 | 8 |
| Lead notes + search | 1 day | Low | Yes—Phase 8 | 8 |
| Dashboard filters (offer type, stage, date) | 1 day | Low | Yes—Phase 8 | 8 |
| Project auto-creation (trigger + cascade) | 2 days | Medium (error handling) | Yes—Phase 9 | 9 |
| Payment installments (templates) | 1 day | Low | Yes—Phase 9 | 9 |
| Client token generation + link | 4 hours | Low | Yes—Phase 9 | 9 |
| Duplicate client check | 4 hours | Low | Yes—Phase 9 | 9 |
| Email integration (send proposal, auto-log) | 2–3 days | Medium (provider) | Yes—defer | Later |
| Multi-user + team features | 3–5 days | Medium-High (roles) | N/A—anti-feature | Never |
Total Phase 7 MVP: ~5–6 days
Total Phases 7–9: ~11–14 days (complete suite)
Solo Consultant Design Constraints
What's Different from Team CRMs
| Constraint | Implication | Design Pattern |
|---|---|---|
| Single admin, no team routing | No "assign to rep" or "owner" field. All leads = Simone. | All leads belong to admin; no ownership concept. No role-based UI. |
| Relationship-heavy, not transaction-heavy | Leads stay in pipeline for months, not 30 days. | Stage = relationship milestone (Contacted, Qualified, Proposal Sent), not rep activity (Attempted, Left Message, Following Up). |
| Qualitative follow-up, not automation | "Check in with X, heard timeline concerns" not email sequences. | Notes + activity log, no email automation. Manual send, logged as activity. |
| Low deal volume (5–15 in flight) | Pipeline visualization doesn't need advanced analytics. | Simple table or 5-column kanban board. No forecasting rollups. |
| Minimal data entry tolerance | Won't log every call if it takes >3 clicks. | Modal: "Log call → name/date/notes → save" in <10 seconds. |
| No role-based access | No "manager sees forecast, rep sees pipeline". | Single "admin dashboard" with all data. No permission layers. |
| No forecasting pressure | Consultant forecasts deal value by feel, not rollup math. | Dashboard shows "Total Negotiating: $45k". That's it. No probability weighting. |
| Calendar/email often offline (field work) | Email sync is nice-to-have, not must-have. | Fallback: manual entry. No real-time sync requirement. |
| Accountability is personal, not hierarchical | No "why is this deal stalled?" escalations. | Follow-up reminder = consultant decides action. No automatic escalations. |
UX Patterns for Solo Consultant
- Minimize data entry by default: Yes/No confirmations, checkboxes, dropdowns. Avoid text fields unless essential.
- Context visible by default: Open a lead → see last 3 activities, next_action, stage, offer type in one view. No tabs.
- Dashboard as command center: Lead reminders + upcoming payments + next meetings all visible. No app switching.
- Proposal as shared artifact: Lead sees what they're buying (phases, deliverables, price). Consultant sees acceptance status + lead email.
- Automation where it reduces clicks: Accept proposal → auto-create lead. Move to Won → ask once for payment plan, auto-create project. Don't auto-email.
Pipeline Benchmark (Reference)
From industry research:
| Metric | Benchmark | Implication for ClientHub |
|---|---|---|
| Typical pipeline stages | 5–7 stages | ClientHub uses 5: Contacted, Qualified, Proposal Sent, Negotiating, Won/Lost. Minimal overhead. |
| Proposal Sent → Negotiation conversion | 40%+ | Flag stale proposals (>3 days, no activity) in dashboard. |
| Negotiation → Won conversion | 50%+ | If low, consultant reviews proposal scope or pricing. |
| Lead follow-up frequency | 8+ touches to close | Activity logging tracks touches (calls, emails, meetings). No automation; manual follow-up. |
| Typical pipeline review cadence | Weekly or bi-weekly | Consultant checks dashboard daily; reviews pipeline health weekly. |
| Average deal cycle for consultants | 30–90 days | ClientHub supports long cycles (no pressure to close fast). |
Confidence & Sources
| Area | Confidence | Basis | Sources |
|---|---|---|---|
| Proposal software features (multistep, acceptance, tiering) | HIGH | Verified with Qwilr, PandaDoc, Proposify; 2026 comparison articles | Qwilr vs PandaDoc, PandaDoc vs Proposify vs Qwilr, 8 best proposal software |
| Pipeline stage structure (5–7 stages, Won/Lost termination) | HIGH | Verified with Pipedrive, Capsule CRM, Salesforce; "Proposal Sent → Negotiation → Won" is standard | Salesforce Pipeline Management, CRM Pipeline Stages, GoHighLevel Pipeline |
| Lead follow-up reminders (last_contact_date, 7+ days flagged) | MEDIUM-HIGH | Sourced from Outreach, HubSpot, Nimble best practices; solo consultant context is reasonable inference | Sales Pipeline Best Practices, Outreach Pipeline Management |
| Solo consultant CRM avoidance of team features | MEDIUM | Sourced from "Best CRM for Solopreneurs" guides; solo preference for simplicity consistent across 3+ sources | Breakcold: CRM for Consultants, Authencio: CRM for Freelancers, Addtocrm: Best CRM Solopreneurs, Mimiran: Anti-CRM |
| Tiered proposal (A/B/C independent offers) | MEDIUM-HIGH | Verified via multiple consulting pricing guides; "3 tiers ideal" is consensus. Independent offers is ClientHub-specific. | Mercury: Pricing Strategy, Ignition: Tiered Pricing, Consulting Success: Consulting Rates |
| Multi-step form engagement patterns | HIGH | Verified with Heyflow, Optimonk, HubSpot research; form completion rates improve with progressive disclosure | Instapage: Multi-Step Forms, HubSpot: Multi-Step Forms, Webstacks: Multi-Step Form Examples |
| Proposal acceptance automation (→ project creation) | MEDIUM | Sourced from Anchor, Estimate Rocket, Monograph workflows. ClientHub implementation is custom but pattern is established. | Sayanchor: Proposal Acceptance, Monograph: Build, Send, Sign, DocuSign: Workflow Automation |
Open Questions for Later Phases
- Email integration: Should proposals be sent via dashboard integration, or manual copy-paste? (Deferred to Phase 10+)
- Proposal expiry: Should proposals auto-expire after N days, or stay open indefinitely? (MVP: no expiry)
- Lead de-duplication: If lead email is already in clients table, how should system handle it? (MVP: manual check; Phase 9+ auto-detect)
- Activity type richness: Should activities include location, participant names, sentiment tags? (MVP: basic type + notes; Phase 8 can enhance)
- Proposal versioning: Can consultant send multiple proposals to same lead? (MVP: yes, same lead.email + new proposal record)
- Payment plan customization: Can consultant define custom installment schedules, or only use templates? (MVP: templates; Phase 9 can add custom)
- Lead archive vs. delete: When lead is Won → converted to client/project, should lead record stay in DB for history? (Recommendation: keep for audit trail; mark archived or moved_to_project_id)
Appendix: Frequently Asked Questions
Q: Why no e-signature in MVP?
A: Design is ready (CLAUDE.md notes it as deferred). A simple "Accept" button + timestamp is sufficient proof of acceptance for solo consultant use case. E-signature (DocuSign, Stripe Sign) adds external dependency and cost; defer unless client explicitly requests.
Q: Should proposals auto-expire?
A: No, not in MVP. Solo consultant may send proposal Monday, follow up Thursday, acceptance Friday. Expiry is team-sales friction (forces re-quote). Keep simple: accepted_at = null means still open.
Q: Can a lead be in two stages at once?
A: No. Stage is singular immutable state at any moment. If second proposal sent to same lead: either (a) create new lead record (same email, add suffix "2"), or (b) update same lead.stage to "Proposal Sent" again. Option (b) is simpler; stage can repeat; last_contact_date updates on each proposal send.
Q: Should activities auto-log from email/Slack?
A: No, not in MVP. Adds external dependency surface. Fallback: consultant manually logs calls/emails as activities in <10 seconds. Acceptable for solo consultant volume (5–15 leads).
Q: What if lead email already exists in clients table?
A: Phase 9 auto-detection: when moving lead to Won, check if lead.email in clients. If yes, ask: "Link to existing client X (repeat engagement)?" or "Create new client". Prevents duplicate records.
Q: Can phases be reordered after project creation?
A: Yes. Phases are copied from offer at project creation time, but project phases are modifiable in hub (Phase 1, already built). Offer template is never mutated. Studio-grade immutability.
Q: What's the payment flow after Won → project creation?
A: Consultant chooses payment template (50/50, 3-part, 4-part, custom) during Won → project creation modal. System creates N records in payments table with due_dates calculated from project start_date. Client sees payment schedule in hub dashboard (Phase 1, already built). No invoicing or collection automation (out of scope, PROJECT.md locked).
Q: Can consultant change their mind after accepting a proposal?
A: If consultant moves lead back to Proposal Sent or Negotiating (after accepting and creating project), the original accepted_proposal record remains immutable. Project can be deleted/archived if needed, but proposal acceptance is final. This matches real-world: once accepted, consultant can't un-close a deal.
End of FEATURES_v2.0.md