Add-on Services & Integrations Catalog

How to sell, scope, and price every add-on that hangs off a base build — content editing, analytics, email, payments, WhatsApp, deep integrations, advertising. Operational playbook — derived from BUSINESS-MODEL.md + DECISIONS.md (settled) + BRAND-STRATEGY.md.

Every engagement starts with a base package — Launch (A), Repaint (B), or Storefront (C). The items below are the attach layer: what you upsell onto a build, or sell to an existing client, without ever bending the base package's fixed scope. The recurring products (Care Plan, the WhatsApp receptionist retainer) live in Recurring & care; prices/discounts/invoicing live in Pricing, payments & discounts. This doc is the build/setup side.

Rules of the road (read once, apply always)

• One active build at a time + a waitlist. Add-ons are scoped into the current build or a change-order — never a reason to run a second build in parallel.
• One integration is included in every build. Each additional integration is a fixed add-on or a change-order at R900/hr SA · $110/hr INTL, quoted up front and written into the SOW (grounded — BUSINESS-MODEL.md change-order rate).
• Upsell to the next thing; never bend the current scope. Out-of-scope requests convert to a priced add-on or the R900/hr change-order — they don't silently expand the package (Risk 3, scope creep).
• Client-facing language is outcome-led and stack-agnostic — "your team edits the site themselves", "you'll see which enquiries convert", not "Sveltia git-CMS" / "GA4" / "Resend function". The stack names in this doc are internal only.
• ⛔ No hospitality clients, ever. No add-on, integration, or referral path routes a hospitality lead in.
• Pricing honesty: any SA price below not carried in BUSINESS-MODEL.md is a web-dev-hourly proxy (R450–950/hr) and is flagged as an unvalidated proxy estimate. See the global pricing flag at the end.

Master catalog

1. Content editing / CMS

Sell it as: "You'll be able to update your own words, photos, prices and gallery whenever you like, and it goes live in a click — no waiting on a developer, no monthly software fee." Sold as a build add-on, not a standalone product (it rides on a build that uses the editable-site-template).

Scope boundary — hard line. Editable content is text · images · prices · gallery · contact details. It is NOT bookings, logins, inventory, or anything with a live datastore. The moment a client needs those, it is no longer a content-edit add-on — it graduates to the aerias direction (D1/Supabase-backed app), which is a bespoke build quote, not this add-on.

How it works (internal): SvelteKit adapter-static on Cloudflare Pages; content is JSON in the repo edited through a form-based portal at /admin (Sveltia). Staging branch = editable → merge to main = publish. Client edits on staging, you (or they) merge to go live.

One-time infra [X] (per client, first setup):

