How we use Rezee to build Rezee
Dogfooding all the way down - how the Rezee team runs specs, planning, code, CI, and agents inside Rezee itself, what the naming scheme is about, and what building on your own product teaches you.
May 6, 2026 · 4 min read · Kash Gohil
Rezee is built in Rezee. The specs for every capability, the issues behind every commit, the pipelines that test the git server, and the chat where we argue about all of it - one workspace, the same one we're selling you. This post is about what that actually looks like, and what relentless dogfooding teaches you that user interviews can't.
What does the stack look like?
One monorepo, five moving parts, and - since you'll notice the pattern anyway - a naming scheme borrowed from Chainsaw Man:
- denji - the git engine, in Go: smart HTTP and SSH transport, bare repos, the thin-pipe architecture we wrote up. Named for the boy who became one with his chainsaw; a git server is mostly a chainsaw you try not to reimplement.
- makima - the API service (TypeScript/Bun): auth, authorization, and control over everything. If you've read the git server post, you know every permission decision routes through makima. The name is, we admit, on the nose.
- pochita - the app UI (React): the workspace shell you actually live in. Small, friendly, does everything.
- kobeni - the pipeline runner: anxious, overworked, somehow always survives.
- The marketing site you're reading - also in the monorepo, also shipped through the same pipelines.
Go for the engines, TypeScript and React for everything user-facing, YAML pipelines of the shape we teach here on every push.
How does a Rezee feature actually ship?
The lifecycle we recommend is the one we run:
It starts as an RFC in Ideate & Design, using the template we published - problem, proposal, what we're not doing, decision date. Recent example: the capability detail sheets on our features pages went through a spec that argued about (and rejected) two other presentations first. The rejected alternatives are still in the doc, which is the point.
Then it becomes issues - one reviewable change each, the spec referencing them so it reads as current rather than as a snapshot. The tracker hygiene we preach is mostly enforced by the structure, which is good, because preaching doesn't survive deadlines.
Branches name their issues, merges close them. Nobody on this team has updated an issue status by hand in months. The changelog you see on the site is written from closed work, not from memory.
Agents do the boring middle. Investigating the issues we assign them, diagnosing the failure when kobeni reports a red pipeline, drafting doc deltas after a push. Everything gated exactly as we tell you to gate it: agent proposes, human merges. We feel the "review becomes the bottleneck" effect ourselves, which keeps us honest about review discipline.
What has dogfooding actually changed?
The honest value isn't marketing - it's that friction finds us first:
- Live log streaming exists because we got tired of refreshing. Watching kobeni run tests through a polling UI lasted about two days before the streaming work was specced.
- Unfurls stay live because stale ones burned us. A pasted PR link that said "open" after merge caused exactly one confused standup before the live-unfurl issue was filed - from the chat thread where the confusion happened.
- Spec → issues is on the roadmap because of our own drift. Early Rezee was specced in Rezee docs but planned by hand, and our specs rotted like anyone's. The closed loop is being built to fix our own fiction problem first.
- The bottleneck moved, so the product followed. Once agents took over more of the routine reading, review and specification became our scarce resources - which reordered the roadmap toward review flow and templates. We'd have gotten there eventually from user feedback; living it got us there quarters sooner.
The limitation, stated honestly: we're one team with one workflow, which is why the comparison posts exist and concede what they concede. Dogfooding tells you a lot about depth and nothing about breadth.
FAQ
Is Rezee really built entirely in Rezee?
The development lifecycle - specs, issues, code review, CI, team chat - yes, one workspace. The exceptions are the boring ones any young product has: some external services for email and payments, and public artifacts (like this blog) that also ship to the open web.
Why the Chainsaw Man names?
The services needed names, the team likes the series, and the fits were too good to pass up - the git engine that's mostly chainsaw, the API that controls everything, the runner that suffers. Internal names leak into blog posts; we've decided to enjoy it.
What's the biggest thing dogfooding taught you?
That drift is structural, not moral. Our own specs rotted and our own tracker lied when the links between them were manual - with maximum motivation and the builders themselves as users. That's what convinced us the seams have to be removed by architecture, not discipline.