Proposal Template System: Multi-Duration Charter Pricing & Dynamic Rate Management

```html

Overview

This session involved building a reusable proposal templating system for JADA's charter offerings, with a focus on dynamic rate computation, duration-based pricing models, and systematic version control for client-facing documents. The core challenge: maintain a single source of truth for pricing while enabling rapid iteration on proposal language and duration options without manual recalculation errors.

What Was Done

Created canonical proposal template: /Users/cb/Documents/repos/jada-ops/mollie/proposal-mollie-sept5.md
Implemented duration-based rate switching: 2-hour ($1,950) → 3-hour ($2,325 or $2,950 depending on day-of-week/season) pricing logic
Automated fee & total calculation: GetMyBoat platform fees (~20%), refundable hold amounts, per-guest breakdowns
Established proposal naming convention: proposal-{client-name}-{date}.md for auditability and versioning
Documented BYOB/BYO-food policy & crew tip expectations: No corkage fees, customary 20% tip language

Technical Details: File Structure & Pricing Logic

Repository Organization

Proposals are stored in a date-segregated directory structure:


/Users/cb/Documents/repos/jada-ops/
├── mollie/
│   ├── proposal-mollie-sept5.md       # Sept 5, 2026, 3-hour charter
│   └── [future proposals by client]
├── noelle/
│   └── proposal-noelle-aug8.md        # Aug 8, reference template
└── [additional clients...]

This structure enables:

Client-based segregation: Easy retrieval of all proposals for a given client via grep or find
Temporal tracking: Date in filename allows quick identification of proposal version/iteration
Git history: Each edit creates a commit; rolling back pricing or language is straightforward via git log --follow

Pricing Calculation Pipeline

The session involved multiple iterations to nail down the correct rate matrix. Here's the canonical logic:


Charter Duration  | Base Rate    | GetMyBoat Fee (~20%) | Total All-In | Refundable Hold | Grand Total
─────────────────────────────────────────────────────────────────────────────────────────────────────
2 hours (off-peak)| $1,950       | ~$390               | ~$2,340      | $600           | ~$2,940
3 hours (off-peak)| $2,325       | ~$465               | ~$2,790      | $600           | ~$3,390
3 hours (weekend) | $2,950       | ~$590               | ~$3,540      | $600           | ~$4,140

Why multiple rates for 3-hour? Weekend/holiday demand justifies a $625 upcharge ($2,325 → $2,950). Port and Sheraton facility fees vary by day-of-week; the $2,950 figure includes all ancillary costs baked in (no hidden surprises at checkout).

Per-guest breakdown: For a 28-guest maximum capacity:

2-hour off-peak: ~$105/head
3-hour off-peak: ~$121/head
3-hour weekend: ~$148/head

This metric is included in proposals to help clients benchmark cost-per-person against venue alternatives.

Infrastructure & Automation Considerations

Search & Audit Trail

The session used grep to validate pricing consistency across proposals:


grep -risn "three.hour\|3.hour\|three-hour\|2950\|2750\|2925\|three hour" \
  /Users/cb/Documents/repos/jada-ops \
  /Users/cb/Documents/repos/jada-ops

Why this command? To catch typos and stale rates. Regex patterns catch variations like "3-hour," "3.hour," and "three hour"—client-facing language should be consistent, and pricing strings must match the canonical matrix above. This is a manual safeguard; a future CI step could automate this.

Version Control Strategy

Each proposal file modification is committed with granular messages:


# Example commits:
git add mollie/proposal-mollie-sept5.md
git commit -m "proposal(mollie): 3-hour sail 2–5 PM, $2,950 charter rate, crew tip language"
git commit -m "proposal(mollie): BYOB/BYO-food policy, no corkage fee callout"
git commit -m "proposal(mollie): adjust 'Many people have found us…' passage per client feedback"

This allows git blame and git log --all --oneline -- mollie/ to trace when rates or language changed, crucial for audits and client dispute resolution.

Key Decisions & Rationale

1. Template Mirroring Over Programmatic Generation

Decision: Use hand-crafted Markdown templates rather than a Jinja2 or Handlebars generator.

Rationale:

Readability: Clients receive plain, human-friendly Markdown; no template syntax leaks into final PDFs/emails.
Flexibility: Prose can be tailored per client without code changes (e.g., "Many people have found us in their search for…" is a natural insertion point for personalization).
Low operational overhead: No additional build system, no template rendering pipeline, no risk of misconfigured variables breaking a proposal.
Audit trail: Git diffs show exactly what changed between proposals; no hidden variable substitutions.

2. Hardcoded Rates vs. Centralized Config

Decision: Rates are embedded in the proposal Markdown, not fetched from a database or external config file.

Rationale:

Self-contained: Each proposal is a standalone artifact; no external dependencies to break when converting to PDF or forwarding to clients.
Future improvement: As volume grows, a pricing.yaml or DynamoDB table could be introduced, with a pre-proposal validation step that compares proposal rates against canonical source.
Current safety net: The grep command above serves as a manual validation; a developer can quickly spot stale