• Cloudflare Pages git-integration (main→prod, staging→preview) — not direct-upload mode
• A GitHub OAuth app (client id/secret)
• A sveltia-cms-auth Cloudflare Worker deployed
• Cloudflare Access gating /admin + the staging site (client's email)

Until all four exist, /admin loads but can't authenticate. Budget this into the setup fee; it's faster on repeat clients once the worker pattern is reused.

Price: R3,500–6,000 setup (proxy estimate to validate — not in BUSINESS-MODEL.md; derived from ~6–10 h at the R450–950/hr proxy). No monthly fee — the whole point is the client edits for free. Proposed — not yet in DECISIONS.md.

2. Analytics & tracking

Sell it as: "You'll see how many people visit, how many turn into enquiries/bookings/sales, and where you're losing them" — and it's what produces the "after" numbers for the case-study one-pagers and the /repaint metrics (the ROI-objection killer for ICP-A).

Default = Cloudflare Web Analytics — free, privacy-friendly, no cookie banner. Put it on every build by default (settled task, BOARD.md #7: berlein has none, aerias has GA4 — both should get CF WA). This is bundled, not a line item.

GA4 (funnels / ads attribution) — when the client wants it. Use GA4 where the client needs a conversion funnel or ad attribution (e.g. aerias's checkout funnel on property G-R4EP5H5QTF). GA4 sets cookies → it needs a consent notice, so only add it when the funnel/attribution is genuinely wanted.

Conversion-event tracking on the moments that matter: enquiry submit · booking confirmed · checkout complete. This is the add-on's real value — it turns "traffic" into "leads/sales".

Price: CF Web Analytics free / bundled. GA4 + conversion-event wiring R1,800–3,500 setup (proxy estimate to validate; ~3–5 h at proxy rate). Proposed — not yet in DECISIONS.md (the CF-WA-by-default choice is settled; the priced GA4 add-on is the new bit).

3. Email (transactional)

Sell it as: "Every enquiry lands reliably in your own inbox — sent from your own domain — and your customer gets an instant confirmation."

What it replaces. The current sites use client-side EmailJS (berlein, aerias order-confirm/welcome) and Formspree (aerias contact) — keys shipped in the browser bundle. This add-on retires those in favour of server-side transactional email via Resend, called from the site's own functions, sending FROM the client's domain TO the client's business inbox (+ a customer confirmation where relevant). Resend is the settled single vendor (ROADMAP.md).

POPIA / privacy rules — non-negotiable:

• Destinations are per-client. Enquiries go to the client — Alexa for berlein, the aerias team for aerias — never to Daniel.
• Client submissions must NOT be copied to Daniel's Discord or any of Daniel's channels. Berlein especially (health-adjacent → POPIA-sensitive).
• (Daniel's own site danielslater.dev routing enquiries to his own Discord is fine — that's his data, not a client's.)

Setup checklist:

• Verify the client's domain in Resend (DKIM/SPF DNS records)
• Server-side send function on the site's host (Vercel Function / CF Pages Function / Worker)
• Destination = client's business inbox; confirm the address in writing
• Customer-confirmation template where the flow warrants it
• Remove the old EmailJS/Formspree keys from the bundle

Price: R2,500–4,500 setup (proxy estimate to validate; ~4–6 h at proxy rate). Run cost ~R0 at these volumes. Proposed — not yet in DECISIONS.md (Resend-as-vendor is settled; pricing this as an add-on is new).

4. Payments

Sell it as: "Customers can pay you online and you're confirmed the moment they do."

Gateways:

• SA: Yoco (~2.6% online), Paystack (2.9% + R1.50), or PayFast (2.4–3.5%) — the client's choice; these are the client's processing fees, not our fee.
• INTL: Stripe.

WhatsApp / chat flows — there is NO native in-chat WhatsApp Pay in SA. The pattern is a hosted payment link + webhook confirmation back in chat. Demo and sell it honestly as "tap, pay, get confirmed here" — never "in-chat checkout" or "pay inside WhatsApp". The link opens the browser to pay; the bot gets a webhook and sends the confirmation message. (Even SA's biggest retailers haven't wired WhatsApp end-to-end into payments — don't over-promise it.)

Where it's sold: payments are bundled into Storefront (C) (payments + shipping config is in-scope there). As a standalone add-on on a non-Storefront build or a chat flow: R3,500–6,500 (proxy estimate to validate; ~6–10 h — gateway account, checkout/link, webhook confirmation). Proposed — not yet in DECISIONS.md for the standalone add-on price; the Storefront bundle is grounded.

5. WhatsApp Receptionist — build / setup

The recurring product (R1,800/mo capped tier, overage, margin math, Meta's Oct-2026 metering) is in Recurring & care. This section is the one-time build/setup.

Build (Chat Agent, Pkg D): R15,000 — ONE agent, ONE channel (WhatsApp), ONE integration included, scripted transactional flows. Grounded (BUSINESS-MODEL.md D + WhatsApp addendum). Effort ~16 h (20 h on the first).

Scope = transactional / booking only. Booking, confirmations, reminders, FAQ. This is also a Meta-policy requirement, not just a scoping choice — since Jan 2026 Meta bans general-purpose bots and blesses narrow booking/ordering/support bots, so the agent must be architecturally scoped to refuse off-topic requests. Broadcasts / marketing messages are a separate priced line item (marketing runs ~R1.40/msg — 5k/mo ≈ R7.5k in Meta fees alone), never folded into the build or the base retainer.

Onboarding lead time — set expectations BEFORE signature (no same-day go-live):

• Meta Business verification: 2–14 days (business docs; up to 14 if incomplete)
• Template review — a separate Meta queue on top of verification
• Dedicated number — client can't reuse their personal WhatsApp number (surface this early; it's a common late objection)
• BSP = Twilio PAYG (lean, ~$0.005/msg markup, no monthly) — never a bundled no-code platform like WATI (its subscription alone can exceed the whole retainer)

Included integration: default to the one that fits the sub-vertical — see §6. For the psychologist segment (the flagship, Alexa's segment) that's Google/Outlook Calendar sync.

6. Deep integrations

The rule (settled framing): every build includes exactly ONE integration. Each additional integration is a fixed add-on or a change-order at R900/hr SA · $110/hr INTL, quoted up front and written into the SOW. Never absorb a second integration into a fixed price silently.

Effort splits hard by target — quote from this, not a flat rate:

Decision aid — which diary path?

• Psychologist / allied-health prospect → Google/Outlook Calendar sync (included integration).
• Dentist / GP on GoodX → GoodX API write-back (add-on if it's the 2nd integration).
• Dentist / GP on Healthbridge-only → own the diary (avoid the 60-day gate) unless the client will fund the partner process. Whether to pursue a formal GoodX partnership is an open decision (below).

7. Advertising (Proposed — new offering, no research yet)

⚠️ Proposed — needs a dedicated pricing/scoping research leg before it is sold. Daniel raised this; there is no research behind it and no SA-specific pricing for it anywhere in the source docs. Everything here is a proposal, not a decision.

Proposed shape — keep it LIGHT:

• One-time setup fee — set up the Google/Meta ad account, build the initial campaign(s), and wire conversion tracking (this depends on §2 being in place — the campaign is only worth running if you can measure the conversions).
• Optional light management retainer — a capped monthly check-in/optimisation, only if validated.

⚠️ Risk flag — why this fights the model: ongoing ad management is an open-ended time commitment. It collides directly with the 10–20 h/week ceiling and the "async, best-effort, no hard SLA" stance (ad platforms and clients expect timely reactions to spend/performance — that's an implicit SLA, like voice). Ad spend also isn't Daniel's money to be on the hook for.

Mitigation (proposed): keep it setup-only until validated, or if a retainer is offered, hard-cap it at a fixed few hours/month with everything beyond that at the R900/hr change-order rate — same discipline as the voice minute-cap.

Price: [placeholder — unvalidated] one-time setup + optional capped retainer. No specific price is set here on purpose — the research leg must produce it. Proposed — not yet in DECISIONS.md.

Global pricing flag

Per DECISIONS.md (open item) and BUSINESS-MODEL.md: there is NO SA-specific AI / automation / add-on pricing in the research. The only add-on numbers that are grounded here are the change-order / integration rate (R900/hr SA · $110/hr INTL) and the WhatsApp build (R15k) + retainer (R1,800/mo) from the WhatsApp addendum. Every other SA setup price in this catalog (CMS, GA4/analytics, email, standalone payments) is a web-dev-hourly proxy (R450–950/hr) and is an unvalidated proxy estimate — validate against real quotes or a pricing research leg before treating any of it as settled.

Open decisions (→ DECISIONS.md)

Everything below is flagged Proposed in this doc and needs Daniel to ratify (or a research leg to validate) before it moves to DECISIONS.md:

• CMS / content-editing add-on — sell as a fixed build add-on with the text/images/prices/gallery boundary; proxy price R3,500–6,000 setup.
• Analytics add-on — CF Web Analytics free/bundled by default (this half is effectively settled via BOARD.md #7); GA4 + conversion-event tracking as a paid add-on at a proxy R1,800–3,500 is the new proposal.
• Email add-on — Resend is the settled vendor; pricing the transactional-email setup as an add-on at a proxy R2,500–4,500 is the new proposal.
• Standalone payment add-on — proxy R3,500–6,500 when payments aren't bundled in Storefront.
• Advertising offering — whether to build/sell it at all, its price, and its management-retainer cap. Requires a dedicated pricing/scoping research leg first (extends the existing open "SA add-on pricing" gap in DECISIONS.md).
• GoodX API partnership — whether to pursue a formal GoodX integration partnership for the dental segment (the one writable diary), vs. staying calendar-sync-only + own-the-diary.