Plans · updated 2026-09-07

PRD 001 - The MVP curriculum portal

1What this document is

A review of the MVP as currently designed, and the fix list to get it shippable. It covers five things:

1. The product experience and goals, checked against what the business actually needs
2. The MVP map: journeys, screens, states, and what the API owns
3. Copy fixes
4. Branding fixes
5. UI/UX improvements for the web app and the iOS app, and what they force on wtfisai.co

Where this document disagrees with the mockups, this document wins. Where it disagrees with the Fathom calls, the calls win and the disagreement is flagged.

2Goals

2.1 What the MVP is for

The Sept 1 launch is a list-building instrument that teaches, not a course. It exists because the 101 is not recorded yet and the business needs an audience by the time it is.

2.2 Targets to set before launch

The Aug 8 call set a date but no numbers. Pick these now so the launch can be judged:

• Emails captured in the first 30 days: [TARGET]
• Plans generated: [TARGET]
• Percentage who finish intake once started: 60% (proposed floor; below this the intake is too long)
• Percentage who export or email their plan: 35% (proposed floor; below this the plan is not good enough to keep)
• Waitlist-to-101 intent captured: [TARGET]

2.3 Non-goals

Explicitly out of the MVP. Every one of these goes in the ClickUp post-MVP folder per the Aug 8 discipline.

• The 101 course itself, or any video beyond Sheila's intro
• Community forum. The Aug 8 call flagged engagement as unsolved. A dead room is worse than no room.
• The "female CTO" agent
• Payments of any kind, on either surface (see D1 in section 8)
• The 201 build track
• Office hours booking

3Review: problems with the MVP as designed

Findings from reviewing the mockups against the goals. Each has a fix in sections 5 to 7.

P1. The plan asserts numbers the intake never collected - CRITICAL

The plan screen shows "4h per new client", "$310 monthly software", "2 processes only you know". The intake asks three questions and none of them produce those figures. Right now the mockup fabricates precision.

This is not a cosmetic problem. The entire product promise is this AI is worth trusting because it knows your business. Inventing a dollar figure is the exact failure mode module 0 teaches people to catch. If a user spots one invented number, the plan is dead and so is the course pitch.

Fix: either ask, or do not assert. See R2.4 and the intake redesign in 5.2.

P2. The career path has no product behind it

The two paths fork the whole experience, but the 101 is written only for the SMB owner. A career user finishes her plan and the next step we offer her is a course that is not for her.

This is worth solving rather than cutting, because the career persona is validated: Michelle is it, and her outcome is the strongest testimonial the business has. The repo already holds the assets - amazon-playbooks/audit-your-career-for-the-ai-economy.md and how-millennials-should-prep-for-the-ai-workforce.md.

Fix: keep both paths, route them to different post-plan destinations. See R3.

P3. Email is captured too late

In the current flow the user only gives an email at resource download. Someone who completes the intake, sees the plan, and closes the tab is lost entirely - and she is the most qualified person who visited that day.

Fix: capture email before the plan renders, framed as delivery rather than a gate. See R2.5.

P4. Nothing brings anyone back

Between Sept 1 and the course launch there is no reason to reopen the app. A dormant install is worth almost nothing, and a dormant install on iOS gets deleted.

Fix: the profile-to-better-plan loop is the mechanic. Make it explicit and give it a nudge. See R4.

P5. The plan might satisfy the need instead of creating it

The plan is deliberately good. Good enough that some users will act on it and never buy anything. That is an acceptable trade only if the boundary is deliberate.

Product principle, to be enforced in copy: the plan tells her what and why. It never tells her how. Every "how" is a named module. This is exactly the 101-versus-201 line from the Aug 8 call, applied one layer earlier.

P6. No states are designed

No empty state, no loading state, no error state, no offline state, no "agent failed" state. The generating screen is the happy path only. AI calls fail, and the first time a user sees a raw error the trust is gone.

Fix: see 7.4.

P7. The demo persona is a real person

The mockups use Michelle Rubin, her real business, and a real-looking email. These screens will end up in App Store listings, decks, and social posts.

Fix: replace with a fictional persona everywhere. See 5.5.

P8. Brand continuity between site and app is thin

Someone arrives from wtfisai.co and lands somewhere that shares a palette but none of the signatures: no marquee, no logo, no profanity, no "built for you". It reads like a different company's product.

