Founders Teach Customers With Email Curricula

Founders teaching customers with email curricula is the honest alternative to a knowledge base nobody opens and a webinar nobody rewatches. You already explain the product on calls. A curriculum captures that explanation as sequenced issues, grounded in the docs you actually ship, reviewed before it hits an inbox that also contains your status page.

This is not a nurture sequence. Nurture sequences optimize for a demo booking. Teaching curricula optimize for a customer who can integrate without Slack. If you blur them, customers learn to ignore you.

Cadensend is the engine we built for the teaching side: plan a series from a learning goal, ground every issue in sources, review, send approved mail exactly once. MIT license, self-hosted, no hosted signup. It is not ConvertKit. It is not a bulk sender. Source: github.com/HinterBuild/cadensend.

Key Takeaways:

• Write customer curricula from product sources (docs, changelog, API spec), not from marketing adjectives.
• One series per job-to-be-done: “send your first webhook,” not “love the platform.”
• Founders should review claims about money, data, and uptime personally. Models rewrite SLAs.
• Do not blast a curriculum to a purchased list. Teaching ops still need consent.
• Version the course against the product. A wrong default in issue 3 becomes support load.
• Measure activation tasks, not open rate. Opens are not evidence of teaching.

Table of Contents:

• Why founders are the right authors — and the wrong senders
• Pick a job, not a newsletter theme
• Ground in the product, freeze legal
• Review like support will screenshot it
• Delivery: curricula vs campaigns
• Cadensend for founder-led teaching
• When this fails
• A four-week rollout
• Frequently Asked Questions

Why founders are the right authors — and the wrong senders

Founders know the exclusions: what the product is not. Cadensend's Create Series wizard captures included and excluded concepts, outcome, audience level, cadence, timezone, and tone. That brief is a founder artifact. Delegating it to a model produces a generic “intro to webhooks” that could be any company.

Founders are the wrong unsupervised senders because they are tired and optimistic. They will approve a draft that overclaims “real-time” or “unlimited.” Human-in-the-loop AI written courses exist so the send tool is privileged. Pair with HITL approval gates.

If you are a solo founder teaching yourself the market, that can start as a personal learning series. The moment the audience is customers, it is a team series with reputational risk. Re-review.

HinterBuild's about page is our version of this discipline. We would rather ship a narrow teaching engine than a fake marketing cloud. Contact if you want the same on your docs.

Pick a job, not a newsletter theme

Bad series titles: “Getting the most out of Acme,” “Tips & tricks,” “Product education.”

Better: “Verify a webhook signature,” “Replay a failed payment,” “Promote a staging API key to prod without leaking it.”

Each series should have a single outcome you could put on a support macro: “After these five issues, you can do X without us.” If you cannot write that sentence, you are planning content, not a curriculum.

Audience level belongs in the brief. “First engineer at a customer” is not “the customer's VP of sales who forwarded the email.” If both matter, two series.

Cadence: two issues a week beats daily. Customers have jobs. Teaching that arrives like a burst campaign gets filtered.

Issue 0 can be a one-page map: outcome, how many issues, what you will not cover, and how to reply if something is wrong. Do not hide a sales deck in issue 0. If they need a champion inside the customer, say so in one sentence and point at the docs, not at a calendar link farm.

Sample five-issue “verify a webhook” spine:

1. Where the secret lives and how it rotates.
2. The header names and the exact HMAC construction, cited to the spec.
3. Failure modes: clock skew, retries, duplicate deliveries.
4. A diagram of retry vs replay — PNG in the inbox.
5. A staging checklist they can run without you on the call.

If issue 3 cannot cite the retry policy in your docs, stop. You have a docs problem, not a copy problem. The same honesty belongs in teach yourself system design by email: uncited folklore does not belong in customer mail either.

Diagrams: one integration path per figure, PNG in the inbox. See diagrams in email SVG vs PNG.

Ground in the product, freeze legal

Upload the OpenAPI spec, the auth docs, the changelog, the status-page policy. Do not upload the landing page. Landing pages are slogans. Slogans cause hallucinations that sound on-brand.

Cadensend retrieves only from the sources you supplied, with structural citations the renderer turns into links. The model cannot fabricate a docs URL. You still review AI-generated lesson content because the prose can misread a real span.

Freeze anything that is:

• Pricing, credits, overage
• Data residency, subprocessors, retention
• Uptime language
• “HIPAA,” “SOC 2,” “encryption at rest” claims
• Who the product is not for

Those sections are founder- or counsel-written, locked, and only edited when the source of truth changes. Keep the course updated when sources change is the maintenance loop. Do not let a weekly regen “clarify” the DPA.

If your docs are a mess, fix docs first. A curriculum cannot save an untrue handbook. RAG on garbage is still garbage; we wrote why RAG returns garbage for a reason. For larger corpora, RAG systems help, but the editorial freeze still applies.

Review like support will screenshot it

Support will. Sales will. A customer will forward issue 2 to a lawyer.

Use the five-axis score (faithfulness, coverage, difficulty, actionability, email fitness). Hard-fail any invented endpoint. Hard-fail any “just disable verification in production” shortcut.

Add founder-specific checks:

• Does this contradict the latest changelog?
• Does the example use the public API, not an unreleased flag?
• Is the diagram the public topology or our internal one? Internal diagrams do not belong in customer mail.
• Would we be comfortable seeing this quoted on Twitter?

Section-regenerate, don't whole-issue roulette. Cadensend Content Studio is built for diffs and retrieved context.

