A chained reasoning pipeline that halts itself rather than ship a half-built document
A performance coach was hand-writing 40-page training plans, eight hours each. I built a pipeline of four chained Claude modules that assembles the same branded 40-page document, with token-based verification between stages so a failed module halts the run instead of emailing a broken PDF to a paying client. Built and validated. The client never took it to production, so the time saving is a benchmark, not a result.
The problem
Brother Faris runs a high-performance coaching brand. Every new client gets a personalized 40-page training and recovery plan: eight hours of work, every time. Quality bar high (clients pay accordingly), but delivery cost was capping the business. Faris was turning away work because he couldn't keep up.
The constraint wasn't his expertise. It was that the expertise lived only in his head, expressed by hand, every time.
What I did
- Mapped the structure of a great plan first. Intake, training, recovery, nutrition, cover narrative. Each section pulls from a different intake signal. This became the spec.
- Typeform intake. ~20 questions feeding the pipeline directly.
- Four chained Claude modules in Make.com. One per section. Each module gets the intake plus the previous sections, so it writes consistently with what came before. Four targeted prompts, not one huge one.
- PDF.co assembles a 40-page A4. Branded cover, Montserrat throughout, structured sections, embedded charts. The template IS Faris's hand-built layout.
- SendGrid delivery with personalized email and the PDF attached.
The detail that mattered: token-based verification between the four Claude modules. Each returns a completion token before the next runs. If a module fails or returns garbage, the pipeline halts and Faris gets a Slack alert, not the client. Half-built PDFs never go out.
What it measured
Against real intake data during the build, a plan came out in about twenty minutes instead of eight hours, at a quality the client accepted as indistinguishable from hand-built. Those are build-time measurements, not operating results. See the status note below.
Status: built, never deployed
Honest footnote, added 2026-08-13. This system was built and validated against real intake data, but the client never took it to production. The engagement stalled on their side and the pipeline never ran for paying end users.
Which means the "8 hours to 20 minutes" figure is a measured benchmark of the build, not an operating result. I originally carried it as an outcome. It isn't one, so it no longer leads anywhere in my resume or profile, and this case study is no longer featured.
What still transfers is the engineering: chaining a reasoning model across four dependent stages, and the token-based verification between them that halts the run on a bad response so a half-built document never reaches anyone. That pattern went on to earn its keep elsewhere. The project itself did not ship.