Case Study - Train Everything

Overview

Hybrid training, the mix of barbell strength and real running distance in the same week, has outgrown the people who can afford a coach to program it. The usual answer is an app: a questionnaire, a subscription, and a plan generated for you alone. We incubated Hibrido to test the opposite idea, that the programming itself is the product, and that it is worth proving before anyone builds the app around it.

So Hibrido publishes one workout a day, the same one for everyone, in Spanish, English and Portuguese. No account, no paywall, no ads. Two equipment variants, a commercial gym and a minimal kit, with three scaling tiers on every movement, so a first-month lifter and a tenth-year athlete are doing the same session at different weights.

As a company builder, Everseed handled the whole lifecycle: the training model, the brand, the generation pipeline, the site, and the infrastructure underneath it.

The Challenge

Generating a workout with a model is easy. Generating one you would hand to a stranger at 6am, with nobody there to ask, is not.

Two problems had to be solved before anything could ship. The first is safety. A model asked politely in a prompt to avoid Olympic lifting and high-skill gymnastics will mostly avoid them, and "mostly" is the wrong standard when the failure mode is somebody attempting a snatch alone because a website told them to. The second is drift. A model that writes its own movement names writes them differently in three languages, and Spanish, English and Portuguese readers slowly stop receiving the same workout.

Both are the same challenge in different clothes: how much do you trust the model, and where do you put the thing you are not willing to trust it with?

Our Process

1. The Catalog, Not the Prompt

We moved the exercise vocabulary out of the prompt and into the repository. The model is handed a fixed catalog of 59 movements, versioned in code and already translated into all three languages, and it composes a session by choosing ids from it. It never names a movement. Output referencing an unknown id, or one unavailable in the equipment variant that used it, is rejected and regenerated, three times, then the run fails rather than degrading. That is what turns the exclusions into a constraint instead of a polite request.

2. Splitting Structure From Prose

Generation happens in two calls. The first produces the language-neutral structure, the movements, reps, loads and time domains. The second writes the coaching prose in all three languages against that fixed structure. Translation therefore cannot drift the training itself: the Portuguese reader and the English reader are looking at the same numbers by construction, not by review.

3. Art That Never Sees the Workout

A third call renders the day's two plates, 16:9 for the site and 4:5 for social. It follows the same rule one level further: the image model is never told what the workout is called. It receives a physical description of the day's dominant movement, taken from a file with a line for every catalog id and a test that fails the build when one is missing. So the exclusions hold for the picture the way they hold for the session, and the workout's prose, which an image model would happily paint into the corner of a frame that exists to have text laid over it, never reaches it.

The people in those pictures come from a table. Invented athletes, one row each, with a physical description and a reference portrait rendered from it. Days rotate through the roster, so a week of plates is recognisably the same handful of faces rather than seven strangers.

4. Publishing With a Buffer

The nightly job runs at 08:00 UTC and works two days ahead. Nothing is rendered until its own date arrives, which leaves 48 hours to catch a failed run, a model outage, or a session that simply reads badly. Which date is yours is a separate question, answered from the reader's own timezone, resolved server-side, so nobody in Vancouver is handed tomorrow's session at breakfast.

Architecture & Tech Stack

• Framework: Next.js 16 (App Router) with React 19, server-rendering every dated page so the workout is readable, shareable and indexable without a client bundle doing the work.
• Generation: model calls through OpenRouter, validated with Zod against the catalog before anything is stored. The image stage is the one part allowed to fail quietly, recorded against its own stage so the workout stores regardless. Structure and copy give up rather than degrade; a missing picture is a missing picture.
• Data: Supabase Postgres holds the sessions, the cast and the signup list, with writes closed to the service role and two public buckets for the rendered plates and portraits.
• Migrations: forward-only, applied automatically on merge by CI using the same script a developer runs locally, with destructive statements refused unless the file explicitly says so. A migration path that only runs in CI is one nobody has tested.
• Delivery: deployed on Vercel, with the nightly generation on Vercel Cron and a password-gated dashboard that fails closed rather than serving unreviewed drafts.

The Impact

Hibrido is Everseed's argument about where models belong in a product. Not as the thing that decides, but as the thing that composes inside a boundary somebody else wrote down and a test enforces. The catalog, the structure-then-prose split, and the image scenes are all the same move: put the model's freedom where a bad answer is cheap, and take it away where a bad answer reaches a person lifting something heavy.

It is deliberately early. The generator runs nightly and the site publishes in three languages; the signup list keeps the addresses it collects and has not sent anything yet, because the workout has to be good before the distribution is worth building.

Visit hibrido.app to read today's session.