After Hours Builders
RhythmMonthly updates

Community onboarding

Community launch kit for the first members.

Pinned onboarding, support lanes, and the first four build-along sessions for opening After Hours Builders without improvising the member experience.

Setup principles

Open with fewer moving parts.

  • Keep the live platform simple: course map, check-in format, support lanes, session calendar, and no-income-guarantee rules.

  • Send members toward one visible product path, not general tool chatter.

  • Use the same evidence format everywhere: current URL, intended behavior, actual behavior, blocker, and next action.

  • Keep billing, support, and private data issues out of public build threads.

  • Refresh vendor facts before publishing tool recommendations or monthly updates.

Pinned onboarding

Posts to publish before inviting members.

Pinned post

Start here: 30-day build map

Orient new members to the course sequence and stop them from starting with random tools.

  • Begin with Module 0 and the 60-Minute AI Builder Stack before changing your tools.
  • Move through the course in order: idea, build, ship, first 10 users, then the iterate-or-kill memo.
  • Use the templates as your working artifacts. The goal is one shipped path and evidence from real people, not a perfect app.
Open `/course`, complete the stack lesson, then save one Week 1 idea scorecard.
Pinned post

Weekly check-in format

Create a durable weekly rhythm that works in Skool, Discord, Circle, or any simple community platform.

  • Post one check-in each week with focus, status, what changed, blocker, and next step.
  • Make the next step concrete enough that another member can tell whether it happened.
  • Use check-ins for accountability and office-hours triage, not vague motivation.
Use `/member` once auth is live, or copy the same fields into the community thread until then.
Pinned post

How to ask for build help

Keep build-along support useful by requiring facts instead of vague debugging requests.

  • A good support post includes the current URL or screenshot, intended behavior, actual behavior, exact error, recent changes, and what you already tried.
  • Do not post private customer data, employer data, secrets, credentials, private keys, or payment details.
  • The first response should push toward the smallest verified fix, not a rewrite.
Paste the unsticking protocol from `/templates/unsticking-protocol` before asking for technical help.
Pinned post

Rules: no guaranteed outcomes

Protect trust, legal posture, and community quality before paid membership opens.

  • Members can share experiments, lessons, and outcomes, but not passive-income promises or job-replacement claims.
  • The membership sells a process, templates, support rhythm, and shipped artifact. It does not promise customers, income, employment, or business success.
  • Advice should respect after-hours constraints and avoid unnecessary platform churn.
Review `/terms` and `/privacy` before enabling checkout or posting paid community copy.

Support lanes

Keep help requests sortable.

Build help

Broken screens, harness confusion, prompt recovery, data model questions, and thin-build scope.

  • Current URL, screenshot, or file path.

  • Intended behavior.

  • Actual behavior or exact error.

  • Recent changes.

  • Smallest outcome needed before the next session.

Owner rule: Answer with one next diagnostic or fix; move billing/account issues to the private support lane.

Billing and account support

Checkout, refunds, membership access, login problems, email delivery, and protected downloads.

  • Account email.

  • What the member expected to access.

  • What happened instead.

  • Relevant timestamp.

  • No card numbers, passwords, secrets, or private keys.

Owner rule: Handle privately through the monitored support inbox; never ask members to post payment details.

Tool updates

Model, harness, access, routing, pricing, platform, and policy changes that may affect the course.

  • Vendor or product name.

  • Primary source URL.

  • What appears to have changed.

  • Whether it affects beginners now or can be delayed.

Owner rule: Check against the vendor fact sheet before turning a tool update into a recommendation.

Launch feedback

Landing pages, first-user outreach, copy clarity, objection logs, and iterate-or-kill decisions.

  • Target buyer.

  • Current promise.

  • Public URL or copy excerpt.

  • What users did or said.

  • Decision needed.

Owner rule: Separate claim-safety issues from product feedback, then ask what evidence would change the decision.

First four sessions

Make the opening month concrete.

Opening week

Session 1: Stack and scope kickoff

Every founding member has the stack PDF, one product folder, one notes file, and one problem inventory started.

  • Re-explain models, harnesses, and access layers.
  • Confirm what not to buy yet.
  • Walk through the build-bench setup template.
  • Have members post one boring-problem inventory.
Read Module 0, open the stack PDF, and create the product folder before the session.
Week 1

Session 2: Idea scorecard review

Members narrow to one reachable buyer, one current workaround, and one thin promise.

  • Review the boring problem scorecard.
  • Separate compliments from strong evidence.
  • Draft five validation questions.
  • Choose build, narrow, or discard for the first candidate.
Bring three scored problems and at least one conversation note.
Week 2

Session 3: Thin build lab

Members convert one promise into a route/component/data plan and one manual smoke test.

  • Translate the thin promise into one user path.
  • Use the thin build spec to block extra features.
  • Practice the unsticking protocol with one real or sample error.
  • Write the manual operating steps that remain after the build.
Bring a product spec, current app URL if one exists, and the exact blocker.
Week 3 or 4

Session 4: Ship and first-user review

Members have a safe public page, support path, disabled/live provider checklist, and first-user outreach plan.

  • Review landing page clarity and claim safety.
  • Check support path and provider gates.
  • Draft ten qualified outreach targets.
  • Plan the first iterate-or-kill evidence memo.
Bring a public URL or landing-page draft, support path, and one outreach draft.

Platform setup fields

Copy these into the live platform setup pass.

  • Live community URL

  • Support inbox

  • Pinned course map post

  • Pinned weekly check-in post

  • Pinned build-help format

  • Pinned no-income-guarantee rule

  • First four session dates

  • Monthly update owner

  • Billing/account support lane

  • Private data and secrets rule

Next setup action

Store the live community URL after platform approval.

Once Google auth and an admin profile are live, the final platform URL can be saved through the audited admin community settings panel.

Open admin