Engineering Velocity at Genovo: Shipping Six Releases Without Breaking the Pipeline

In the last cycle we shipped a redesigned application shell, folder and multimodal uploads, dataset groups, warranty claims, a live pipeline view, named API keys, two-factor auth, and a public certificate verifier — while the backend evolved underneath on its own schedule. Small team, no downtime, no big-bang release.

The trick is that frontend and backend do not release in lockstep; they release against a contract. Features that depend on an endpoint that has not shipped detect its absence and hide themselves — a 404 from a capability probe means “not yet,” not “error.” The day the endpoint lands, the feature appears without a deploy.

Every endpoint the platform consumes is typed once, in one API layer, with the backend’s field-name quirks normalized at the boundary — validation_id becomes id in exactly one place instead of forty components. When the backend renames a field or wraps a response, one normalizer changes and the UI does not notice.

CI is deliberately unexciting: typecheck, lint with zero tolerated warnings, a production build of every route, and an end-to-end suite that walks the public surfaces and auth redirects in a real browser. Preview deployments per pull request mean review happens against a running product, not a diff.

Slow release trains create pressure to sneak changes in; fast, boring releases remove the incentive. Because any given deploy is small and reversible, we can afford to be strict about what enters it. On a platform whose whole pitch is “we catch problems before they get expensive,” the deployment culture has to model the same principle.