Formship is a live SaaS that helps coaches turn their frameworks into structured programs their clients can actually work through. I designed and built it end to end, solo, in Vue 3 and Python.
Why orchestration instead of one big prompt
A coaching program is not a blob of text. It is a sequence: content blocks a learner reads, quizzes that check whether the material landed, checkpoints that track progress. Ask a model to generate all of that in one shot and you get plausible mush, the kind that reads fine and composes terribly.
So generation runs as a multi-step pipeline instead. Each step in the chain has a narrow job and a structured contract for what it hands to the next one, and the customer-visible features (AI-generated quizzes, modular content) are the last link of that chain, not the whole machine. Decomposing the work this way is what makes the output usable: a quiz that arrives as structured data can be rendered, edited, and scored by the app; a quiz that arrives as prose can only be pasted somewhere.
The unit of composition is the block
The other load-bearing decision: programs are built from modular content blocks rather than documents. Blocks are what the AI pipeline generates into, what coaches rearrange, and what the analytics layer measures learner progress against. One shape, three jobs. That symmetry was the design goal, because the structure that makes generation reliable is the same structure that makes progress measurable.
What it taught me
Formship is where I learned the lesson I now apply everywhere, including to the MCP servers I build: AI output is only as composable as the data model you force it into. The model is rarely the hard part. The contract is.