AI SaaS Workflows — the business shapes
The engineering is settled; now the commercial container. Four shapes: AI-native products (the AI is the product), AI features inside existing SaaS (the largest category by revenue), vertical AI (one industry's workflow, owned deeply), and internal tooling/services (unsold, enormously valuable). Two design forces govern all four:
Force 1 — unit economics as a design constraint (Topic 77, now existential): pricing must survive your cost curve. Per-seat pricing + heavy usage = margin erosion; usage-based or credit pricing tracks COGS honestly; and the margin-protection stack — routing, caching, caps, batch — isn't optimization, it's what makes the pricing page true. Cost-per-customer metering (Topic 70) from day one, because in AI SaaS your heaviest user can be your least profitable.
Force 2 — the moat question, deserving the honest treatment: "it's just a wrapper" is the standard sneer, and the standard rebuttal is real: the model was never the moat — models commoditize on Topic 11's 6–12-month lag, for everyone, symmetrically. Durable advantage in AI SaaS comes from exactly four places: the data flywheel (next diagram), workflow depth (integrations, permissions, the fifty unglamorous edge cases that make switching painful), distribution, and trust/proprietary context (being the system that already holds the customer's data). Here's the first one — the compounding engine this entire course quietly built the parts for:
Decode the flywheel with course vocabulary and notice you own every gear: usage → data is Topic 74's feedback capture and Topic 79's accept/reject exhaust; data → improve is Topic 75's regression cases plus Topics 16/28's preference pairs feeding DPO/KTO; improve → better product is the eval-gated ship loop; and competitors starting today can copy your UI in a week but cannot copy your accumulated eval set and preference corpus — the one asset that only time-in-market produces. Corollary for small teams: vertical beats horizontal — a niche workflow's flywheel spins faster because the data is concentrated and the workflow depth is reachable; and the validated build sequence is concierge → semi-automated → productized: do the workflow manually for five customers first (you're building the golden set and discovering the edge cases — Module 2's data craft as market research), automate second. Premium-tier idea you're uniquely equipped to offer: per-customer fine-tunes via Topic 22's multi-adapter serving — a 50 MB adapter per client on one shared base is a feature competitors without Module 3 can't quote.
Summary
AI SaaS = engineering wrapped in unit economics (price to survive your cost curve, meter per customer) and moated by flywheel, workflow depth, distribution, and trust — never by the model. Go vertical, concierge first, and let the eval/preference corpus compound.
Mental model
The model is the espresso machine — every café on the street has the same one. The moat is the regulars, the barista who knows their orders (data flywheel), and the fact that the office upstairs runs a tab (workflow depth).
Mistakes to avoid
defending "wrapper" accusations by hiding the model instead of building the flywheel — the accusation is only true of products that don't accumulate data advantages; and pricing per-seat with unmetered usage, then discovering your best customer is your biggest loss.
Exercise
For a SaaS idea you'd actually build: write the flywheel concretely (what data does usage produce? what does it improve, mechanically — eval cases? DPO pairs? retrieval corpus?), name the moat among the four, and draft the pricing model with a Topic 77 margin check at 10× expected usage. One page: the difference between "an idea" and "a business shape."