Flocci Projects: The Sprint Tracker That Was Never Meant to Stand Alone

There’s a specific kind of grief in watching a plan come apart without anyone deciding to abandon it. Ask most teams where “the plan” actually lives and you’ll get three answers at once: a doc someone wrote in week one, a chat thread where the real decisions quietly happened, and the head of whoever’s been here longest. All three claim to be authoritative; none of them agree. The doc describes a scope that shifted two standups ago, the thread has scrolled past recall, and the version in someone’s memory walks out the door every time they take a day off. Nobody chose this. The plan just rotted in the gaps between the places it was supposed to live. Flocci Projects starts from a blunt observation about that decay: plans don’t survive contact with reality because reality is fragmented — scattered across a tracker, a calendar, a wiki, a notes app, and a canvas, each with its own login and its own version of the truth — and no single tracker can fix a fragmentation it’s a part of.

First, it’s a real tracker

Strip away the suite for a moment, because the suite only matters if the tracker underneath is worth using — and this one sweats the unglamorous parts. Issue keys, the FP-42 that turns up in a standup or a commit message, are handed out by a per-project issue_sequences counter that increments atomically, so two teammates hammering quick-add in the same second can’t both be given FP-42. Due dates and sprint start and end dates actually persist — an early validator was silently stripping them on the way to the database until someone noticed the dates never stuck and fixed it, because a date that quietly vanishes is worse than a blank field. Sprints run a genuine lifecycle, planning to active to completed, with a POST /sprints/:id/reopen that flips a finished sprint back to active for the weeks when reality reopens the work whether you wanted it to or not. Hand the AI a goal and it breaks that goal down into a set of issues. And every one of these moves — a reordered card, a status change — broadcasts as a projects:changed event over Socket.io, so a teammate’s board updates by push rather than on their next refresh. None of that is exotic. It’s just the baseline a team can actually build a plan on — the part most “lightweight” trackers quietly skip.

Five logins that never speak to each other

Price out how a small agile team actually operates and the bill is longer than the one on the invoice. You buy a tracker — Jira, Linear. You buy a calendar. You buy a wiki — Confluence, Notion. You keep a notes app. You bolt on a whiteboard. Five products, five logins, five subscriptions, five silos. And critically, five things that don’t know about each other. There’s no native way to turn an issue into a calendar event, or to tether a spec page to the ticket it describes. The links you care about — this task, that meeting, this doc — live only in your head, or in a paragraph of pasted URLs that rot the moment anything moves.

That fragmentation isn’t a UX annoyance. It’s the actual reason the plan rots. A plan is a web of relationships — this depends on that, this is discussed there — and the moment you shatter the web across five disconnected tools, you’re left maintaining the relationships by hand. Nobody does. So the calendar drifts from the sprint, the wiki page describes a version of the feature that shipped two iterations ago, and the tracker becomes a list of tickets nobody believes.

Flocci Projects’ thesis is that a sprint tracker should not be sold as a standalone thing at all, because a standalone thing is structurally incapable of holding the web together. It should be one facet of a suite where the connections are native — inherited, not bolted on.

”Once at core” is an architecture, not a slogan

Most suites are a marketing bundle: five products acquired or built separately, given a shared nav bar and a joint price. Underneath, they’re strangers. Flocci Projects is the opposite — the sharing runs all the way down to the wire.

There is one backend: Hono plus Drizzle ORM in TypeScript, serving all five apps. Sign in once and you’re signed into everything, because identity is a property of the core, not of each app. The Socket.io realtime spine, the AI gateway, the Graph event mesh — one of each, shared by all five. When the team wired globally-unique issue keys, or push realtime, or AI goal-to-backlog breakdown, they weren’t adding features to Projects so much as lighting up capabilities the shared core already carried. That’s why an app that could easily have been a weekend to-do list instead has the plumbing of something far more serious.

The payoff shows up as things that would be genuinely hard to build in a silo and are nearly free here. An issue can cross-link to a calendar event, with linked badges showing the connection on both ends — because the calendar is right there, on the same backend, in the same org context. The link fabric isn’t Projects-specific; its type enum spans notes, wiki pages, issues, events, and boards. The web of relationships that fragmentation destroys is, in Flocci, a first-class data type.

The mechanics are real, not a demo

It would be easy to assume that an app defined by its suite membership skimps on the tracker itself. It doesn’t — and the details are where you can tell.

