--- title: 'What a 127-Commit Release Actually Is' excerpt: 'GeekBye v1.7.0 was 127 commits in eleven days. From the outside that looks like a hundred little things. From the inside it was two big features braided together — and one of them got built in the wrong place, then torn out and rebuilt mid-release. Here is the anatomy of a large release.' date: '2026-07-06' author: 'Steven' authorAvatar: '/images/blog/authors/steven.jpg' coverImage: '/images/blog/covers/what-a-127-commit-release-actually-is.svg' tags: ['Engineering', 'Release', 'Architecture', 'GeekBye Releases'] keywords: - 'how big is a large software release' - 'client vs backend source of truth architecture' - 'react strictmode duplicate api calls 429' - 'long lived feature branch integration cost' - 'shipping two big features one release' - 'anatomy of a large release' lastModified: '2026-07-06' tldr: "GeekBye v1.7.0 was 127 commits, but not 127 small things — it was two large parallel features braided together: an AI calibration flow that assesses your communication skills, and a full premium redesign delivered as a second application window. The instructive part: calibration was first built in the client's local database, then three days later 680 lines were deleted to move it to the backend, where the architecture always said it belonged. And integration surfaced a bug isolation never would: duplicate fetches tripping a rate limit." keyTakeaways: - 'A 127-commit release was two big braided themes — an AI calibration flow and a full premium redesign — not a hundred unrelated changes' - 'The real cost of a large release is integration order and long-lived branches, not the commit count; one feature branch had to merge main four times to stay current' - "Calibration was built in the client's local database, then 680 lines were deleted three days later to move it to the backend where the architecture said it belonged" - "Integration surfaced a bug isolation could not: duplicate API calls per navigation, doubled again by React's strict mode, tripped a rate limit until fetching was consolidated" - 'When your architecture already says where the source of truth lives, taking the client shortcut is rework you have pre-scheduled for yourself' --- There's a version of this blog post that just lists everything in GeekBye v1.7.0 — a redesigned home screen, a calibration flow, a collapsible sidebar, new settings, and on and on. It would be accurate and it would teach you nothing. Because the honest story of a **127-commit release** isn't the list. It's the _shape_. Here's the shape. A hundred and twenty-seven commits sounds like a hundred and twenty-seven little things. It almost never is. v1.7.0 was **two big features**, built in parallel on long-lived branches over about eleven days, braided together at the end. Understanding a large release means understanding those two strands — and the one place we built something in the wrong spot and had to tear it back out mid-flight. ## Strand one: calibration The first strand was **calibration** — an AI voice assessment of your communication skills. You start a live call with an AI "career coach," work through a structured set of phases (warmup, behavioral, technical communication, pressure response, goal-setting), and at the end you get scored across six dimensions: confidence, clarity, specificity, engagement, composure, relevance. Underneath, it measures concrete speech metrics too — your speaking pace, filler-word frequency, whether your pauses read as strategic or hesitant. The output isn't a grade, it's a _starting point_. Calibration produces your strengths, your growth areas, and — crucially — a recommended difficulty to start practicing at. It calibrates _where the product should meet you._ Each skill comes back as an expandable feedback card with a summary, a concrete suggestion, and an actual quoted line from your own call as the example. It's the feature the rest of the practice experience is built on top of. ## Strand two: a whole new window The second strand was a **premium redesign** — and calling it a redesign undersells it. It wasn't a reskin of the existing screens; it was effectively a **second application window**, built out in six explicit phases: a collapsible Notion-style sidebar, a header dropdown that replaced the old session list, browser-style navigation with history and breadcrumbs, and premium rebuilds of Home, Profiles, Meetings, and Settings. Two big features. That's what 127 commits actually was. And the hardest part of shipping them wasn't writing either one — it was the _braiding_. The two branches were interdependent; one was merged into the other, and the calibration branch had to pull in the main branch **four separate times** just to keep from drifting out of sync while the redesign moved underneath it. **The commit count isn't the cost of a big release. Long-lived branches and integration order are.** ## The part worth the read: we built calibration in the wrong place Here's the mistake, and it's a good one because it's so common. GeekBye has a firm architectural rule: **all AI operations live on the backend.** The client is a thin shell that talks to a server. Everybody knew this. And yet calibration was first built **in the client's local database.** A dedicated table, a database migration, a 254-line repository, IPC handlers, and a 515-line bank of assessment questions — all living on the user's machine. It worked. It also quietly violated the contract the whole app is built on. Three days later, one commit deleted **680 lines across eight files** to move it all to the backend, where calibration data became a proper server-side model, and the question logic and scoring became a server concern. Another commit deleted the 515-line client question bank outright. The diff is almost funny: _one insertion, six hundred and eighty deletions._ Nobody set out to write 680 lines of throwaway code. It happened the way this always happens: the client shortcut is _right there_, it's faster to prototype locally, and "we'll move it to the backend later" feels harmless. But when your architecture already tells you where the source of truth lives, building it anywhere else isn't a shortcut — **it's rework you've pre-scheduled for yourself.** The lesson that stuck: put it where the contract says, the first time, even when the local version is quicker to stand up. ## The bug that only integration could find One more receipt, because it's the signature failure mode of big releases. Once calibration and the new navigation were wired together and actually running, the app started tripping a **rate limit** — HTTP 429s — for no obvious reason. The cause was pure integration. Calibration status was being fetched at the component level, so every navigation refetched it — and React's strict mode, which deliberately double-invokes effects in development to surface bugs, doubled that again. The result was **four to eight identical calibration requests firing per screen change**, enough to trip the server's rate limiter. The fix consolidated fetching to a couple of calls on mount. You could not have found this bug testing calibration alone, or the navigation alone. It only exists at the _seam_ — where two independently-correct features meet. That's the tax a large release charges: the last mile isn't building the features, it's discovering everything that only breaks when they're finally in the same room. ## Three things a big release taught 1. **A 127-commit release is two or three big themes, not a hundred small ones.** Find the strands. The work — and the risk — lives in how they braid together, not in the count. 2. **Put the source of truth where the contract says it lives, the first time.** We deleted 680 lines relocating calibration from client to backend. The local shortcut is rework you've scheduled in advance; the architecture already told you the answer. 3. **Integration surfaces failures isolation can't.** The 429 storm lived at the seam between two correct features and only appeared once they ran together. Budget for an integration pass, not just per-feature testing. This is a v1-era cousin of a story we'd tell again at a much bigger scale — see [what a version 2 actually takes: 206 commits of honest states](/blog/what-a-version-2-actually-takes-206-commits) (v2.0.0), where the same "a big number is really a few big ideas" truth plays out across the whole v2 rewrite. For the previous chapter in the v1 story, [how to stream a live report without the flicker](/blog/how-to-stream-a-live-report-without-the-flicker) (v1.6.13); and for the whole arc, [the anatomy of shipping software to perfection](/blog/anatomy-of-perfection).