The Reality-Check Blueprint

Part 0. How to read this edition — and what Edition 1 got wrong

Edition 1 (/autoseo/) is a build log: it grew section by section as the machine was built, and it's a faithful record. This edition is different. It starts from the uncomfortable question — why is there a great machine and no revenue? — and reorganizes everything around the answer. Read Edition 1 to see how the machine works. Read this edition to see how the business works.

What Edition 1 got right

• The core reframe: account creation is one-time and human; posting is a solved API problem. Connect once, publish forever. That's real and it's now proven live.
• The subscription-only cost discipline. The whole machine runs on ~$24/month of new infrastructure, and nothing in it meters tokens.
• The honesty edge: a deterministic engine that refuses to fabricate is a genuine, defensible trust position in a market full of hallucinating tools.
• The Human Desk insight: the parts machines can't do (opening accounts, being accountable) are exactly the parts customers will pay a human-backed service to handle.

What Edition 1 got wrong — the five honest mistakes

1. Build-first bias. Fifty-plus prompts about building; almost none about selling. The plan kept adding capability to a machine no customer had asked for. This edition inverts that: every build item now exists to serve a named buyer.
2. Selling to "everyone." Eleven mirror sites pitching automated marketing to any small business is a customer of nobody. The correction: two niches — home building and polymagnetics — where a foothold already exists.
3. The $49 self-serve fantasy. A $49 price can't fund the human trust-building this product needs, and no distribution existed to deliver self-serve volume. The correction: partner-led, managed-service pricing.
4. Cold outreach as the default sales motion. Wrong — a five-year working relationship with our home-building industry partners already exists, with real collaborations behind it. You don't cold-email people you already work with; you bring them something concrete. This edition's first milestone is exactly that.
5. Platform breadth before client depth. Connecting every network matters less than making one client's presence excellent. Breadth is now sequenced behind the pilot, not ahead of it.

Part I. Where we actually stand — the verified inventory

Plain English: before planning anything, here is exactly what exists and works today, what exists but is unproven, and what does not exist at all. Everything in the first table was verified live on 25 July 2026.

I.1 — What exists and is proven

I.2 — What does not exist (the reality-check anchor)

• Paying customers: zero. No revenue from this product line.
• Billing: none. No way to take recurring money (Stripe exists elsewhere in the network but is not wired to this).
• A client portal: none. A client cannot see their calendar, approve a post, or read a report.
• Reports: none. Nothing shows a client what they got for their money.
• Multi-tenant operation: unconfigured. The hub currently runs as a single owner workspace; per-client workspaces are supported by the software but not set up.
• Facebook, Instagram, LinkedIn, Mastodon: not connected. (X and Bluesky are.) Meta and LinkedIn each require a developer app plus a multi-day review that has not been started.
• A content generator: not built. Today a human writes every post.
• An orchestrator: not built. Nothing runs the loop on a schedule.
• A written commercial arrangement with the partners: none recorded in our systems. The working relationship is real and five years deep; the deal for this product is a conversation that hasn't happened yet. TBD
• A named polymagnetics buyer: none recorded in our notes. The artifacts exist; the person to show them to has not been identified. TBD

Technical summary: the delivery layer (analyze → publish) is real and proven on two networks. The business layer (sell → onboard → bill → report → renew) is at zero. Every hour of work from here should go to the business layer or to the minimum delivery work a pilot demands — nothing else.

Part II. The reality check — market, competition, and the AI wave

II.1 — The diagnosis, restated plainly

This is not a product problem. The machine works — a post written on this desk reached thousands of real followers tonight through infrastructure we own. The problem is that nobody is asking for it, because nobody knows it exists, and the people who could know it exist haven't been shown a reason to pay. That is a demand, trust, and distribution problem. More features cannot fix it. Only two things fix it: a partner who already owns trust and distribution, or years of building both ourselves. We have the first option available. Most businesses don't.

II.2 — The competitive field, honestly

II.2b — Battlecards: every competitor a buyer will name, and the honest answer

When a builder or a magnetics company hears our pitch, they will think of something they already know. This is the card for each — what it costs, what it's genuinely good at, where it fails our buyer, and the one-sentence answer. The "where they beat us" column is deliberate: knowing it keeps us honest and keeps us out of fights we'd lose. Published prices are typical ranges as of mid-2026 and can drift. EST

II.3 — The AI wave, stated as a law

Notice that the two-niche partner strategy scores on all five. The generic SaaS strategy scores on none. That's the whole argument, and it's why this edition exists.

II.4 — Is there a path to profit? The honest verdict

Yes — one. Not "an AI marketing SaaS for small business" (saturated, undifferentiated, distribution-less: poor odds, roughly 5–10% EST). The path with real odds is a partner-channeled, niche-focused, done-for-you managed service where the machine does the work and the margins, and humans supply trust and accountability. With a live partner conversation available and working artifacts already delivered into that relationship, the odds of reaching a modest, genuinely profitable service business are materially better — our working estimate is 40–55% EST, with the biggest single variable being whether the pilot earns a "yes" from real builders. That is a subjective estimate and should be treated as one; Part IX defines the checkpoints that will replace guesses with evidence.

Part III. The strategy — two niches, one partnership, one sequence

III.1 — Niche A: Home building, through the partnership

Plain English. The home-building industry spends real money making new communities and homes visible. Our two partners built and led the company at the center of how American home builders do digital marketing, and the working relationship with them is five years deep, with delivered artifacts to show for it (the bejane.com rebuild; the three-design automated-marketing-department pitch built for them at deptless.com and automarketingdept.com). They hold exactly the two assets we lack: the industry's trust and distribution to its buyers. We hold exactly what complements it: a working machine that turns a builder's listings into an always-on, on-brand social presence at near-zero marginal cost.

The offer to builders (through or alongside the partners): "Every community and every home you list becomes a steady stream of on-brand posts across every social channel — automatically, with your team approving from their phone. No one on your staff logs into anything." Home building is close to the ideal case for our machine: the content is structured (listings: price ranges, plans, lot availability, amenities, location), visual (photos and renderings already exist), local (community-level audiences), and recurring (inventory changes weekly) — which means the deterministic content path produces genuinely good posts from facts, without fabrication risk.

What the partnership could look like — three shapes, in ascending commitment, all TBD until the conversation happens:

III.2 — Niche B: Polymagnetics, through demonstrated depth

Plain English. The programmable-magnetics world (Polymagnet and the companies around that technology) is small, technical, and starved for good marketing: the products are genuinely fascinating, the buyers are engineers, and generic AI copy about them is transparently shallow. We have already done the hard part once — the 10-page Polymagnet rebuild and the magnetics case file demonstrate we can write about this field credibly. That work is the door-opener.

The offer: "A consistent, technically credible presence — applications, case studies, product news — published across LinkedIn, X, and your site on a steady cadence, with your engineer's approval on every post." In technical B2B, consistency and credibility compound: a year of steady, accurate posting makes a small company look like the category leader.

