All Briefs
Mission Brief · 004—·updated

by Łukasz Graliński

Twenty days to build.
Thirty weeks to keep alive.

PirxeyOS is the operating system we are building for our own company: time tracking, HR, a skills matrix, employee records, onboarding — and it keeps growing, so expect more briefs from this log. Our AI engineer built the first working version, the time-tracking module, in about twenty working days, AI-native, alone. This is the honest log of what happened next: 587 commits, 46% of them fixes, and an average weekly commit rate about 60% higher from the go-live week onward.

587
commits · Feb 7 → Sep 7, 2026
46%
fixes · 269 of them
22%
co-authored by Claude or Codex
Open the log
Ship's log · interactive

Scrub the log. Watch go-live happen.

Every bar is a week of commits to the PirxeyOS repository. Orange is a fix. Cream is a feature. The purple line under each bar is how many commits that week carried a Claude or Codex co-author. Drag the playhead, or hit replay and watch the week of July 1 arrive.

587commits · 32 weeks
46%of them fixes
18%features
22%co-authored by Claude or Codex
225pull requests merged
Commits per week, Feb 7 → Sep 7, 2026
fixfeaturedocs · chore · testsAI co-authored
13263851GO-LIVE · JUL 1day 1day 20go-livetoday2026-02-022026-09-07
W32 · 2026-09-07Today

Six contributors. 81 migrations. 140 test files. Time tracking is one module now — HR, a skills matrix, employee records and onboarding grow alongside it. Still shipping fixes weekly.

This week
3 commits · 2 fixes · 0 features · 2 authors
AI co-authored
1 of 3 (33%)
Log so far
587 commits · 46% fixes · 22% AI

Before go-live · 21 weeks

15 commits / week

41% fixes · 18% features

After go-live · 11 weeks

24 commits / week

52% fixes · 18% features

The demo ended in week 4. The product started in week 22. Nobody planned the jump — real users did.

What the 269 fixes were about
Real commit titles, grouped by keyword. Pick a category.