Fix: see section 6.

4The MVP map

4.1 Personas

4.2 The journey

   wtfisai.co  ─┐
   social bio   ─┼──▶  Welcome ──▶ Pick path ──▶ Intake ──▶ Email ──▶ Generating ──▶ PLAN
   App Store    ─┘      (sign in)   career /      4-6 q      capture     agent runs      │
                                    business                                            │
                                                                                        ▼
                        ┌───────────────────────────────────────────────────────── Home / portal
                        │                                                                │
                        ▼                          ▼                    ▼                ▼
                   Free shelf              Intro video           Your business      101 waitlist
                   (3 magnets)             (4 min, Sheila)       (profile)          or career
                                                                       │             playbooks
                                                                       └─▶ regenerate a better plan

Two entry facts that shape everything: she arrives from a phone in most cases, and she has never heard the word "agent" used this way.

4.3 Screen inventory

4.4 What the API owns

Non-negotiable, because two front ends drift into two products otherwise.

The content manifest matters most. Modules, videos, and assets are served, not compiled in. Without it, adding module 08 means an App Store release and a ~10 day wait - the exact tax Sheila worried about on the Aug 8 call.

4.5 Data the profile holds

This is the shared context layer from the Aug 8 call, made concrete. It is also the answer to P1: the plan may only assert what this holds.

Everything the plan asserts traces to a row in this table. Nothing else gets a number.

5Copy fixes

5.1 Voice rules the app must follow

From WTFISAI-BRAND-GUIDE.md section 7, non-negotiable:

• No em dashes anywhere. Hyphens only.
• Profanity censored with asterisks, never spelled out. And it must actually appear - see C1.
• Plain English, no jargon, no gatekeeping
• Direct, unapologetic, empowering
• Do NOT prefix product names with "WTF is AI:". Canonical names are in brand guide section 8.

5.2 Fixes

5.3 Copy that is working, keep it

• "Cautious women who get educated outperform reckless early adopters" - straight from module 0, does the emotional work in one line
• "Not here to make you a founder or get you VC money. Here to make your business and your career worth more." - from the Aug 8 call, and it filters the audience Sheila does not want
• "Do not automate the part they hired you for. Automate the 4 hours around it." - the single most useful sentence in the plan
• "If this is what the free things look like, you can guess what the paid ones look like." - Michelle's framing, working as a shelf subhead

5.4 Michelle's scope

Per the Aug 8 call she is writing scripts and copy edits. The highest-leverage writing in the MVP, in order:

1. The plan output template. It is the deliverable, and it is 80% of whether the free tier converts.
2. The intake questions. Every word affects completion rate.
3. The generating screen narration. It is a teaching surface disguised as a loading screen.
4. Welcome and path copy.

She needs the repo to do this. Still outstanding since the Jul 18 call.

5.5 Demo persona

Replace Michelle Rubin and Rubin Creative everywhere in mockups, App Store screenshots, and decks. Proposed: Dana Reyes, Reyes & Co, a 3-person branding studio in Springfield MO serving med spas. Fictional, matches the priority persona, and safe to publish.

6Branding fixes

Audited against Design-File-WTFISAI.md, which is canonical.

6.1 Typography - DECIDED 2026-08-20: Broadcast

Sheila's read on the mockups, 2026-08-19: the type is what feels off. Agreed, and it is worth treating as a real decision rather than a tweak, because Playfair Display is doing two jobs badly at once.

Why Playfair is the wrong tool here. It is a didone: extreme thick-to-thin contrast, hairline serifs, drawn for large-format print and editorial mastheads. It reads elegant at 104px on a slide and it reads fussy at 22px on a phone, where the hairlines thin out and the whole line goes soft. It also carries the wrong association: Playfair says wedding invitation and fashion masthead. The brand says 90s broadcast, bright, a bit degraded, unapologetic. Those are not the same room.

Three candidates, each a genuinely different axis, all live in the prototype behind the font switcher:

Decided: Broadcast. Archivo at expanded width for display, Archivo for UI, Archivo 700 uppercase for labels. One superfamily doing both display and UI is the cleanest possible outcome, which was the actual request, and the expanded width delivers the era without any costume.

Playfair Display is retired from the product. It survives nowhere except in assets not yet re-cut, and those are listed below.