Honest status: we do not have a named contact in this niche recorded in our notes. TBD The first to-do is identifying the right person (the Polymagnet technology's owners/licensees and adjacent magnetics manufacturers) and approaching them with the already-built case file as the credential — "we built this about your industry because we find it genuinely interesting; here's what a year of this looks like, automated." That is a warm approach built on demonstrated work, not a cold pitch.

Sequencing: Niche A first — its distribution already exists. Niche B runs one step behind, reusing every asset (portal, reports, templates) the pilot produces.

III.3 — Why exactly these two (the strategic logic, compressed)

• Both are specialized B2B, where generic AI output is weakest and niche depth is visible — the anti-commoditization ground from Part II.
• Both have an existing foothold: a five-year partnership in one; delivered technical artifacts in the other. We start from trust, not from zero.
• Both have structured content sources (listings; technical applications), which the deterministic engine can turn into posts without fabrication risk — our honesty edge becomes a selling point, not a constraint.
• Both are referral-dense: builders talk to builders; the magnetics world is a village. One delighted client is a channel.
• Both tolerate service pricing ($500–$2,500/month is normal B2B marketing spend), which funds the human accountability the product needs. EST

Part IV. The product — what we actually sell (and stop selling)

IV.1 — The definition

IV.2 — Product A: The Builder Presence Engine (home building)

IV.3 — Product B: The Technical Presence Engine (polymagnetics)

Same chassis, different content spine: instead of listings, the source material is applications, case studies, and product news, produced on a weekly/biweekly cadence with a mandatory expert-approval gate (an engineer signs off on every technical claim — our "never fabricates" rule made human). Lower volume, higher depth, LinkedIn-centered. Deliverables: cadence plan, per-post drafts from verified source material, publication, quarterly "authority report" (reach, engagement, inbound signals).

IV.4 — Pricing that matches the motion

IV.5 — The full pricing model EST final numbers set with partner input

Builder tiers (Niche A) — priced per builder brand, month to month

Magnetics tiers (Niche B)

The rules behind the numbers

• Pilot-to-paid mechanics: the day-60 review presents the builder's own numbers beside the tier that fits them; founding pilot clients get their tier at −20% locked for 12 months EST — a reward for early trust, not a negotiable discount.
• Never discount the service — discount the term. The price holds; what varies is how long a founding rate is locked. This keeps the offering's value intact as the roster grows.
• Payment: monthly card via Stripe, cancel anytime effective end of period; setup invoiced on acceptance. No annual prepay pressure — retention should come from the report, not the contract.
• Included in every tier: platform posting fees (X's pennies), infrastructure, monitoring, and the honesty guarantee. No surprise line items — one number a month.
• Partner economics TBD, modeled three ways in the day-60 conversation: referral ~20% of MRR for 12 months on introduced clients · reseller ~35% where the partner owns billing and first-line relationship · white-label ~50% where it runs under their brand and we operate. All three can coexist by client. EST
• Objection math, ready: against a $99 tool — "the tool is 11% of our price and does 10% of the job; the other 90% is the part your team keeps not having time for." Against a $3,000 agency — "we're the always-on layer at a third; keep the agency for campaigns, we'll happily coexist." Against free AI — "free needs a disciplined human weekly, forever; that human is what you're actually short of."
• Floor discipline: below $500/month the accountability promise can't be kept honestly (it stops funding human attention) — so there is no tier below it, only the free instrumented pilot, which is time-boxed and capped at 3 builders at once.

Part V. The user interface and flow — full analysis, current and target

Plain English: a marketing machine only produces results if the people around it can operate it without friction — the client approving posts, the operator running the system, the partner watching the portfolio. This part walks the entire flow as it exists today, names every gap honestly, then specifies the target experience screen by screen and shows exactly how the interface chain produces marketing results.

V.1 — The funnel today, stage by stage

V.2 — Screen-by-screen: what exists today (operator's honest tour)

• Family site → CTA: clean, credible, now with proper share previews. Verdict: good enough for the partner-led phase; not a growth engine by itself.
• /setup form: five fields, radio tiers, platform checkboxes. Functional. Submits into silence (no email, no next-step page) — must fix before any paying client touches it.
• Operator console: hd_admin.py — a CLI. Fine for us (list/show/approve/poll/verify/release all work); invisible to clients; will need a thin web wrapper only when someone other than the founder operates it. Not urgent.
• The hub (Postiz): login solid on HTTPS; Add Channel flow proven (Bluesky 4 clicks, X via our dev app); compose flow has the "Add to calendar" trap — it schedules to the next slot rather than posting, and the real "Post Now" is buried in a submenu. Decision: clients never touch this UI. It is back-of-house. The engine talks to it by API; humans see only the portal.
• Reports: none. The agent desk (automarketingagent.com) proves we can build data dashboards — that pattern gets reused per client.

V.3 — The target experience, screen by screen

The Client Portal (five screens, phone-first — because the builder's marketer lives on a phone)

┌─────────────────────────────────────────────┐
│ 1. TODAY (Approval Queue)      ● 3 waiting  │
│ ┌─────────────────────────────────────────┐ │
│ │ [photo] Cypress Grove — 3 new homesites │ │
│ │ "Three new homesites just released in   │ │
│ │  Cypress Grove from the $340s…"         │ │
│ │  → X · Facebook · Instagram   Tue 10:00 │ │
│ │  [ Approve ]  [ Edit ]  [ Skip ]        │ │
│ └─────────────────────────────────────────┘ │
│  swipe → next card. Under 60 seconds a day. │
├─────────────────────────────────────────────┤
│ 2. CALENDAR — month view of queued/sent     │
│ 3. RESULTS — this month: posts, reach,      │
│    engagement, top post, GA clicks          │
│ 4. CHANNELS — connected accounts, health    │
│ 5. SETTINGS — voice, cadence, approvers     │
└─────────────────────────────────────────────┘

• Screen 1 — Approval Queue (build first). Card per pending post: image, text, channels, scheduled time; Approve / Edit / Skip. One design rule: a full day's approvals in under sixty seconds on a phone. Technical: a thin web app (plain HTML/JS, no framework needed) against a small API over the hub's Postgres — posts in a pending_approval state that the engine writes and the hub only publishes once approved. Approval-by-reply email as fallback for the phone-averse.
• Screen 3 — Results (build second). Monthly: posts published, per-channel reach/engagement, top post, site clicks (GA), simple deltas vs last month. Never a vanity wall — five numbers a builder cares about. Doubles as the renewal instrument and the referral prompt.
• Screens 2/4/5 are read-mostly and can ship in v2 of the portal.

The Operator Console (us)

Orders board (today's CLI, webbed later), per-client health (last post, next post, queue depth, token expiry warnings), Human Desk queue, and the existing uptime/backup monitors. Nothing here blocks the pilot; the CLI carries us months.

The Partner View (the partners' window) TBD

One page: every builder in the program, posts this month, engagement trend, status green/amber. This is how a referral partner sees the portfolio working without asking us. Cheap to build off the same data as Screen 3; disproportionate relationship value.

V.4 — How the interface chain produces marketing results (the causal spine)

Illustration of the cadence math (labeled EST, not a promise): a builder with 6 active communities and a 4-posts/week cadence ships ~200 posts a year with roughly 15 minutes a week of client attention — a volume and consistency no human social manager maintains at this price, and the exact thing the machine does for pennies. The pilot's job is to replace this estimate with that builder's real numbers.

V.5 — UX build order (ruthless)

1. Approval Queue v1 (cards + Approve/Edit/Skip + email fallback) — before the pilot's second week.
2. Weekly digest email (automated) — week 1 of pilot; a manually-assembled one is acceptable for week 1.
3. Results page v1 — before day 30 of the pilot (it powers the day-30 review).
4. Fix the /setup dead-air (thank-you page + email) — before any paid order.
5. Everything else (calendar, settings, partner view, operator web console) — after the pilot proves demand.

V.6 — The first thirty days, day by day (the client journey we're committing to)

This is the experience a pilot builder signs up for, hour-for-hour honest about whose time gets used. Total client time in month one: about 75 minutes, most of it in two short calls.

Two design commitments hiding in this table: nothing in month one requires the client to learn a tool (the hub stays back-of-house; they see only the approval cards and the reports), and every claim of progress is measured against a baseline captured before we touched anything — the honesty rule applied to ourselves.

V.7 — The UI issues register: every interface problem we know about, with severity and fix

A product that lives or dies on "under a minute a day" lives or dies on interface quality. This register lists every UI issue currently known across all surfaces — including the ones we hit ourselves, tonight, as real users — each with severity, the fix, and the phase that owns it. Severity: S1 blocks a user or loses money · S2 causes confusion or wasted time · S3 polish. Issues found by actually failing are marked ⚡ (observed live) — they are the most trustworthy items on this list.

V.8 — Complete wireframes and interaction specs (all screens)

Portal Screen 1 — Approval Queue (build first; acceptance criteria below)

┌──────────────────────────────────────┐
│ Meadow Creek Homes      ● 3 waiting  │   ← client brand, count badge
├──────────────────────────────────────┤
│ ┌──────────────────────────────────┐ │
│ │ [listing photo]                  │ │   ← their real photo, full-bleed
│ │ Cypress Grove — 3 new homesites  │ │
│ │ "Three new homesites just        │ │
│ │  released from the $340s…"       │ │   ← full text, no truncation
│ │ ⓧ ⓕ ⓘ            Tue 10:00 AM   │ │   ← channels + time, plain
│ │ ┌─────────┐ ┌──────┐ ┌────────┐  │ │
│ │ │ Approve │ │ Edit │ │  Skip  │  │ │   ← 44px+ targets, thumb reach
│ │ └─────────┘ └──────┘ └────────┘  │ │
│ └──────────────────────────────────┘ │
│  … next card …                       │
│ ┌──────────────────────────────────┐ │
│ │ ✓ Approve all 3 remaining        │ │   ← batch action, end of list
│ └──────────────────────────────────┘ │
├──────────────────────────────────────┤
│ Today · Calendar · Results · More    │   ← 4-tab bottom nav
└──────────────────────────────────────┘
Interactions: Approve = one tap, card collapses to a green check.
Edit = textarea inline, Save approves. Skip = 4 reason chips
(wrong tone / wrong fact / wrong timing / other), then collapses.
Empty state: "Queue clear — next posts generate {day}." + last
3 published posts. Auth: magic link, 7-day, one client scope.

Portal Screen 2 — Calendar (read-mostly, v2)

┌──────────────────────────────────────┐
│ July      ◀  ▶            [month|wk] │
│ Mo Tu We Th Fr Sa Su                 │
│  ·  ●  ●  ●  ●  ●  ○   ● sent/queued │
│ tap a day → its posts, status chips: │
│ SENT ✓ · QUEUED · AWAITING YOU ⚠     │
│ "AWAITING YOU" taps through to the   │
│ queue — calendar never dead-ends.    │
└──────────────────────────────────────┘

Portal Screen 3 — Results (the renewal screen)

┌──────────────────────────────────────┐
│ July results        [share] [print]  │
│ ┌───────┐┌───────┐┌───────┐          │
│ │  22   ││ 14.2k ││  312  │          │
│ │ posts ││ reach ││ engmt │          │
│ └───────┘└───────┘└───────┘          │
│ ┌───────┐┌────────────────┐          │
│ │  87   ││ TOP POST       │          │
│ │ clicks││ [photo] +test  │          │
│ └───────┘└────────────────┘          │
│ vs June: posts = · reach ▲12% ·      │
│ clicks ▲9% (every number sourced;    │
│ platform-hidden metrics say so)      │
│ ── "Know another builder who should  │
│    see this? Reply to this report." ─│
└──────────────────────────────────────┘

Portal Screens 4–5 — Channels & Settings (v2)

CHANNELS: one row per account — icon, handle, big status dot
(green OK / amber "needs re-connect — tap to fix" with the OAuth
link right there / grey off). No error codes, ever.
SETTINGS: voice words, banned words, cadence slider (min→max per
tier), approvers (add by email → magic link), pause button
("pausing stops posts, not your subscription — resume anytime").

Operator console (us; thin web wrapper in Phase 4)

ROWS = clients. COLS: last post · next post · queue depth/age ·
token health · cadence % · MRR · flags. Click-through to the same
portal the client sees (impersonation-view, read-only, logged).
Top strip: infra (hub, certs, backups, X credit, Temporal).

Partner view (Phase 3+, TBD with partner)

One page, their logo: portfolio table (builder · posts this mo ·
reach trend sparkline · status dot) + a quarterly rollup line.
Read-only, magic-link, revocable. Purpose: the partnership's
health visible without anyone writing a status email.

V.9 — UX acceptance tests (measurable, phase-gated)

These are pass/fail gates, tested with a real person (the founder counts; a pilot client is better) on a real phone. A failed test blocks the phase gate the same way a failed code test would.

Part VI. The build plan — resequenced around the partnership

The sequencing principle: every phase ends at a human milestone (a demo shown, a pilot live, a price agreed), not a technical one. Platform approvals run in parallel from day one because their clock is the longest and not ours.

Part VII. The refined prompt library

How to use this part: each prompt below is written to be pasted directly into a Claude Code session on this network (it assumes our stack, paths, and rules). Plain-English purpose first, then the paste-able text. Statuses of the P53–P71 set from Edition 1 are listed first for continuity; the new P72–P80 set operationalizes this edition.

VII.1 — Status board (from Edition 1)

VII.2 — The new prompts (P72–P80), full text

Build the builder demo for the partner working session.
Context: Postiz hub live at postiz.wholetech.com (X + Bluesky connected);
direct-publish scripts postx.py/postbsky.py proven on the postiz droplet.
1. Create a dedicated "Builder Demo" workspace/context in the hub.
2. Pick ONE real, public new-home community page from a large production
   builder. Extract only public facts (community name, city, price range,
   plan names, amenities). Do not invent numbers or availability.
3. Write 6 posts from those facts: 2 new-release announcements, 2 amenity/
   lifestyle spotlights, 1 price-range post, 1 "why this location" post.
   Every post labeled SAMPLE in the demo view (not in any live post).
4. Queue all 6 in the hub with realistic spacing across a demo week.
5. Prepare TWO live-fire posts (generic, non-builder-branded versions) to
   publish to our own @springnet X + Bluesky DURING the demo, proving the
   pipe end-to-end in front of the partners.
6. Produce a one-page leave-behind (HTML + print CSS): the offer in plain
   English, the causal chain (approve → cadence → presence → leads →
   report), pilot ask ("give us two builders for 60 days"), and honest
   costs. No fabricated metrics anywhere — use "the pilot will measure X".
7. Write the 15-minute walkthrough script: 2 min problem, 5 min live demo,
   3 min approval-queue mockup, 3 min pilot ask, 2 min questions.

Build the deterministic builder-content generator.
1. Define a normalized listing schema: community, builder brand, city/area,
   status (now selling / coming soon / final homes), price_from, plans[]
   (name, beds, baths, sqft), amenities[], photo_urls[], page_url.
2. Ingest adapters, in priority order: (a) manual CSV/JSON (pilot-ready
   day one), (b) page scraper per builder site template, (c) feed if the
   partner ecosystem exposes one (TBD).
3. Template library v1 — at least 12 templates across 5 families:
   new-release, price-point, plan spotlight, amenity/lifestyle, milestone.
   Templates fill ONLY from schema fields; if a field is missing the
   template is ineligible (never guess). Rotate phrasing variants to avoid
   repetition; track last-used per builder.
4. Per-builder brand profile: tone words, banned words, emoji policy,
   hashtag set, required disclaimers, link/UTM pattern.
5. Output: post objects {text, image_url, channels[], proposed_time}
   written to a pending_approval store (feeds P74).
6. Hard rule inherited from the engine: no invented facts, no invented
   urgency ("only 2 left!" requires a status field saying so).
Test: run against the P72 demo community; generate 20 posts; hand-review.

Build client-portal v1: the Approval Queue.
1. Storage: pending_approval posts (from P73) in the hub droplet's
   Postgres, keyed by client workspace. States: pending → approved |
   edited+approved | skipped; audit trail on every transition.
2. UI: phone-first single-column card feed (plain HTML/CSS/JS, no
   framework): photo, post text, channel icons, scheduled time;
   buttons Approve / Edit (inline textarea) / Skip. Batch "Approve all
   remaining" at the bottom. Target: full day's queue in <60 seconds.
3. Auth: per-client magic-link (signed token, 7-day expiry) — no
   passwords for clients. HTTPS on portal.wholetech.com or
   /portal/ on the hub droplet's nginx.
4. Publish handoff: approved posts flow to the hub scheduler (or the
   direct-publish scripts) at their proposed_time. Skipped posts logged
   with optional reason (feeds P66 later).
5. Email fallback: daily digest email listing pending posts with
   one-click approve links (same signed-token mechanism).
6. Safety: nothing publishes unapproved while a client's require_approval
   flag is true (default true, always true during pilot).

Build the reporting layer.
1. Post log: every published post recorded {client, channel, url, time,
   template_family}. Engagement pulled per channel where the API allows
   (X counts are pay-per-use reads — batch weekly, budget-capped;
   Bluesky/Mastodon free; FB/IG/LinkedIn once connected).
2. GA integration: UTM-tagged links per post; pull sessions/clicks per
   campaign from the existing GA property.
3. Weekly digest email (client-facing, plain English): posts that went
   out, best performer, next week's plan. Assemble automatically; allow
   one human sentence on top.
4. Monthly results page (portal Screen 3) + print CSS for PDF: five
   numbers a builder cares about — posts published, total reach EST,
   engagements, site clicks from social, top post — with deltas vs
   prior month and zero vanity padding. Include the standing referral
   line. Every number traceable to its source; if a platform hides a
   metric, say "not exposed by platform" rather than estimating.

Prepare the white-label option (build only after partner interest):
1. Brandable portal: logo, colors, product name per tenant via config;
   partner domain CNAME + cert automation.
2. Tenant hierarchy: partner → clients → workspaces; partner-level
   portfolio view (posts, engagement, health per builder).
3. Billing split support in Stripe (partner share as negotiated).
4. Operational isolation: per-tenant backups and export (a partner must
   be able to leave cleanly — that clause builds trust going in).

Build the technical presence engine for the magnetics niche.
1. Content spine: source-material intake (client's application notes,
   spec sheets, case studies, product pages) → a verified-facts store
   per client. Posts may cite ONLY the verified store.
2. Cadence: 2–3 posts/week, LinkedIn-primary (once P57 lands), X
   secondary; monthly longer-form piece for the client's own site.
3. Expert gate: every post requires named-human approval (the client's
   engineer) via the P74 queue — no exceptions, ever, for technical
   claims. Surface the source snippet next to each draft for one-glance
   verification.
4. Re-use our existing artifacts (the 1.deptmatic Polymagnet rebuild,
   c.deptmatic case file) as the pitch portfolio; refresh both before
   any outreach.
5. First business task (human, not code): identify the named buyer —
   Polymagnet technology owners/licensees and adjacent magnetics
   manufacturers; log candidates in the CRM note file. TBD.

Instrument the pilot.
1. Baseline capture BEFORE first post, per builder: follower counts per
   channel, posts in prior 90 days, GA social sessions prior 90 days.
2. Weekly snapshot job: same metrics + our post/approval/skip counts,
   time-to-approve, cadence adherence. Store as JSON; chart on a simple
   internal page.
3. Skip-reason taxonomy (wrong tone / wrong fact / wrong timing / other)
   — every skip is free product feedback.
4. Day-30 and day-60 review docs auto-drafted from the data: what went
   out, what changed vs baseline, what clients did (approval behavior),
   open issues, and an honest "is this working?" section the founder
   edits by hand before any partner sees it.

Build the proposal generator.
Input: builder name, community count, channels, chosen cadence, setup
needs (accounts to open), pilot results if available.
Output: one-page HTML (+print CSS) proposal — their numbers from the
pilot (real, sourced), the service definition (approve from your phone;
we do the rest; monthly report), price per the rate card ranges, what
happens in week one, and a plain-English no-lock-in clause (month to
month, your accounts stay yours — a differentiator worth stating).
No fabricated projections: if pilot data exists, show it; if not, show
the causal chain and say "the first 60 days will measure this."

Write and wire the onboarding runbook.
Checklist per new client, each step logged with owner + timestamp:
1. Intake: brand profile (P73 §4), listing source, channel inventory.
2. Accounts: existing → connect (client OAuth, guided call or link);
   missing → Human Desk order (P50) under identity/phone policy (P55).
3. Workspace: create in hub (P60), map channels, set cadence + approval
   flag, load templates.
4. Baseline: run P78 §1 capture.
5. First week: generate first batch (P73), client approves (P74), posts
   flow; day-7 check-in email auto-drafted.
Wire steps 3–5 into scripts; keep 1–2 human. Target: <1 day labor.
Publish the runbook as an internal page so a future VA can run it.

VII.3 — The critical five from Edition 1, expanded to full text

Build the publish adapter that lets our systems post through the hub.
1. Module publish.py on the hub droplet: publish(client, post) → routes
   to Postiz API (scheduled) or direct scripts (immediate); returns
   {post_url, channel, ts}; retries 3x with backoff; failure → operator
   alert (existing ntfy), never silent.
2. Per-client channel map (workspace → integration ids) in one config.
3. Queue semantics: everything flows THROUGH pending_approval (P74)
   unless client flag require_approval=false (never during pilot).
4. Log every publish to the post log (P75 §1).
5. X cost guard: count X posts/month per client; warn at threshold
   (subscription-discipline habit applied to the $25 X credit).

Build the content module with two lanes, respecting the network's
subscription-only rule (no pay-per-token API, ever):
LANE 1 (deterministic, daily): P73 templates over structured facts —
the drumbeat. Zero marginal cost, zero fabrication risk.
LANE 2 (batched, weekly): one Claude Code session per week generates/
refreshes spotlight posts for ALL clients in one cached run — seasonal
angles, local events (verified sources only), template variants.
Output of both lanes lands in pending_approval; nothing publishes
itself. Lane 2 outputs carry a source note per post for the approver.
Measure: % of Lane-1 posts approved unedited (target >80%); skip
reasons feed template fixes (P78 §3).

Enforce the honesty brand promise in code.
1. Fact rule: every factual claim in a post must trace to a schema field
   (Lane 1) or a verified-source note (Lane 2). Fail → post not created.
2. Banned-pattern lint: fake urgency without status data, superlatives
   without source, competitor disparagement, fair-housing-sensitive
   phrasing for builder content (flag for human, never auto-fix).
3. Brand lint per client: banned words, required disclaimers, emoji/
   hashtag policy (from P73 §4).
4. Cadence sanity: per-channel daily caps, quiet hours, no duplicate
   text within N days.
5. When unsure, don't post: any lint uncertainty routes the post to
   pending with a visible flag instead of publishing.

Build the per-client loop runner on the hub droplet (cron first;
Temporal if complexity earns it):
Daily per client: ingest listing changes → generate eligible Lane-1
posts → queue to pending_approval → send approval digest if queue>0
→ publish approved at scheduled times → log.
Weekly: engagement pull (budget-capped for X) → snapshot (P78) →
digest email (P75).
Monthly: results page refresh + report PDF + renewal/referral prompt.
Every step idempotent and individually re-runnable; every failure
alerts (ntfy) with client + step; a stalled client (no posts 7 days)
is an ALARM, not a silence.

Codify the permanent human gates:
1. Client posts: gated by P74 while require_approval=true (pilot:
   always). Relaxable per client ONLY by the founder, in writing.
2. Money: no charge, refund, escrow release, or payout without an
   explicit human --confirm (Human Desk rule, extended to Stripe).
3. New accounts: only via Human Desk under the identity policy (P55);
   the machine never self-registers client accounts.
4. Technical claims (magnetics): named-expert approval, no relaxation
   flag exists.
5. The engine's own social (@springnet etc.): founder approves; the
   flagship account is never on autopilot.
Log every gate decision; review the log monthly.

VII.4 — The remaining prompts, written out in full

These complete the library: every still-queued prompt from Edition 1 now has paste-able text. (P56 is wired; P61 merged into P75; P62 done; P64 folded into P69.)

Stand up the Social Ops VA desk.
1. Hiring spec (post to OnlineJobs.ph and one US VA agency for comparison):
   fluent written English, social-platform account admin experience,
   detail discipline; ~10 hrs/wk to start; $6-9/hr PH or ~$1k/mo US EST.
2. Their queue = the Human Desk (hd_admin) + the onboarding runbook
   (P80) steps marked HUMAN. They never touch money, API keys, or the
   founder's accounts (P70 gates apply to them too).
3. SOPs to write before day one: account creation under the identity
   policy (P55), evidence submission, client email templates (kickoff,
   nudge, day-7 check-in), escalation rules ("when unsure, stop and ask").
4. QA: founder reviews 100% of their work weeks 1-2, then 20% sampled;
   trust score tracked like any pool operator (P51 pattern).
5. Payment via the pool ledger — logged, founder-confirmed, never
   automated.

Create and wire the LinkedIn app.
1. Founder (browser): linkedin.com/developers → Create app. App name
   "WholeTech Publishing Hub"; company page: create one for the product
   first if none exists (a Company Page is REQUIRED to own an app).
   Privacy policy URL: https://automarketingengine.com/privacy/
2. Auth tab → Authorized redirect URLs — add BOTH:
   https://postiz.wholetech.com/integrations/social/linkedin
   https://postiz.wholetech.com/integrations/social/linkedin-page
3. Products tab → request "Share on LinkedIn" + "Sign In with LinkedIn
   using OpenID Connect" (usually instant) and "Community Management
   API" (review; needed for organization-page posting - scopes
   rw_organization_admin, w_organization_social, r_organization_social).
   Review answer: "Self-hosted publishing dashboard; posts only content
   our authenticated clients approve to pages they administer; no data
   resale; privacy policy linked."
4. Founder runs /opt/postiz/set-linkedin-keys.sh (client ID + secret;
   installer already staged).
5. Verify: hub Add Channel → LinkedIn shows and OAuth round-trips.

Create and wire the Meta app (founder answer-sheet exists in session
notes; installer /opt/postiz/set-meta-keys.sh is staged).
1. Founder: developers.facebook.com → Create App (type Business) →
   add Facebook Login for Business; Valid OAuth Redirect URI:
   https://postiz.wholetech.com/integrations/social/facebook
   Basic settings: app domains postiz.wholetech.com; privacy
   /privacy/; terms /terms/; data-deletion /privacy/#data-deletion.
2. Founder runs set-meta-keys.sh with App ID + Secret.
3. IMMEDIATELY usable (dev mode): connect founder-admin'd FB Pages +
   IG professional accounts. Do this the same day for proof.
4. App Review (for client accounts): request pages_show_list,
   pages_manage_posts, pages_read_engagement, pages_manage_engagement,
   business_management, read_insights, instagram_basic,
   instagram_content_publish, instagram_manage_insights.
   Prepare: 3-min screencast of the connect+approve+publish flow on a
   test page; reviewer test instructions; business verification docs
   (business portfolio required at this step).
5. Track review status weekly; add channels to pilot digests as they
   land.

Configure multi-tenant operation.
1. Use Postiz organizations/workspaces: one per client, named
   ""; owner login stays ours; clients NEVER get hub
   logins (they get the portal).
2. Config file /opt/postiz/clients.json: slug, workspace/org id,
   integration ids per channel, cadence, require_approval, brand
   profile path, listing source. Single source of truth for P59/P69.
3. Isolation checks (scripted, run weekly): no integration id appears
   in two workspaces; every post log row carries the right client slug;
   portal magic-links scope to exactly one client.
4. Backup note: nightly pg_dump already covers all workspaces; add
   per-client export script (their posts + reports as a zip) — the
   clean-exit promise from the terms.

Build the template feedback loop.
1. Every post carries template_family + template_id in the post log.
2. Monthly per client: engagement rate and click-through by
   template_family vs that client's median; skip-rate and edit-rate
   by family from the approval log (P74 data).
3. Weighting rule (simple, explainable): families >1.5x median get
   +25% selection weight next month; families <0.5x median for two
   consecutive months get flagged for rewrite; skip-reason "wrong
   tone" twice on one family → auto-flag for brand-profile review.
4. Never auto-delete a family — flags go to a monthly 15-minute
   human template review (us), decisions logged.
5. Report hook: "what we changed and why" one-liner appears in the
   client's monthly report — improvement made visible.

Wire Stripe subscriptions (build now, activate at G3).
1. Products: builder-starter/growth/portfolio, magnetics-presence/
   authority; monthly prices per the rate card; one-time setup SKUs
   $199/$399. Founding-pilot coupon: -20% x12 months.
2. Payment links (no custom checkout needed v1): one link per
   tier, sent with the proposal (P79); metadata carries client slug.
3. Webhook receiver on the hub droplet: checkout.session.completed →
   mark client active in clients.json + notify (ntfy);
   invoice.payment_failed → dunning email + operator alert;
   customer.subscription.deleted → offboarding checklist trigger.
4. Money gates (P70): refunds and plan changes are founder-manual in
   the Stripe dashboard, never API-automated. Recurring charges are
   client-authorized by the subscription itself.
5. Bookkeeping: monthly Stripe payout summary appended to a simple
   revenue log page (internal, auth-protected).

Automate the onboarding runbook (P80 stays the spec).
1. Intake form (private link per new client) → writes the brand
   profile JSON + clients.json entry directly; founder reviews diff
   before commit.
2. Channel connect: generate the client's guided-connect page —
   one button per channel, each opening the right OAuth flow into
   their workspace; progress checkmarks stored per channel.
3. Missing accounts: intake gaps auto-draft Human Desk orders
   (pending_review as always — dispatch stays human-approved).
4. Baseline capture (P78 §1) fires automatically when the last
   channel connects; first content batch (P73) generates the same
   night; guided-approval call gets calendar-booked by email.
5. Definition of done: from signed yes to first live post in <7 days
   with <1 day of our hands-on labor, measured and logged per client.

Build the ops watchdog (extends the existing 5-min health-check).
1. Per-client heartbeats: last post published, next post scheduled,
   pending-approval queue depth + age. Alarms: no post in 7 days;
   queue item older than 72h (client nudge email + operator ping).
2. Token health: X/LinkedIn/Meta token expiry probes weekly;
   re-auth needed → operator alert BEFORE posts fail, with the
   client's guided-reconnect link ready.
3. Infra: hub uptime (exists), cert expiry (certbot + probe),
   nightly backup success (file age check), disk headroom, Temporal
   liveness, X credit balance vs monthly burn.
4. All alerts → existing ntfy channel, severity-tagged; weekly ops
   digest (one email: every client green/amber/red + infra summary).
5. The rule from the blueprint: a stalled client is an ALARM, not a
   silence. No system state may be quiet and broken at once.

Part VIII. Economics — costs, pricing, and what the money can look like

VIII.1 — What it costs to run (verified)

VIII.2 — Unit economics, illustrated EST

One builder at $750/month: infrastructure share is a few dollars; X fees perhaps $2–4; the real cost is residual human attention (approval nudges, report glance, occasional fix) — call it 1–2 hours/month once Phase 4 lands. Gross margin runs ~90%+. Ten builders ≈ $90,000/year on the same $24 droplet. Twenty at a blended $900 ≈ $216,000/year. With a 40% partner share on partner-sourced clients, ten partner-sourced builders still net ≈ $54,000/year to us. All of these are arithmetic on assumed prices, not forecasts — the pilot and the partner conversation set the real numbers. TBD

VIII.3 — Break-even and the honest floor

Break-even on new cash costs is one client at any plausible price (the hub costs $24/month; a single $500/month client covers it twenty times over). The floor case — no partner deal, one or two direct clients — is still a profitable micro-service that pays for the whole network's infrastructure. The ceiling case runs through the partner channel. The difference between floor and ceiling is not code; it is the Part III conversations.

VIII.2b — Twelve-month scenarios, cost stacks, and sensitivity EST throughout — arithmetic on assumed prices, not forecasts

Three scenarios, quarter by quarter (monthly recurring revenue)

The cost stack at three sizes (monthly)

Sensitivity — which assumptions actually matter

• Price point ($500 vs $1,000 average): changes scale, not viability — break-even stays at one client either way. The pilot's job is to discover which number the market bears; do not guess it downward in advance.
• Churn (the big one): at 8 clients, losing one per quarter caps growth near 10–12 clients; keeping annual churn to 1–2 makes every scenario above conservative. This is why the monthly report and the day-by-day first-month experience get build priority — retention is a product feature, not a sales activity.
• Partner share (20% vs 50%): at 50%, twenty partner-sourced clients net about the same as ten direct ones — and arrive with near-zero sales effort. Any share is worth it while distribution is the scarce asset; renegotiate from evidence at scale, not from fear at the start.
• Onboarding labor: if a new client costs 3 days instead of <1, growth stalls at the founder's calendar long before it stalls at demand. P68/P80 are growth infrastructure, not conveniences.
• X read costs: engagement pulls are budget-capped by design (P75); the cap turns a variable risk into a fixed line item.

What we will not spend on (the discipline list)

• No paid advertising until referral + partner channels saturate — every scenario above works without a single ad dollar.
• No hires beyond the VA desk until MRR clears $10k for two consecutive months.
• No annual-prepay discounting to juice cash — it trades retention truth for optics.
• No new infrastructure ahead of load — the $24 droplet carries the Base scenario whole.
• And the standing rule everything inherits: no pay-per-token API billing, ever — content scales through the deterministic lane and the weekly batched session, inside the flat subscription.

Part IX. Odds, risks, and the gates that replace guessing

IX.1 — Updated odds table (subjective, labeled as such EST)

IX.2 — The honest risk register

• Partner priorities. The partners run a big world; this may not be their front burner. Mitigation: make the ask small (one working session, two pilot builders), the demo undeniable, and the pilot zero-effort for them.
• Pilot indifference. Builders may approve posts for 60 days and still not pay. Mitigation: instrument everything (P78) so we learn why; the day-60 review either prices the offer or redirects it (white-label may fit where direct billing doesn't).
• Platform reviews stall. Meta/LinkedIn approvals can drag. Mitigation: started in week 1; pilot launches on X + Bluesky + Mastodon and adds channels as they land; the report shows channel additions as delivered momentum.
• Content quality drift. A spam-cannon impression kills the trust position permanently. Mitigation: P65 guardrails, approval gates, and the >80% approved-unedited metric watched weekly.
• Single-operator dependency. The whole system currently runs through one founder. Mitigation: boring technology, runbooks (P80), documented gates, and the VA path — build everything as if someone else will run it next year.
• Continued AI commoditization. The task keeps getting cheaper for everyone. Mitigation is structural: we sell trust, accountability, and niche depth — the parts that don't commoditize — and the cost base is already near zero.

IX.3 — Decision gates (dates set when Phase 1 books)

Part X. The 30/60/90 — who does what, starting now

X.1 — The founder's list (the human work only a human can do)

1. This week: message the partners — not a pitch, a show-and-tell: "The machine is live and posting; I want 30 minutes to show you something built for builders." Book the working session.
2. Approve the demo community choice and the leave-behind copy (P72 output).
3. Hold the session; ask for two pilot builders; agree the day-30/60 review dates.
4. Polymagnetics: one thinking session to name candidate contacts; log them. TBD
5. Decide the canonical product domain (recommendation: automarketingengine.com).
6. Approve pricing before any proposal goes out (ranges in Part IV are estimates until you set them).

X.2 — The machine's list (build order, mapped to prompts)

X.3 — The single next action

Part XI. The whole story, in plain English — exactly what happened, and why

This last chapter retells everything in this document in everyday language — no jargon, nothing left out. If you read only one part, read this one.

What we set out to do

The goal was to build a marketing machine: a system that takes care of a business's online presence — especially social media — automatically, so the owner doesn't have to. Write once, publish everywhere, measure what happened, get better over time. And then to sell that as a service to other businesses for a monthly fee.

What actually got built (and works — you can click every one of these)

• The analyzer. A program that reads any website and scores it — and is built so it cannot make things up. Every number it reports comes from something it actually measured. This "never guesses" rule turned out to be the most valuable idea in the whole project, because most AI tools do guess, and businesses are starting to notice.
• The publishing hub. A control panel on its own small rented computer ($24/month) that can post to social networks. It's ours — no software fees, no limits.
• Real accounts, really posting. The hub is connected to a real X (Twitter) account with thousands of followers and a real Bluesky account — and both have published live posts through the machine. This proved the whole pipe works, end to end, with real audiences.
• The human desk. Some things machines aren't allowed to do — like opening new social media accounts, which platforms require a real person for. So there's a system for hiring and managing real people to do those steps properly, with the money always requiring a human's explicit approval.
• The demo. A working demonstration built for the home-building industry: real posts written from a real Texas community's published facts, shown in a phone screen where you tap Approve, Edit, or Skip. Its best moment is a post the machine refused to write — because it couldn't verify the price. That refusal, shown live, is the sales pitch.
• The client portal — built today, working now. This was the biggest missing piece: the screen a paying customer actually uses. It now exists for real, not as a mock-up: the machine writes posts from listing facts, they appear in a phone-friendly approval queue behind a private link, the customer taps Approve or Skip, and at the scheduled time the machine publishes what was approved and logs everything. Weekly and monthly report pages are generated automatically, and they only ever show numbers we actually have.

What went wrong — and why there are no customers yet

Here is the uncomfortable truth this document exists to face: we built the machine before we found the customers. It's the most common mistake in business — "build it and they will come." They don't come. Nobody knew the machine existed, nobody had a reason to trust it, and it was being offered to "any small business," which is the same as offering it to no one in particular. On top of that, the price was set at $49 — too little to pay for the human attention that earns a stranger's trust. So: great machine, empty street. Not a failure of the product; a failure of the selling — which had simply never been done.

Why the plan had to change — the AI problem

There's a bigger force at work too. AI tools now let anyone generate a month of social media posts for free in a few minutes. That means "we'll write and post your content" is no longer worth much on its own — the task itself has become nearly free, for everyone. So a business built on doing that task is standing on melting ice. What AI cannot give people for free: a trusted relationship, access to buyers, a real person who's accountable, deep knowledge of one industry, and someone to do the annoying human parts. Any durable business must be made of those five things, with the machine hidden inside making the costs low.

The new plan, in one paragraph

Stop selling a tool to everyone. Start delivering a finished result — "your company visible everywhere, automatically, and you just approve from your phone" — to two specific industries where trust already exists: home building, through a five-year working relationship with two senior partners at the center of that industry's marketing world; and magnetics, a technical field where we've already demonstrated real understanding. Charge real service prices ($500–$1,500 a month for builders), prove it with a free 60-day trial run for two builders the partners choose, measure everything honestly, and then set final prices from the evidence. Grow by referral. It won't be a tech empire — it can be a genuinely profitable small business with costs under $100 a month and margins above 90%.

What happened in tonight's build — including what broke, and why

Building honestly means recording the failures too, because each one taught something:

• The sign-in page had a trap. The hub showed a "Continue with Google" button that wasn't set up — clicking it (which you did) produced a scary error. Why it happened: the software ships with that button visible whether or not it's configured. Lesson now written into policy: clients never see that screen at all; they get a simple private link instead — no passwords, no buttons that lie.
• Logins silently failed at first. Before the hub had a proper secure address (https), the browser refused to remember the login — it just bounced back to the sign-in screen with no explanation. Why: browsers deliberately distrust insecure addresses. Fix: a real domain with a security certificate. Rule created: nothing user-facing ever runs on a bare numeric address again.
• Our first post vanished into the calendar. The hub's compose screen has a button called "Add to calendar" that schedules the post for later instead of posting it — and the real "Post now" is hidden in a submenu. Even we were fooled; the post quietly queued for midnight. Fix: the machine now publishes through its own direct route, and customers never touch that confusing screen.
• Today's portal had a freeze bug. When a post was approved, two parts of the program tried to write to the same small database at the same instant — one recording the approval, the other recording the audit note — and they locked each other out, like two people grabbing the same doorknob. The approval appeared to fail. Why it happened: an ordering mistake in brand-new code, caught within minutes because we test everything live before a customer ever sees it. Fixed by making the writes take turns. The same bug existed in the publishing step; fixed there too.
• And the guard proved itself. During testing, the machine generated posts for a second community where fewer facts were published — and it correctly held four posts it couldn't verify (including every price post), marked in red, impossible for anyone to approve. Nobody programmed those specific holds; the honesty rule produced them by itself. That's the product's soul working exactly as designed.

What it all costs

Running everything — the analyzer, the hub, the portal, the reports, monitoring, backups — costs about $24 a month, plus about a penny and a half each time we post to X (the only network that charges; $25 of credit is already loaded). Building it cost almost no cash, because the building is done inside a flat-fee subscription. The costs that grow later — a part-time assistant, payment-processing fees — only appear after revenue does, and scale with it. One client at any realistic price covers the entire cost base many times over.

What happens next, and who does what

The machine's work is largely done for now. What remains is human, and most of it is one person's job:

1. Book the working session with the partners — show them the demo and the real portal, publish a live post in front of them, and ask one question: "which two builders should we pilot this with?" Everything else in this plan waits behind that half hour.
2. Two ten-minute developer sign-ups (Facebook/Instagram and LinkedIn) that only the account owner can do — they start multi-day approval clocks, so sooner is better. Step-by-step answer sheets are already written.
3. Then the 60-day pilot: real builders, real posts, honest measurement, and a day-60 conversation about money — with evidence instead of promises.

The honest odds, one last time

As a "software company for everyone," this would most likely fail — the field is crowded and AI keeps making the core task cheaper. As a small, trusted, two-industry service with a machine inside, the odds are genuinely decent — our working guess is roughly a coin flip's neighborhood, and the pilot will replace that guess with facts within about ninety days. The floor is low (costs are trivial), the ceiling is real (ten clients ≈ $100,000 a year at ~90% margin), and the deciding factor isn't code anymore. It's whether two builders say yes. Getting them to say it is the entire job now.

Part XII. Everything that needs your input — the complete step-by-step checklist

This is the whole list. Nothing else in this entire plan is waiting on you — the machine's side is done. Each item below says why it matters, how long it takes, and every step in order. And for every single one, there is an easier path: open a Claude session and say "help me with checklist item 1" (or 2, 3…) — and it will be walked through with you live, one small step at a time, with the right text placed on your clipboard as you go. Doing them in the order listed is best, but any order works.

Item 1 — Book the working session with your partners  HIGHEST VALUE · ~5 minutes · easy

Why: every dollar in this plan sits behind one half-hour meeting. The demo, the script, and the leave-behind are all built and waiting.

1. Open your email (or text messages — whichever you'd normally use with them).
2. Send a short, casual note. Here is a draft you can copy and adjust — it's deliberately a show-and-tell, not a pitch:

   Subject: Want to show you something built for builders
   
   I've spent the summer building a marketing machine, and it's
   alive — it posted to my real accounts this week, automatically.
   I built the demo around home builders, and I'd love 30 minutes
   to show you: a builder's listings turning into approved,
   published social posts, live, while we watch.
   
   No deck, no ask beyond your honest reaction — though if you like
   it, I'll want your advice on which two builders to pilot it with.
   
   Good day this week or next?

3. When a time is set, tell Claude: "the partner session is booked for [date]" — everything gets prepped and rehearsed with you before it.
4. For the session itself, your three links (bookmark them now):
   • The demo (open on your phone): automarketingengine.com/demo/builders/
   • Your minute-by-minute script: automarketingengine.com/demo/builders/script.html
   • The printable leave-behind: automarketingengine.com/demo/builders/leave-behind.html

Item 2 — Create the Meta (Facebook + Instagram) developer app · ~10 minutes · medium

Why: this is the key that lets the machine post to Facebook and Instagram. Your own pages work the same day; client pages unlock after Meta's review — which is a multi-day clock that starts the moment you do this. That's why it's item 2.

1. Go to: developers.facebook.com/apps and log in with your regular Facebook account. (First time it may say "Register as a developer" — agree and continue.)
2. Click the green Create App button.
3. Answer the wizard with these:
   • What do you want your app to do? → Other, then app type → Business
   • App name → WholeTech Publishing Hub
   • Contact email → walhus@gmail.com
   • Business portfolio → skip it if allowed (create one named WholeTech only if it forces you)
4. On the app dashboard, find "Facebook Login for Business" in the product list → click Set up. Then in the left sidebar: Facebook Login → Settings → in the box called Valid OAuth Redirect URIs, paste exactly:

   https://postiz.wholetech.com/integrations/social/facebook

   → Save changes.
5. If an Instagram product is listed → click Set up (nothing to configure).
6. Left sidebar → App settings → Basic. Fill in:
   • App domains → postiz.wholetech.com
   • Privacy Policy URL → https://automarketingengine.com/privacy/
   • Terms of Service URL → https://automarketingengine.com/terms/
   • Data deletion → choose "instructions URL" → https://automarketingengine.com/privacy/#data-deletion
   • Category → Business and pages → Save changes
7. At the top of that same Basic page: App ID (visible) and App Secret (click Show; it asks your Facebook password). Write both on paper.
8. Open your own terminal (any folder), and run:

   ssh -t root@64.227.29.192 /opt/postiz/set-meta-keys.sh

   It asks for the App ID, then the Secret — paste each, press Enter. It says "Done!" and the hub restarts with Facebook + Instagram wired in.
9. Leave the app in Development mode — correct for now. Tell Claude "Meta keys installed" and your own Facebook Page + Instagram get connected the same day; the client-unlocking review gets submitted for you with the screencast it requires.

Item 3 — Create the LinkedIn developer app · ~10 minutes · medium

Why: LinkedIn is the channel that matters most for the magnetics niche and for builder corporate brands. Its review is also a multi-day clock.

1. First, the app must belong to a LinkedIn Company Page. If you don't have one for the product yet: on LinkedIn, click For Business (top right) → Create a Company Page → choose Company → name Auto Marketing Engine, website automarketingengine.com, industry "Software Development", tiny logo optional → create. (2 minutes; skip anything optional.)
2. Go to: linkedin.com/developers → Create app.
   • App name → WholeTech Publishing Hub
   • LinkedIn Page → pick the page you just made
   • Privacy policy URL → https://automarketingengine.com/privacy/
   • Logo → anything (the og image from automarketingengine.com works) → Create app
3. Auth tab → under Authorized redirect URLs, add BOTH of these, exactly:

   https://postiz.wholetech.com/integrations/social/linkedin
   https://postiz.wholetech.com/integrations/social/linkedin-page

4. Products tab → request "Share on LinkedIn" and "Sign In with LinkedIn using OpenID Connect" (usually instant), and "Community Management API" (this one is the review). If it asks how you'll use it, paste:

   Self-hosted publishing dashboard. It posts only content our
   authenticated clients approve, to pages they administer. No data
   resale. Privacy policy linked on the app.

5. Auth tab again → copy the Client ID and Primary Client Secret onto paper.
6. Your own terminal:

   ssh -t root@64.227.29.192 /opt/postiz/set-linkedin-keys.sh

   Paste the two values when asked. On "Done!", tell Claude "LinkedIn keys installed."

Item 4 — A Mastodon account · ~3 minutes · easy

Why: a free, no-review network that makes the pilot's channel list longer on day one. The machine's side is already fully wired — only an account is missing.

1. Go to mastodon.social → Create account → username suggestion: wholetech (or springnet), your email, a password you write down. Confirm the email it sends you.
2. Then open the hub → postiz.wholetech.com → sign in → + Add Channel → Mastodon → it bounces you to mastodon.social → click Authorize. Done — tell Claude, and Mastodon joins every future post.

Item 5 — Decide about the open $13 bounty · ~1 minute · easy

Why: $13 of your money is escrowed on a task (creating a Bluesky account for one of the sites) that may now be redundant, since your own Bluesky is connected.

1. Just tell Claude one of: "cancel the bounty" (the $13 returns to your wallet) or "keep the bounty running" (a dedicated brand account still has value). Either answer is fine; cancel is the tidy default.

Item 6 — Rotate the RentAHuman key · ~4 minutes · easy

Why: that key once appeared in a chat window, so best practice is to replace it. Until then it can spend from your RentAHuman wallet (caps are set, but still).

1. Log in at rentahuman.ai → find API keys (usually under Settings or your profile) → Regenerate (or delete + create new). Copy the new key — shown once.
2. Your own terminal:

   ssh root@143.198.182.180 nano /opt/autoengine/rentahuman.env

   Replace the old value after RENTAHUMAN_API_KEY= with the new one. Save: Ctrl+O, Enter. Exit: Ctrl+X.
3. Tell Claude "RAH key rotated" — the connection gets re-verified for you.

Item 7 — Two one-line decisions · ~1 minute each · easy

1. The canonical product site. The eleven family sites should funnel to one. Recommendation: automarketingengine.com. Just reply "use automarketingengine.com as canonical" (or name another) and the redirects get handled.
2. Pricing sign-off. The rate card in Part IV ($500/$900/$1,500 builders; $1,250/$2,500 magnetics; −20% founding rate) is an estimate until you bless it. Reply "pricing approved" or adjust any number — final-final gets set with pilot evidence anyway.

Item 8 — Later, optional (no action now)

• Email sending (SMTP) so the system can send confirmation and digest emails itself. Decision needed eventually; nothing blocks on it today.
• App reviews follow-up: after items 2–3, Meta and LinkedIn will email their verdicts within days. Forward or mention anything they send to Claude — responses get drafted for you.

Part XIII. After your input: every remaining step to complete the project

This chapter assumes Part XII is done — the session is booked, the developer apps exist, the keys are installed, the decisions are made. From that moment, here is every step remaining, in order, until the project is complete — with who does each one, what it unlocks, and the honest definition of "finished" at the end. Almost everything below is the machine's work; your parts are marked YOU and total a few hours spread over three months.

Stage A — The week after your inputs land (machine, ~2–3 days)

1. Connect your own Facebook Page + Instagram through the new Meta app (dev mode works immediately for accounts you admin). First cross-platform test post to your own channels — proof in hand for the session.
2. Connect LinkedIn (personal share works at once; company-page posting arrives when the Community Management review clears) and Mastodon (instant).
3. Submit the Meta App Review — screencast of the connect-approve-publish flow, reviewer instructions, business verification. Starts the clock that unlocks client accounts.
4. Pre-session rehearsal: demo reset, live-fire preview run, portal demo link tested on a phone, leave-behinds printed. YOU: one 15-minute rehearsal pass with the script — the only prep the session needs.

Stage B — The working session and the 48 hours after it (YOU + machine)

1. YOU: hold the session (the script is Part V's demo flow: problem → live demo → held card → live-fire → the ask). Leave with two pilot builder names — or, fallback, one introduction.
2. Machine: same-day thank-you draft for you to send, with the leave-behind link and the agreed day-30/60 review dates.
3. Machine: pilot intake packs prepared per builder (brand-profile form, channel inventory sheet, listing-source request). Gate G1 is now passed or the fallback path triggers (Part IX — reassess, white-label framing, or direct outreach through other builder contacts).

Stage C — Pilot onboarding, per builder (machine + Human Desk, ~1 week each, run in parallel)

1. Intake call (YOU, 30 min, with the builder's marketing person) → brand profile + listing source agreed.
2. Machine: workspace created (P60), templates tuned to their communities (P73), listing adapter written (CSV first, scraper if their site is stable).
3. Existing accounts connected by guided link; missing ones opened by the Human Desk under the identity policy (P55) — the builder's identity, a dedicated business number, never burners.
4. Baseline captured before the first post (P78): followers, prior 90-day posting, prior social traffic. Non-negotiable — it's what makes the day-60 numbers honest.
5. First week's queue generated; guided first approval session (us on the phone while they swipe — 15 minutes); first posts live on X + Bluesky + Mastodon immediately, Facebook/Instagram/LinkedIn joining as reviews land.

Stage D — Pilot operations, weeks 1–8 (machine, with two YOU checkpoints)

1. Daily: listings checked, posts generated, approval digests sent, approved posts published, everything logged.
2. Weekly: Monday digest to each builder; metrics snapshot (P78); template tuning from skips and edits (P66's simple rules, applied by hand at this scale).
3. Channels appear in digests as platform reviews clear — visible momentum without extra work.
4. Day 30 — Gate G2 (YOU, 20-min review call per builder): cadence ≥90%? approvals under a minute a day? If not, the product experience gets fixed before any money conversation.
5. Weeks 5–8: the Results page (P75) fills with real numbers; the day-60 review documents auto-draft from data, and you hand-edit the honest "is this working?" paragraph.

Stage E — Money (day 60 → ~week 12): Gate G3, the project's hinge

1. YOU: the day-60 review with each builder — their numbers beside the tier that fits, founding rate (−20%, 12 months) on the table. The ask: "keep it running as a paid service?"
2. YOU: the partner-terms conversation the same week — referral / reseller / white-label (the three shapes from Part III), chosen from evidence, not theory.
3. Machine: proposals generated (P79), Stripe activated (P67 — built and waiting), first subscriptions live. First recurring revenue.
4. If G3 fails (no one pays ≥$500): the written pivot from Part IX executes — reprice, restructure as white-label, or cap at the floor case. No drift, no sunk-cost spiral.

Stage F — Productionize (weeks 12–20, machine; makes 10+ clients possible)

1. P68 — onboarding automation: intake form → brand profile → workspace → connect page → baseline → first batch, with <1 day of human labor, measured.
2. P69/P70/P71 — the orchestrator, gates, and watchdog: the loop runs itself per client on schedule; sensitive actions queue for a human; silence becomes an alarm. This is the "self-driving" promise, delivered.
3. P63 Lane 2 — the weekly batched content session: spotlight posts for all clients in one cached run, inside the flat subscription. The quality ceiling rises; the cost stays zero.
4. P54 — the VA desk activates (~8–10 clients): one assistant runs the human layer from the runbooks; you review samples weekly instead of doing the work.
5. Operator web console (thin) + the partner portfolio view (P76-lite) — the business becomes visible to its partners and runnable by someone who isn't you.

Stage G — The second niche: magnetics (parallel from ~week 14)

1. YOU: one thinking session to name the right buyer contacts in the Polymagnet/magnetics world; machine refreshes the case-file artifacts as the pitch portfolio.
2. Warm approach built on the demonstrated work → one pilot on the Technical Presence tier, expert-gated (P77). Same chassis, deeper posts, LinkedIn-first. Gate G4 after one quarter: engaged buyer or park the track at zero cost.

Stage H — Steady state: what "the project is complete" actually means

The project is done — not paused, done — when every box below is true:

• ☐ At least 3 paying clients on monthly subscriptions (any mix of tiers/niches).
• ☐ The loop runs without daily human attention: generate → approve → publish → measure → report, orchestrated, gated, and alarmed (P69–P71 live).
• ☐ A new client onboards in <1 day of labor, by runbook, by someone other than you at least once (P68 + P54 proven).
• ☐ All major channels publish through our own apps: X ✓, Bluesky ✓, Mastodon, Facebook, Instagram, LinkedIn — reviews cleared and client accounts connecting.
• ☐ Every client sees a monthly report that renews them without a sales call, carrying the standing referral line.
• ☐ The partner arrangement is written down — even one page — and at least one client arrived through it.
• ☐ Revenue exceeds all running costs by 10× or more (the math says this happens at client #1; the box is here so it's checked, not assumed).
• ☐ The kill-gates log (G1–G4) shows every gate passed or consciously pivoted — no zombie efforts running on inertia.

After that, the weekly rhythm of the finished business is small and calm: approvals happen on clients' phones without us; the Monday digests go out alone; one batched content session; one glance at the ops digest; one monthly report cycle; conversations only with prospects and partners. The machine does the work. The humans keep the trust. That was the whole idea, and at that point it will simply be true.

Appendix A. Index — every section, A to Z

Built automatically from the document's own headings on every page load, so it can never drift out of date. Click any entry.

Appendix B. References — every link in this document

Every distinct URL referenced anywhere above, collected automatically on page load and grouped: first the project's own live pages (the evidence), then external references. Self-updating.

Our live pages & evidence

External references

Appendix C. GitHub repositories — what we run, and what we can integrate

The open-source map of this project: repositories already in production, and vetted candidates for each upcoming phase. Everything here fits the house rules — self-hosted, subscription-safe, boring-by-preference.

The integration rule: nothing joins this table by being exciting — it joins by removing work at a phase we've actually reached, self-hosted, with no per-token or per-seat metering. Candidates get adopted when their phase arrives, not before.