Midnight, time zones, duplicates across pages, cascading deletes — the physics of real data.

  • 2026-07-20fix: handle midnight in tracker form (#156)
  • 2026-07-09fix: fix duplicate entries between pages for the same created_at
  • 2026-08-20fix: cascade deletion from entry to timer_session
  • 2026-08-18fix(calendar): duplicate entries to any date
  • 2026-07-09Fix report pagination after temporal backfill
  • 2026-03-20Fix manager project duplicate checks
Day 20 vs week 30

The same product, two different jobs.

Both columns are true. The left is what a one-person, AI-native build genuinely delivers in twenty working days — and it is a lot. The right is what the same system needed once it became the tool 150 people log their hours in.

01
Day 20 vs Week 30

Scope.

Day 20A tracker, a weekly calendar, team scheduling, reports, client billing, tags and projects. A custom design system with light and dark mode. It looked finished, because it was — for one user.
Week 30The same modules, plus: role scoping for managers, the Clockify history import, a public REST API and an MCP server so agents can log time, 81 database migrations, and a fix for every way 150 people found to enter time. Nothing new on the roadmap. Everything new in the details.
Day 20 delivered the product. Week 30 delivered the company's version of it.
02
Day 20 vs Week 30

Data.

Day 20Sample entries. Whole hours. One time zone. Nobody working past midnight.
Week 30Entries crossing midnight. Duplicates between pages sharing the same timestamp. A delete that has to cascade to a running timer. Reports over six months that must stay fast. 51 fixes in this category alone.
Data has physics. It shows up on go-live, not in the demo.
03
Day 20 vs Week 30

People.

Day 20One developer, 319 commits, every decision in one head. No handoffs, no alignment, no waiting.
Week 30Six contributors. Pull requests, reviews, a merge queue. Someone reads the support channel. Someone owns the migrations. The one-person speed was real — and it was also the one thing that could not scale with the user base.
The build was a sprint. The product is a shift rota.
04
Day 20 vs Week 30

AI.

Day 20Claude and Codex wrote most of the first version. That is the whole reason twenty days was possible.
Week 30AI kept writing — 22% of all commits carry a co-author line, fixes included. What AI did not do: notice the midnight bug, decide a manager should not see another team's hours, or pick up the phone when reports were slow. Somebody asked. Somebody checked. Somebody shipped.
AI wrote the tail too. A human had to know the tail was there.
What we'd tell you · six things

What the log taught us

Not a retrospective. The six things we now say to anyone who asks whether they should build their own module instead of renting one.

01
~15k USD · one developer

The twenty days are real

A working, designed, deployed system with real users in a month is not a pitch — it happened. Discovery, data model, front end, back end, API, security, deploy. AI-native, one person. Do not let anyone tell you the first version still takes a quarter.

— Pirxey case study · PirxeyOS
02
15 → 24 / week

Average commit rate rose about 60%

Before the go-live week: 323 commits in 21 weeks. From it on: 264 in 11. Not because the build was sloppy — because 150 people found 150 ways to use it. Budget for the second half before you celebrate the first.

— pirxey-os repo · weekly history
03
52% of post-launch commits

Half of everything after launch is a fix

Fixes are small (about 290 lines each, features are about 1,450) and there are two and a half times more of them. Commits, not hours — but the shape is unmistakable: shipping starts the work.

— pirxey-os repo · 269 fix commits
04
data · UI · permissions · APIs

The fixes have categories, and they repeat

51 data-consistency fixes. 35 on real devices and screens. 31 on permissions and security. 26 on APIs and integrations. Every product we have ever rescued had the same four buckets. Plan them; don't discover them.

— pirxey-os repo · fix explorer above
05
REST + MCP · Telegram · Claude

AI-native means API and MCP from day one

An employee tells a Telegram bot to log 1.5 hours on code review; an agent does it through MCP without touching the UI. That was designed in, not bolted on — and it is the part a SaaS vendor will never build for your process.

— Pirxey case study · PirxeyOS
06
~40k USD/yr SaaS vs ~15k once

Own software is an asset — if you staff the tail

150 people times ~22 USD a month is the subscription. The build was roughly a third of one year of it. The honest comparison also includes the thirty weeks after: a maintenance stream sized to your users. That is what we help you size.

— Pirxey case study · PirxeyOS · Okta SMBs at Work 2024
Evidence · receipts

The numbers — open the repo, or read the case.

Everything above is counted, not estimated. The dataset behind the log is generated from git history and shipped with this page.

587
commits, classified by prefix and keyword.
fix / feat / chore / docs / test from conventional-commit prefixes, plus a keyword pass (fix, bug, regress, revert, crash) for the 134 commits without a prefix. 269 fixes, 104 features. Merges excluded.
pirxey-os repository · Pirxey
127
commits carry an AI co-author line.
Co-Authored-By trailers naming Claude or Codex — the way both tools sign their work. It undercounts (not every AI-assisted commit is signed) and it is still one in five.
pirxey-os repository · git trailers
20 days
from process discovery to a working system.
Six phases: discovery, architecture and data model, design and front end, back end and data migration from Clockify, API and MCP layer, security and production deployment with permissions, RLS, Sentry and tests.
Pirxey case study — PirxeyOS
~93
applications per company, on average.
Okta's SMBs at Work: about 93 apps at the average firm, 58 at smaller businesses, 36 below 50 people. Every one of them asks the company to work the tool's way. Time tracking was the first PirxeyOS module of doing it the other way round; HR, a skills matrix, employee records and onboarding have joined it since, and the log keeps growing.
Okta — SMBs at Work 2024
+91%
review time in high-AI teams. Throughput flat.
Faros AI across 10k+ developers: developers in high-AI teams interact with 47% more PRs daily; PRs are 154% larger, review time 91% longer, bugs per developer 9% higher. Our log is one product's version of the same pressure — the code got cheap, the checking did not.
Faros AI — Lab vs Reality
95/5
the rule this log is the receipt for.
If you want the model behind the numbers — how much of a product the demo really is, and what the eight layers under the waterline cost — it is the previous brief.
Mission Brief 003 — The new Pareto
Mission control standing by

Thinking of replacing a SaaS with your own module?

We write custom software, some pieces are ready-made, and we join your team and work alongside it. We'll tell you what the first twenty days buy, what the next thirty weeks cost, and whether it beats the subscription — with our own numbers on the table. Free. No slide deck.

Ask about replacing a SaaS with your own moduleBook a call
Pirxey · Aleja Grunwaldzka 472, 80-309 Gdańsk, Poland·130+ engineers · 100+ missions delivered