Read those closely and a pattern emerges: each one is the version a serious engineer builds, not the version a prototype ships. Atomic sequences instead of a naive count that double-mints under load. A sprint lifecycle that can go backwards, because real teams reopen sprints. Drag-and-drop that survives a page reload, because a board that lies about state is worse than no board. Push realtime, because a tracker that makes you refresh to see reality is a tracker people stop trusting. The domain model backs it up — a dedicated Postgres database that runs from projects and sprints down to issue_activity and the issue_sequences table that guarantees FP-42 is always exactly FP-42.

Turning a goal into a backlog, and a sprint into a chart

Two capabilities push Projects past “competent tracker” into something more opinionated about how planning should feel.

The first is AI breakdown. You hand it a goal; it returns a set of issues. That’s the fuzzy objective — the one that until now lived only in the doc’s first paragraph or somebody’s head — decomposed into tickets you can actually assign. Crucially, it doesn’t route through some third-party plug-in. It calls Flocci’s own intelligence service on DeepSeek, wrapped in a Graph-ready envelope carrying an app id, tenant id, identity user, feature key, trace id, and idempotency key — so the action is traceable and safe to retry. The AI isn’t a novelty pinned to the side; it’s a native verb of the platform.

The second is Insights. On the sprint view, Recharts-powered velocity, workload, and status visualizations render a lightweight analytics read on the sprint you’re actually running — the burndown you used to sketch by hand, except it draws itself from the tickets instead of from a hopeful guess.

1. Frame the goal

   Start from an objective, not a blank backlog. AI breakdown decomposes it into a set of issues — type, and a starting place in the backlog — routed through Flocci’s intelligence service with a traceable, idempotent envelope.

2. Shape the sprint

   Pull issues into a sprint, set priorities and story points, and move the sprint from planning into active. FP-42-style keys keep every issue addressable in a standup or a commit message.

3. Run the board

   Work the kanban live. Drag cards across columns and the status persists server-side; teammates see the change pushed over Socket.io, not on their next refresh. Comments and a field-change audit keep the history honest.

4. Read the sprint back

   Watch velocity, workload, and status charts on the sprint view. Reopen a sprint if reality demands it — the lifecycle bends instead of breaking.

Who it’s for, and where it fits

Flocci Projects is aimed at knowledge workers and small-to-mid agile teams — product, engineering, ops — who want honest sprint and kanban tracking without assembling a five-tool stack to get it. The suite membership is the whole pitch. You’re not buying a tracker and then shopping for a calendar; you’re getting a tracker that already lives next to one, reachable from an app-switcher waffle where Projects is the rose tile. Registering on any suite app silently authenticates you across all of them via shared identity cookies — a short-lived access token paired with a longer-lived refresh — and cross-app SSO carries across the suite from a single login.

Underneath, the multi-tenancy is inherited too. Org switching, invites, roles, and teams come from Flocci’s shared Org Identity service, and Projects runs its own isolated Postgres database — one of the five domain DBs behind the shared backend — flippable between local and Neon via the standard DB_TARGET pattern. The Projects-specific wrinkle is capture: every org gets an auto-provisioned “Inbox” project so quick-add has somewhere to land on day one. Because issue keys are globally unique rather than per-org, that provisioner had to be taught to hunt for a free Inbox key instead of blindly minting the same one for every tenant — a sharp edge that only surfaced once real orgs collided. And like every Flocci app, Projects reaches shared providers only through the gateway — identity, AI, and Graph events all flow through one door — but the Graph events it emits are its own: issue and sprint changes on the projects domain, not the calendar’s or the wiki’s.

The honest state of it

It would be a disservice to pretend Projects is a shipped, shrink-wrapped 1.0. It’s a maturing beta. The routes are mounted, the UI runs in live mode, realtime and identity/SSO are wired and working — and there’s a known light-mode re-theme on the list, plus engineering polish like an issue-sequence rollback edge case still queued. That’s not a hedge; it’s the shape of a product being built the right way round.

And it’s the right way round precisely because of where plans actually go to die. A plan doesn’t fail in one dramatic moment; it rots in the gaps between the doc, the thread, and the tracker that never talk to each other. Flocci Projects refuses those gaps. It’s a real sprint tracker — atomic issue keys, a lifecycle that reopens, a board that persists, charts that draw themselves — but it earned all of that by being a facet of something larger rather than a silo pretending to be self-sufficient. The point was never any single one of those features. It was that the work — the tickets, the calendar event, the spec page — can finally sit on one connected surface instead of three that disagree. Flocci Projects is a bet that a plan can keep that surface intact all the way to production, and that the distance between the plan and the thing that ships shrinks the moment it stops having to live in five different places at once.