This is a three-surface change. wtfisai.co, the web app, and the iOS app all currently run Playfair plus Inter, so whatever is picked here changes all three. Two knock-ons to budget for:

• The site's hero tagline is artwork, not live text: /images/wtf-tagline-lower.png. It has to be reset and re-exported in the new face.
• Design-File-WTFISAI.md tabs 6 and 7 become wrong the moment this is decided. Update them in the same pass or the design file stops being canonical, which is worse than any font choice.

See D6.

6.2 The glitch budget - DECIDED 2026-08-20

The type is what got noticed, but the noise had a second source: the 90s TV effect was applied to type, and type is the one place it costs legibility. Chromatic offset sat on headlines, overlines, buttons, bullets, badges, and card edges at once. When everything glitches, nothing reads as glitched - it just reads as slightly broken, with a fuzzy edge on every word the user is trying to read.

The fix is not less fuzz. It is fuzz that is earned. There are exactly four ways to earn it, and anything not on this list does not get it.

Never, at any setting: body copy, overlines, section labels, every bullet, every pill, every card edge.

And the surface carries what the type gave up:

Every brand color stays at full brightness and the era stays. The words go sharp. Both settings are in the prototype so the two can be compared directly.

Six supporting moves, all boring and all necessary:Six supporting moves, all boring and all necessary:

1. Spacing on an 8pt scale. Current values run 24, 26, 28, 32, 34, 36, 38, 40 with no logic. Pick 8, 16, 24, 32, 48, 64 and stay on it.
2. Fewer containers. Cards inside cards inside bordered sections. Let the lilac ground separate things instead of drawing another border.
3. Overlines are not free. Right now nearly every block has an uppercase tracked label above it. Cap it at two per screen.
4. One type scale, actually enforced. Display, H1, H2, body large, body, label, caption. Nothing between.
5. Cyan and magenta are never body text on white or lilac. They fail contrast. They are legal on purple only, which is what the design file already says.
6. These rules apply to the website too. It has the same glitch-everywhere problem in the offerings cards and the marquee area.

7UI/UX improvements

7.1 Both surfaces

7.2 Web specific

7.3 iOS specific

7.4 States to design before build

Currently missing entirely (P6). Each needs a designed screen, not a developer's default:

• Empty: no plan yet, no downloads yet, profile incomplete
• Loading: generating (designed), plan loading, video buffering
• Error: agent failed, network lost, sign-in code expired, code entered wrong 3 times
• Offline: iOS, what is still reachable
• Edge: intake abandoned then resumed days later, plan generated before profile completed, same account signing in on a second device

7.5 App Store reach, and why web is the primary surface

Asked 2026-08-19: is an App Store launch global, and if not, is that another reason to build the web app?

The store is global by default. App Store Connect defaults to "All Countries or Regions" - 175 storefronts, and it automatically includes any storefront Apple adds later. Availability is not the constraint.

But there is a compliance floor, and one item is a hard blocker.

Global availability is not global usability. The MVP is English only, the persona is explicitly middle-American, the agent's build-vs-buy reasoning assumes US software pricing, and any future purchase flow is USD. A user in Jakarta can download it. She cannot use it well.

The stronger argument for the web app

Yes, this is more reason to build the web app - but it is the fourth reason, not the first. Ranked honestly:

1. Android. iOS is roughly 58-60% of the US mobile market, which means an iOS-only launch is invisible to about 4 in 10 of the target audience in the only country the MVP actually serves. Globally it is worse: Android is roughly 69%. A woman running a salon in Missouri is not reliably an iPhone user, and there is no Android app in this plan. The web app is the Android app.
2. Desktop. The plan is a document she will read, print, and hand to a partner or an accountant. She will do the audit sitting at the front desk with a keyboard, not thumbing through it on a phone.
3. No review queue. Web ships the day it is ready and iterates daily. Every iOS change costs ~10 days.
4. Reach and terms. Global from the first minute with no storefront compliance, no 15%, and a plan that can be shared by URL - which is the only organic distribution channel the launch has.

Conclusion, and it confirms the existing plan rather than changing it: the web app is the product and the iOS app is a distribution channel. That is already the build order in ../docs/01-scope.md. This is the evidence for it, and the reason to hold the line if the App Store timeline slips - web live Sept 1 is the launch, with or without Apple.

Android is committed

