Building Kasratbook in public
A behind-the-scenes look at our weekly ship cadence, monorepo setup, and the deploy pipeline that lets two engineers ship five times a day.
We're a team of four engineers serving 500+ gyms. We ship to production an average of 7 times a day. Here's the setup that makes it possible.
The monorepo
Everything lives in one repo: the dashboard, the member apps, the API, the docs site, the marketing site, our internal admin tools. We use Turborepo for caching and pnpm workspaces for dependency management. The whole repo clones, installs, and builds in under 4 minutes on a fresh machine.
The deploy pipeline
Every push to main triggers a deploy. We have no staging environment. We have feature flags, canary releases, and aggressive monitoring instead.
When a PR merges, GitHub Actions runs the full test suite (about 1,800 tests, runs in 3 minutes), builds the affected packages, and deploys to Vercel for the web apps and to AWS ECS for the API. The whole pipeline takes 8-12 minutes from merge to fully rolled out.
Feature flags do most of the work
We use GrowthBook for feature flags. Every meaningful change ships behind a flag and rolls out gradually: 1% of accounts → 10% → 50% → 100%. We can stop the rollout in 10 seconds if anything looks wrong.
Observability
Sentry for errors, Grafana for metrics, Logfire for traces. We have a hard rule: every PR must include the metric or log line that proves it works in production. Code without observability is code we can't trust.
Why it works
The honest answer is that we say no to a lot of complexity. We don't have microservices. We don't have a custom build system. We don't have a staging environment. Every shortcut we don't take is one less thing that can break at 2 AM.