The rebuild that two years of development couldn't crack. Shipped solo in seven days.
Scrumo is the agile project management tool Core Devs runs on. Version one spent nearly two years in development across multiple teams and never got its hardest feature stable: nested tasks with rolled-up estimation and time tracking. I dropped it entirely and rebuilt from an empty repository with my AI-first delivery workflow. The core was live in a week. It has run our delivery every day since.
Nested rollups killed version one.
Scrumo v1 was an in-house build that ran for roughly two years across several development efforts. The concept was always right: a Scrum tool shaped around how Core Devs actually delivers. The execution kept hitting the same wall. Tasks needed unlimited nesting, and every parent needed live rolled-up numbers: estimated time summed from children, actual time summed from timers and manual logs, story points, completion state. Every edit anywhere in the tree had to update everything above it.
In v1 that recursive recalculation grew heavier as data grew. The app slowed, then started hanging on exactly the screens a PM lives in. Patch after patch treated symptoms while the accumulated architecture underneath stayed the bottleneck. After two years, the honest conclusion was that the foundation could not carry the feature.
- ~2 years of development, multiple teams and developers
- Nested estimation and time-rollup logic never stabilized
- Recalculation made the app slow down and hang
- Fixes patched symptoms, not the architecture
- Never became the daily tool it was meant to be
- 7 days from empty repo to working core, built solo
- Rollup engine designed first, everything built around it
- Deep nesting with instant rollups on live company data
- AI-first workflow: spec, build, test, review in tight loops
- Runs Core Devs delivery every day, 3 workspaces
Empty repository to internal demo.
The rebuild started from a written spec, not from code. I ran it through the same AI-first pipeline Core Devs uses for client work: a full SRS of 237 requirements, a coded design prototype as milestone one, then vertical slices with tests at every step. The decision that made the week possible was building the hardest thing first. The rollup engine was designed and shipped before the features that depend on it, instead of being bolted on at the end like v1.
First commit
Spec locked: SRS V3.0, 237 requirements, 196 scoped for MVP. Multi-tenant architecture with PostgreSQL row-level security decided on day one.
All 23 screens, coded and signed off
Not mockups. A working React 19 + Tailwind prototype covering every screen in the product, navigable end to end. Auth and multi-tenant core passed UAT the same day.
The engine that defeated v1, live
Nested subtasks, time tracking, and the full rollup system: estimation and actuals summing up the tree instantly, timers, manual logs. Projects, sprints, and the task core landed the same day.
First internal demo
Files, comments, notifications, and reporting layered on top. The team started planning real sprints in it. It never went back on the shelf.
A full Scrum suite, not a toy.
Seventeen milestones later, Scrumo is a complete multi-tenant platform: list, Kanban, table, calendar, and Gantt timeline views, sprint planning with per-member capacity, burndown and burnup charts, velocity and completion-rate reports, org-wide workload with capacity overrides, timesheets, recurring tasks, custom fields, personal todos, and real-time collaborative notes with version history and PDF, DOCX, and Markdown export. Everything updates live over server-sent events, it installs as a PWA, and every screen ships in light and dark themes.
Why the rollup engine works this time.
The v1 failure was architectural, so the v2 answer had to be architectural. Rollups in v2 are a single canonical service on the server, not logic scattered across screens. Every write that can affect a tree, whether it comes from the UI, a bulk operation, a timer, or an API call, flows through the same recalculation path inside one transaction. The frontend never computes a rollup; it only renders what the server already resolved.
Two design rules keep it honest. First, display values are never allowed to drift from source data: when a user manually corrects a task's actual time, the engine reconciles the underlying time entries in the same transaction, so the timesheet and the task can never disagree. Second, every derived number has exactly one implementation. When a rule changes, it changes in one place, and an integration test suite pins the contract so regressions surface before deploy, not in a sprint review.
Two years of patches could not fix a wrong foundation. Seven days on the right one did.
How one person outbuilds a team.
Scrumo v2 is the strongest proof of the delivery system I run at Core Devs. The workflow is a disciplined pipeline, not autocomplete: requirements are written and frozen before code, the design ships as a coded prototype, every milestone has UAT scripts that run against the live stack, and every bug fix lands with a written root-cause analysis and a durable rule so the same class of bug cannot ship twice. AI accelerates every step; the engineering discipline is what makes the speed safe.
The same pipeline kept compounding after launch. Scrumo now exposes its own MCP server with OAuth 2.1, so Claude and any MCP client can plan sprints, create tasks, log time, and run reports directly against it. The tool that my AI workflow built is now a tool my AI workflow uses.
Boring where it should be, sharp where it matters.
The tool the company runs on.
Scrumo is not a demo. It is where Core Devs plans sprints, tracks time, reviews workload, and reports on delivery across three workspaces, every working day. The nested rollups that sank version one now run instantly on live production data, and the platform keeps growing on the same pipeline that built it: seventeen milestones shipped, from the core engine to calendar and Gantt views, PDF exports, org-wide workload, and two-way Microsoft To Do sync.
Have a build that keeps stalling?
Tell me what you're building, your timeline, and a rough budget, and I'll tell you if I can help.