Decided 2026-08-19: Android ships after the web app and iOS, and it is a goal, not a maybe. It is out of the MVP and out of Phase 1 on sequence alone, not on merit. The web app covers Android users in the meantime, which is what makes the wait survivable rather than a hole in the plan.

Three consequences worth acting on now, while it is cheap:

1. Three clients on one API, not two. Every rule in 4.4 goes from good practice to load-bearing. Any logic that leaks into a client now has to be written three times and kept in sync three ways. The content manifest in particular stops being a convenience and becomes the only way a new module reaches all three surfaces at once.
2. Design tokens compile to three targets (B8): CSS custom properties for web, a Swift enum for iOS, a Kotlin or Compose object for Android. Generated from one source. Hand-copying across two targets is already a bad idea; across three it is guaranteed drift.
3. Stop assuming iPhone dimensions. Android skews toward budget hardware and a far wider range of screen sizes and densities, and among this audience that skew is stronger, not weaker. Layouts should already be fluid rather than pinned to iPhone breakpoints, and the 44px hit-target floor (U5) should be treated as 48dp, which is the Android guideline and the stricter of the two.

One thing Android gets right that iOS does not: Play review typically takes hours to a few days, not ~10. The update tax that shapes so much of the iOS plan mostly disappears there.

See D7 for the form it takes.

8Website impact - wtfisai.co

The app changes what the site is for. The site currently sells four products behind a waitlist modal. After Sept 1 there is a free product that exists and works, which is a stronger opening than a waitlist.

9Requirements

Numbered for tracking. R1-R5 are Phase 0. Anything not listed is out.

R1. Account

• R1.1 Email 6-digit code sign-in, web and iOS
• R1.2 Sign in with Apple on iOS, linking to an existing account on matched email, private relay included
• R1.3 One session state visible across surfaces: sign in on web, open iOS, already signed in
• R1.4 No passwords anywhere

R2. The plan agent

• R2.1 Two chains, career and business, sharing a profile
• R2.2 Chain of 4 nodes, each output feeding the next, matching the plan's sections
• R2.3 Runs server side. Prompts never ship to a client.
• R2.4 The plan may only assert values present in the profile. No inferred numbers, no market averages, no invented spend. Every figure renders with its source.
• R2.5 Email captured before the plan renders
• R2.6 Plans are stored, versioned, and regenerable
• R2.7 Failure is graceful, answers are preserved, and the plan is emailed if it completes later

R3. Path routing

• R3.1 Business path ends at the 101
• R3.2 Career path ends at the two career playbooks, with the 101 offered secondarily
• R3.3 Path is stored and changeable in the profile

R4. Return loop

• R4.1 Profile is editable at any time
• R4.2 Editing it prompts a regenerate
• R4.3 Regeneration shows what changed
• R4.4 One nudge per user: after 7 days, if the profile is incomplete, one email and one push, offering a sharper plan

R5. Content

• R5.1 Three existing lead magnets, email captured on download
• R5.2 Sheila's intro video, streamed, with an offline copy on iOS
• R5.3 Content served from a manifest so it changes without an app release
• R5.4 Kit receives every capture, tagged by path and by asset

10Acceptance criteria for Sept 1

• A new user reaches a finished plan in under 5 minutes on a phone
• Every number in the plan traces to something she typed (R2.4)
• Intake completion is above 60% in testing with 5 real people who match the persona
• The plan exports to a PDF that looks on-brand when printed
• All three magnets download and land in Kit, tagged correctly
• Sign in on web, open iOS, still signed in, same plan visible
• Every state in 7.4 has a designed screen, no raw errors
• No em dashes anywhere in the product (automated check)
• No retired brand colors anywhere (automated check)
• The web app is live at app.wtfisai.co
• The iOS build is submitted, with icon and screenshots
• wtfisai.co points at the app, with no dead "Coming soon" CTAs in the path

11Open decisions

Carried from ../docs/03-open-decisions.md, unchanged where unresolved.

12Risks

13What happens after this is approved

1. Sheila answers D1 through D5
2. Create the repo, give Michelle a branch (D5)
3. Michelle drafts the plan template and intake copy (5.4)
4. Redesign intake and add email capture in the mockups (U1, U2)
5. Fix the plan screen so every number has a source (C7, R2.4)
6. Design the app icon (B2) - long pole for the App Store
7. Build: API and account first, then web, then iOS against the same API