Coding assistants can help you compare the draft to docs/ in git. OpenClaw vs Claude Code is that comparison. The ChatGPT cheat sheet can draft the review checklist. Neither holds send.

Cost control: don't run a frontier model to rewrite marketing tone. Tone is in the brief. Reducing LLM costs keeps this sustainable after week two.

Delivery: curricula vs campaigns

Cadensend delivers exactly once, timezone-correct, with the record written before the provider call. That is what you want for teaching. It is the opposite of “resend to non-openers.”

Legal: in the US, CAN-SPAM still applies when you use email commercially. Consent and unsubscribe are not optional because your intent was pedagogical. Cadensend's MVP sends to a verified recipient; opt-in audiences are a later, gated update. Do not “just SMTP” a customer list from a laptop to skip that work.

If you already have a consented lifecycle tool, you can author in Cadensend (self-hosted, your data) and hand approved HTML to the tool that owns suppression. Keep teaching ops and list ops in different systems. Mixing them is how a “lesson” inherits UTM soup and a 40% promo footer.

Internal onboarding can be stricter and more internal. Customer curricula must assume adversarial reading.

The send worker is backend API engineering: idempotency keys, provider webhooks, bounce handling without double-sends. See idempotency in distributed systems.

Cadensend for founder-led teaching

Why this product shape:

• Narrow. One learning goal → structured series. Not a CRM.
• Grounded. Claims trace to sources you supplied.
• Bounded writer. No arbitrary browse, no code execution, retrieved text is data.
• HITL. Awaiting review is a real state.
• Exactly once. Restarts do not duplicate lessons.
• Open. MIT. You read it. GitHub.

Why not ConvertKit: ConvertKit is good at audience and offers. It is not a planner-validator-citation engine. Using it as a course brain produces ungrounded drips.

Why not an autonomous agent: agents that “research competitors and email customers” are a support incident. Cadensend is not an autonomous research agent. Product page: Cadensend.

Figure 1. Founder brief: topic, exclusions, outcome, audience, cadence — captured once, up front.

When this fails

The syllabus is the homepage. Too broad, no outcome, no exclusions.

The sources are sales decks. The model will promise the roadmap.

Nobody owns updates. Docs move, course stays. Follow source-change maintenance.

You measured opens. A 60% open rate on a wrong retry example is a failure. Measure the job: signed webhooks in production.

You mixed promo. Issue 4 is a discount. Learners learn to skip.

You sent internal diagrams. Customers now architect against a service that is not on the public status page. Diagrams need a public-vs-internal check.

You treated Cadensend like a list vendor. It is not. Self-hosted teaching ops. No hosted signup.

A four-week rollout

Week 1. Founder writes the brief for one job. Gather docs. Ingest. Reject landing pages.

Week 2. Generate five issues. Review all of them with the 12-minute pass. Lock. Add at most two diagrams.

Week 3. Send to yourself and one friendly customer who agreed. Collect the questions they still asked in Slack. Those questions are missing issues or bad coverage.

A useful extra artifact is a “wrong on purpose” staging payload: unsigned webhook, expired timestamp, replayed idempotency key. If the customer cannot tell which failure they hit after issue 3, the issue taught the happy path only. Happy-path curricula create the loudest support threads.

Record those Slack questions as source memos and ingest them. Do not leave tribal answers in the founder’s head. That is the same hygiene as keeping a course updated when sources change.

Week 4. Patch, lock, define the activation metric. Only then discuss a consented audience. If that audience work is not done, keep it invite-only.

If you later hire a customer-education person, they inherit locks and citations, not a Drive folder of drafts. That is the point of treating the curriculum as a system. Compare how internal onboarding email courses name a domain owner: customer curricula need a product owner the same way.

Teach yourself system design is a useful rehearsal of the engine without customer risk. Team vs personal tells you when the rehearsal is over.

For production agents around this workflow, AI agent development is the service page. Keep send behind a person.

Frequently Asked Questions

Can founders really teach customers by email, or do they need an academy?

Email curricula work for a single job-to-be-done with five to twelve issues. An academy is for a catalog. Start with one job. Most “academies” are unmaintained CMS sites.

Is this the same as a product newsletter?

No. Newsletters broadcast change. Curricula sequence skill. Combining them trains customers to skim.

Does Cadensend send to my customer list?

Not as a bulk product. It is a self-hosted curriculum engine with exactly-once delivery to a verified recipient in the current design. Opt-in audiences are roadmap, gated on consent controls. It is not ConvertKit.

How do I keep the curriculum aligned with releases?

Hash sources, stale citing issues, review, lock. See keep course updated when sources change. Tie the ritual to your release tag.

What should I measure?

Whether the customer completed the job without a ticket: first verified webhook, first replayed payment, first rotated key. Open rate is a delivery health check, not a learning metric.

Should I let an LLM write the whole curriculum unsupervised?

Draft, yes. Send, no. Founders still freeze legal and pricing, and still catch overclaims. Read review AI lesson content.

Where do diagrams fit in customer email?

Public integration paths only, PNG with alt text, one concept per figure. Internal Kafka topologies do not belong in customer inboxes.

Conclusion

• One job per series, sourced from product docs, not from the homepage.
• Founders own the brief and the legal freeze. Models own drafts, not SLAs.
• Review like support will screenshot it. They will.
• Exactly-once teaching is not a blast campaign. Keep list ops separate.
• Cadensend is MIT, self-hosted teaching ops — not a bulk sender, not ConvertKit.

Want a customer curriculum engine on your corpus? Contact HinterBuild. About · LinkedIn.