Lance's own working tool. Pick pieces on the left, watch sequencing and requirements react on the right. Numbers per Reeve's pricing package (2026-09-01) and Fabian's build-tool content (2026-09-02).
Every piece below is independently selectable and independently priced. Foundation fees aren't their own choice — each one is included automatically the moment you check any piece in its group, and drops off if you uncheck them all (Reeve's pricing package, §2–§4, granular structure applied 2026-09-02).
Same total as above, broken into its parts. One-time build cost, then ongoing monthly cost.
Every step is tagged. "Always" steps run regardless of what's picked; piece-tagged steps only show while that piece is checked on Tab 1. Phases run roughly left-to-right; steps within a phase can run in parallel unless a dependency note says otherwise. Known simplification (2026-09-02): "Base Build" steps show whenever ANY of the 3 sub-pieces (CRM, Website, Visitor App) is checked, not only when all three are — Fabian's source content is written at the bundled Base-Build level, not yet split per sub-piece. Same simplification applies to "Email Campaign(s)" steps across the 4 campaign types. A finer-grained rewrite of this content is a real follow-up item, not done here given time constraints.
Yes, for the large majority of this engagement — Base Build, Kickoff Emails, and a Second Suited Set direction all realistically run 100% remote, with zero in-person requirement, if Sacha selects those pieces alone.
Reeve's pricing document already flags this exact tension: since Cascadia is committed to being the ongoing service provider, a literal self-hosted-on-Sacha's-own-hardware setup sits in real tension with Cascadia being able to reliably service it remotely. The more likely real answer, once Tahoma weighs in, is the middle path (Cascadia-managed hosting with full data-export/portability guarantees) — satisfies Sacha's privacy preference without any hardware ever being at his location, and keeps the whole engagement fully remote.
Bottom line: don't over-promise "fully remote, no exceptions" before Tahoma answers the off-grid questions (Step 2C.1) — but it's realistic to tell Sacha remote-only is the plan, with the off-grid architecture decision as the one open variable that could theoretically introduce a single setup visit, not an ongoing pattern of in-person work.
Reactive to Tab 1 — off-grid and Kickoff-Emails-specific lines only appear when those pieces are selected.
Skycorpmaps@mac.com — whether it's a real business account or a personal Apple ID, since DNS changes could risk email deliverability if this isn't mapped first.Full discovery question bank: 2026-09-01_Client-Onboarding-Scoping-Checklist.md §6 (25+ questions) — this tab restates only the access/hardware/remote-specific subset.
Imara's calibrated assessment across the full engagement. Only genuine, non-trivial risks are listed — routine-effort items are filtered out (see below). This tab does not change with your Tab 1 selections.
The sales pipeline app is only as good as the data behind it — someone has to turn ~60 accounts' worth of free-text notes into structured records (status, next step, follow-up date). This is real, human-hours work, not a technical unknown — it can't be automated away, and the quality of the migration determines the quality of the tool from day one.
His live site apparently already links out to individual businesses — the real scope of "port this content" won't be known until someone actually audits it. Could be a quick pass or a genuinely time-consuming one; we can't tell which until we look.
If Sacha comes back wanting everything live in days rather than weeks, several things genuinely cannot compress regardless of how fast information arrives: real data ingestion, a counsel-reviewed contract, DNS cutover with its own propagation delay, and branding integration that depends on assets he hasn't provided yet. This isn't a confidence problem on our end — it's physics.
This isn't a build risk — it's a genuine fork in what we're offering. A self-hosted system trades Cloudflare's free, managed uptime/security for a real ongoing maintenance burden that someone has to own. This only becomes a concern if Sacha picks this option without understanding what he's actually trading — worth a direct conversation about what he's trying to avoid (a monthly bill vs. vendor lock-in vs. hardware-failure risk), since those point to different real answers.
These came up during the build but don't belong on a "concerns" list, since they're already resolved or don't rise to genuine risk:
Iara's read — the positive counterpart to Tab 4. Each case is written to help Sacha see the wisdom in something he might already be leaning toward, not to push a pick he hasn't made. Every dollar figure below is directional, not a guarantee. Pieces not currently selected on Tab 1 are shown dimmed, below — not hidden — a quiet "here's what's on the table," never pushy.
Right now, Sacha's ad pitch to advertisers is a circulation guess — "X thousand maps get printed." We're putting a QR code on the map that opens a digital version, so next season he can show advertisers exactly how many people scanned in and redeemed their discount — real data instead of a claim. That's the core of it. On top of that: a real sales pipeline replacing his Apple Notes, a rebuilt website that makes Mobimaps look credible before anyone calls, and a structured kickoff-email system so no advertiser gets missed. One system, not four separate tools.
What each piece does, why it matters to this kind of business, the toughest real objection with an honest answer, and how it connects to the rest of the system. Study this before improvising live — it isn't meant to be skimmed once.
Fair question, no invented number to answer it with — nobody knows the real scan rate yet because there's no baseline. Even a modest scan rate (5–15% of a season's print run is the deliberately wide working range used in planning) still produces real data points Sacha didn't have before, and the paper map isn't being risked to find out — it keeps working exactly as it does today regardless of app adoption. Low-downside, real-upside. Don't oversell adoption — let the actual data do the talking.
Probably true, and exactly why this is a quiet-compounding case, not a dramatic one. Nobody notices the account that quietly didn't renew because a follow-up got missed during a busy week — it just looks like normal churn. The case isn't "your current system is broken," it's "a small, invisible leak adds up over years, and this closes it without asking you to change how you sell."
The most honest-to-undersell answer of the four. No hard number to offer, and inventing one would be dishonest — the real, defensible value is credibility-and-conversion support for the advertiser sales conversation Sacha's already having, not a directly measurable increase in lead volume. Direct lead-generation upside is plausible but can't be sized honestly without knowing current site traffic. Say this plainly if asked — don't reach for a number that isn't there.
Never about the writing being better than what Sacha would write himself — he still reviews and sends every message, so nothing is taken out of his hands. It's about coverage and timing: making sure all ~60 accounts get reached, in the right order, at the start of the season rather than whenever time allows. No invented response-rate lift or hours-saved figure — the honest framing is "you get to your 60 accounts before someone else gets to them first," a timing-and-consistency case, not a revenue-projection case.
Marlowe's grounding for the pricing conversation itself (§4 of the Elevator Pitch & Talking Points doc) — updated 2026-09-02 for the new granular per-piece/per-campaign structure. Know both sides of the fork; say only the number Lance has actually ratified.
Picking a single piece (especially CRM or Visitor App alone) means the Foundation fee is carried by one deliverable instead of three — margin runs thinner there than on the full 3-piece selection. Worth knowing before quoting a single-piece price live, not a reason to avoid quoting it.
If price genuinely becomes a concern, the honest comparison: a CRM, a website, and a QR-driven app built as three separate bespoke engagements from three separate vendors would run $45,000–$110,000 at real industry rates. Cascadia's number reflects a working, refined prototype already existing — sunk groundwork, not being re-billed. Use only if it comes up; reciting it unprompted reads as a sales pitch, not an honest answer to a real question.
Never present the directional revenue estimates (the CRM's $1,200–$2,400/season, the App's engagement-lift ranges) as promises — they're built from assumptions Sacha hasn't confirmed. Say: "this is a plausible range based on a few reasonable assumptions — the real number depends on things only you'd know, like your actual renewal rate."
Of the $449, only roughly $0–$25 is literal hosting — Cloudflare at this traffic scale is nearly free. About $276/month is the real labor value of holding 3 support hours ready every month. The remaining $148–$173/month is Cascadia's margin for being the ongoing service provider. Fair to say plainly if asked — not a hidden markup.
Already thought through, not reacted to live. Hosting cost genuinely doesn't change with season (confirmed — 2–3 orders of magnitude of headroom regardless of traffic), so a seasonal hosting discount wouldn't be honest to offer. What does move is support-labor demand, heaviest right before a season opens. The strongest answer: unused support hours from quiet months roll into a capped bank Sacha draws down when the pre-season crunch hits — same price, same predictability, capacity where it's actually needed. If Sacha wants the number itself to visibly flex, a three-band seasonal rate is possible but adds billing complexity and isn't finalized — don't quote a specific seasonal number.
A real question, and it deserves a real answer. Cascadia is new and unproven, and Sacha — or whoever asks this next — would be right to ask it. Don't deflect with reassurance; answer with what's actually true.
Starting point: there's no long track record to point to, and pretending otherwise would be the wrong move. The credible answer isn't "trust us because we're good," it's "here's what you can actually verify yourself."
A working prototype already exists, and it's already been shown, not just described — Sacha has already interacted with an early version of the CRM concept and the QR-app concept and shown real interest in both. The proof-of-concept risk is already substantially reduced before a single dollar changes hands.
The pricing itself reflects the honesty, not a sales trick — priced against real forward production cost, not inflated to reflect a reputation Cascadia doesn't have yet and isn't pretending to have. No attempt to recover the substantial unpaid work already put into this pitch — that's a sunk cost of proving the concept, not something billed for after the fact.
The rollout itself is built to de-risk, not to move fast and hope — real client data never goes into the system until security handling is proven first on sample data. The website migration is a staged cutover with live verification at each step, not a single big-bang switch that risks breaking something (like email) with no way back.
Sacha isn't locked in even if it doesn't work out — a full Handover Pack (the actual repo, credentials, a real walkthrough) is built and delivered regardless of who ends up running the system long-term. If the relationship doesn't continue, Sacha owns what was built, not Cascadia.
Being the first paying client is genuinely an advantage, and it's fair to say so — Sacha isn't client #200 in a queue; he's getting direct, personal attention on a build that matters enormously to Cascadia's own credibility. A real incentive alignment, not a line.
What NOT to say: don't promise outcomes ("this will definitely increase your renewals"), don't claim a track record that doesn't exist, don't paper over the "we're new" fact with vague confidence.
The trustworthy version of this answer: "You're right that we don't have five other clients to point to yet. What I can point to is what you've already seen working, how carefully this gets rolled out so nothing breaks along the way, and the fact that you own everything that gets built, no matter what happens with us long-term."
Fast recall if put on the spot mid-conversation.