Open decisions - blocking before build
Ordered by how much they change the code. Each one has a recommendation so nothing sits waiting on a blank page.
1. Does the iOS app sell anything? (biggest fork)
Apple requires In-App Purchase for digital content consumed in the app, at 15% under the Small Business Program. Stripe Payment Links cannot be used inside the app for that. The 08-08 call accepted the 15%. The repo's July plan assumed Stripe with no login.
Options
- A. Reader app. iOS is free, sells nothing, unlocks content bought on the web. No IAP plumbing, no 15%, fastest to build and to review. Apple allows this, but the app cannot link to or mention the website purchase flow.
- B. Full IAP. Sell 101 inside the app. 15% to Apple, real StoreKit work, and every price change becomes an App Store Connect chore.
- C. Phase it. Reader app for the Sept 1 submission (there is nothing to sell in the MVP anyway), add IAP in Phase 1 when the course is actually recorded.
Recommendation: C. The Phase 0 MVP is free lead-gen. There is no reason to build billing plumbing for a launch that sells nothing, and it strips ~a week out of the Sept 1 crunch.
2. Native iOS or web-shell for v1? - DECIDED 2026-08-19
Decision: a real SwiftUI iOS app and a web app, sharing one account. Not a wrapper. Same login, same data, same purchases, two genuinely native front ends.
This is the better product and it removes the App Store rejection risk that a wrapper carries. It costs more build time, so the architecture has to carry the weight instead of the UI:
+---------------------------+
| Identity + entitlements | one account, one source of truth
| (Supabase Auth) |
+-------------+-------------+
|
+-------------+-------------+
| Shared API | agent runs, plans, progress,
| (typed, versioned) | content manifest, downloads
+------+-------------+------+
| |
+----------+---+ +---+-----------+
| Web app | | SwiftUI iOS |
| course. | | App Store |
| wtfisai.co | | |
+--------------+ +---------------+Rules that keep two front ends from becoming two products:
- No business logic in either client. The agent chain, plan generation, and entitlement checks live behind the API. Both clients render what they are handed.
- Content is a manifest, not hardcoded screens. Modules, videos, and take-home assets come from the API so adding module 8 does not require an App Store release. This is what defuses the ~10 day Apple review tax on every content update, which was a live worry on the 08-08 call.
- Design tokens shared literally. The values in
Design-File-WTFISAI.mdbecome one token file, consumed as CSS custom properties on web and as a Swift color/type enum on iOS.
Sequencing for Sept 1: web app first, since it is the surface that can be live on Sept 1 with no review queue. The iOS app targets the same API and gets submitted as soon as the Phase 0 screens are ported. If iOS slips past Sept 1, the launch still happens.
3. Auth model - DECIDED 2026-08-19
One account across both surfaces. Sign in on the web, open the iOS app, already signed in as the same person with the same plan and the same entitlements.
- Primary: email 6-digit code. Satisfies the no-password preference from the 06-25 call and works identically on web and iOS.
- Sign in with Apple on iOS. Required by Apple if any third-party login is offered, and it is the lowest-friction option on an iPhone. Must resolve to the same account record when the email matches, including Apple's private relay addresses.
- Supabase Auth as the identity service. Already in the stack for the agent's storage, has first-class Swift and web SDKs, and matches the shared-context pattern taught in the new 101 module.
Watch item: a user who signs up on the web with sheila@x.com and later taps Sign in with Apple must land in one account, not two. Account linking on matched email needs to be built in v1, not retrofitted after support tickets start.
4. Where does this live? - DECIDED 2026-08-19
app.wtfisai.co. On the WTF is AI domain, not Tandem's. Supersedes the course.beintandem.co line from the 06-25 call.
- Web app served from Cloudflare Pages on that subdomain, wired to this repo per the 07-18 workflow.
- The iOS app points at the same API origin.
wtfisai.costays the marketing site.app.wtfisai.cois the signed-in product.
5. Course numbering: 102 or 201?
Calls say 102. Repo files say 201. Pick one now, before it is in App Store copy and marketing.
Recommendation: 101 and 201. The written curriculum already uses it, and the gap in the numbering signals the gap in difficulty, which is the honest framing.
6. Price story
Three live versions: "high-ticket" (08-08 call), $499 / $1,350 (WTF-is-AI-101-SMB-Owner-Track.md), and $1,350 for a 4.5-month cohort (wtf-products.md, stale). The app needs one.
Not my call. But wtf-products.md should be reconciled or retired either way, since it contradicts the current curriculum doc.
7. What actually powers the goal-to-plan agent?
The 08-08 call described the three-layer pattern (shared context, nodal agents, front end) but as course content, not as this app's architecture. For the MVP the agent needs: the profile as context, a prompt chain that produces the plan sections, and somewhere to store the result.
Recommendation: Claude API with the profile injected as context, a 3-4 node chain matching the plan's sections, results in Supabase. This is deliberately the same shape as the framework taught in the new 101 module, so the app is a live demo of its own curriculum. That is worth a slide.
8. Timeline reality check
Today is 2026-08-19. Sept 1 is 13 days out, Apple review is ~10 days.
- Submitted by Sept 1: achievable if mockups are approved this week and the two new curriculum modules run in parallel rather than blocking.
- Live in the App Store on Sept 1: not achievable. Live lands ~Sept 10-14.
- The web app can be live on Sept 1 with no review queue. Suggestion: web app live Sept 1 is the public launch, App Store availability is a second announcement two weeks later. Two launch moments instead of one.