Detailed estimate of the backlog, in the order it is already written.
No items are reordered, moved between phases, merged or dropped. Every item keeps its phase, its position and its size flag from the source backlog. What is added here: a per-item spec, an owner, a parallelism factor, and a timeline for each section.
| Role | Count | Reads as |
|---|---|---|
| Backend | 2 | Supabase schema, RLS, migrations, triggers, API routes, Workers |
| Frontend | 2 | React Server Components, forms, feeds, client state, design system |
| Designer | 1 | Flows, specs, design-system extensions, QA against the built thing |
| Delivery | 4 eng | The designer is a lead indicator, not a parallel build stream |
Units. wks is the source backlog's own scale: S=2, M=3, L=6, XL=12, XXL=20 person-weeks.
Those are unchanged. cal is calendar time for the whole team on that section, derived below.
Par is how many engineers an item genuinely absorbs:
Design-gated items cannot start until flows exist. One designer feeding four engineers works only while the design queue leads the build queue by a full item. That is the constraint most likely to break this plan, and it is flagged per section.
Overhead. Per-item figures are build-only. Section timelines add 30% for review, QA, the bug tail and deployment.
Checked against the tree (798 source files, 76 migrations). Four items in the backlog are mis-sized because code already exists. Sizes below are left at the backlog's values so nothing is reordered — but these four should be re-flagged at the next grooming pass.
| # | Flagged | Actual state |
|---|---|---|
| Search | L | api/search/route.ts + queries/search.ts already do paginated ilike across profiles, organisations, projects, articles. ~M |
| Transactional email & delivery | L | lib/email/ has a working Resend client, typed config, a user-email service. ~M |
| Events | L | NewEventDialog.tsx exists with no schema behind it. L stands — the dialog is the cheap part |
| Content reporting & moderation | M | Nothing exists. M stands |
No notifications code exists anywhere in the tree, and no Stripe and no i18n dependency is installed. Those items are correctly sized as greenfield.
Shipped before this plan. Listed for completeness; not costed.
Mobile designs · Articles comments · Projects comments · Articles publish, hard deletion & 'My Articles' · Projects publish, unpublish, hard deletion & 'My Projects' · Account hard deletion (Legal) · Organisation hard deletion · Automated moderation · Alpha badges
13 open items · 63 wks · ~7 cal-months.
Two items are in flight. The phase splits hard at the Initial launch milestone: six items before it, seven after, and the seven after it are 51 of the 63 weeks.
| Item | Size | wks | Par | Owner | Spec |
|---|---|---|---|---|---|
| Legal pages (wip, Legal) | M | 3 | ×1 | FE | ToS, Privacy, Cookie + consent modal. Consent must gate analytics scripts, not just record a flag — a banner that sets state after GTM fired is not consent. First-party cookie, read server-side so the modal does not flash |
| Compliance audit (Legal, ops) | M | 3 | ×1 | BE | External review of legal, moderation and data-protection obligations. Scopes the follow-on tooling. Output is a requirements list, not code — book the reviewer early, their calendar is the constraint |
| Content versioning & edit history | M | 3 | ×1 | BE | Immutable snapshot per publish/republish; history + diff; reviews, citations and later PRG bind to a version_id; restore; interaction with retention and hard deletion (a version cannot outlive a GDPR erasure); storage and pruning policy for TipTap JSON |
| Articles — reviews | M | 3 | ×2 | BE+FE | Structured peer review pinned to a version. Reviewer eligibility, lifecycle, public display. Shape the record so a Phase 4 attestor signature attaches without a migration |
| Forms rework | S | 2 | ×1 | FE | Presentation only — layout, spacing, field styling, interaction patterns brought into line. Validation behaviour unchanged. Design-gated |
| Feed filters (wip) | S | 2 | ×1 | FE | In flight on feat/tozn-441-feed-filters. Remaining: land the uncommitted FeedFilters.tsx / InputSelectBadge.tsx work, then fix the detection bug in docs/plans/feed-ssr-unfiltered.md — Object.keys(filters).length > 0 counts undefined-valued keys, so ?published=abc reads as filtered |
Versioning before reviews. Both are M and both sit here, in that order — keep it. Reviews bind to a specific version, not to whatever the author edits the piece into afterwards. Ship reviews first and every review collected becomes unbindable; retrofitting means invalidating them.
Everything after this milestone is subject to change.
| Item | Size | wks | Par | Owner | Spec |
|---|---|---|---|---|---|
| Notifications | L | 6 | ×2 | BE+FE | First release only: five live groups (posts, projects, articles, org membership, own membership), bell + unread count, dropdown, dedicated page, read/seen state, interval polling. Cross-account addressing is the expensive-to-retrofit decision — a notification belongs to an organisation or a person; settle it now. Registration hooks so later types need no migration. Design-gated |
| Content retention & restoration | M | 3 | ×1 | BE | Soft-delete windows, restoration, grace periods on account and org deletion. Interacts with versioning above — decide once whether a restore resurrects versions |
| Organisation ownership transfer | S | 2 | ×2 | BE+FE | Transfer to another user. Invariant: an org always has exactly one owner, enforced in a transaction or trigger, never in application code |
| Stripe integration (Legal) | XL | 12 | ×2 | BE+FE | The rail the next three sit on. Webhooks with idempotent event handling, customer/payment-method storage, SCA/3DS, Connect onboarding with KYC states, payouts, refunds, chargebacks, platform fee at source, tax/invoice surface, currency and minimum rules, founding-member fee exemption keyed off the alpha badge. Connect KYC is partly Stripe's calendar, not yours |
| Project funding | XL | 12 | ×3 | BE+FE | Goals, progress, contribution records, one-off and recurring, payout release via Connect, refund and failed-goal handling, receipts, public funder list with anonymity, event retention for later PRG backfill |
| Tipping | L | 6 | ×2 | BE+FE | Tips on articles and projects, amount presets, recipient eligibility + Connect gate, history both sides, minimums, rate limits, self-tipping prevention, 9% fee |
| Paywalls | L | 6 | ×2 | BE+FE | Per-article opt-in gating, price and currency rules, purchase flow, entitlement storage and access checks, teaser rendering, author earnings, 9% fee. Access check must live server-side in the data layer — a client-side gate on article body is not a paywall |
The money block is 36 of Phase 1's 63 weeks. Stripe gates all three below it, and funding, tipping and paywalls all assume refunds and disputes get handled by a human until the admin console lands in Phase 2.
| Segment | wks | +30% | 4 eng, realistic |
|---|---|---|---|
| Pre-launch (6 items) | 16 | 20.8 | ~7 cal-wks |
| Post-launch, pre-money | 11 | 14.3 | ~5 cal-wks |
| Money block (Stripe → paywalls) | 36 | 46.8 | ~16 cal-wks |
| Phase 1 total | 63 | 81.9 | ~28 cal-wks |
Pre-launch is ~7 weeks rather than 5 because Legal pages, Forms rework and Feed filters are all single-owner frontend items that serialise against each other — FE1's queue is the critical path, and the compliance audit runs on an external reviewer's calendar.
The money block barely compresses: Stripe is a hard gate, and the three items below it cannot start until Connect onboarding works end to end. Expect ~16 weeks regardless of headcount.
12 open items · 74 wks · ~8 cal-months.
| Item | Size | wks | Par | Owner | Spec |
|---|---|---|---|---|---|
| Educational Resources | L | 6 | ×3 | BE+FE | Category/subcategory hierarchy, subject pages, authoring, Foundation curation workflow, references and citations. Curation is Foundation-run here; the DAO queue is Phase 4. Heaviest design load in the roadmap |
| Open Calls | XL | 12 | ×3 | BE+FE | Creation, editing, lifecycle states, directory with filters (grants/fellowships/residencies), application submission and applicant management, org-run endorsement, deadline handling and closure |
| Content reporting & moderation queue (Legal) | M | 3 | ×2 | BE+FE | Report action on articles, projects, comments, profiles; reason taxonomy; duplicate handling; queue with triage states and action log; DSA statement of reasons to reporter and author; appeal route. The DSA obligation is the report route — consider landing the button in Phase 1 and the queue here |
| User-to-user invites | L | 6 | ×2 | BE+FE | Personal links with attribution, acceptance bound at signup, quota and abuse limits, email delivery, inviter status list. Attribution must survive the auth round trip — cookie set pre-signup, consumed in the callback. Depends on Transactional email, which sits in Phase 3 |
| Rate limiting & monitoring (ops) | M | 3 | ×1 | BE | Sentry with source maps through the OpenNext build, rate limits on auth/write/upload keyed per user and per IP. Must be KV or Durable Objects — Workers isolates share no memory, so an in-process counter silently does nothing |
| Security hardening (ops) | M | 3 | ×2 | BE+FE | XSS sanitation of TipTap output server-side on write, Turnstile on signup/login/password reset, Cloudflare Pro bot protections |
| Accessibility audit & remediation (Legal, ops) | L | 6 | ×2 | FE | WCAG 2.2 AA audit and remediation, keyboard nav and focus, screen-reader semantics, colour contrast including the category colour system, form labelling (ties to Forms rework), captions/transcripts/alt-text flow, published statement, CI regression checks |
| SEO & metadata (ops) | S | 2 | ×1 | FE | generateMetadata on public routes, OG images, sitemap.xml, robots, PWA manifest. Must not regress the static-prerender path — a cookies() call added here makes public pages dynamic |
| GDPR self-serve endpoints (Legal, ops) | M | 3 | ×1 | BE | Self-serve export and erasure. Erasure has to reconcile with versioning and retention from Phase 1 — those three decisions belong together |
| Admin & back-office console (ops) | XL | 12 | ×3 | BE+FE | User/org admin, role-based least-privilege access, the moderation queue surfaced, payment ops (refunds, disputes, payout investigation), entitlements and feature flags, curation tooling, manual balance adjustment, audit log of every admin action, single-user support view |
| Search | L | 6 | ×2 | BE+FE | Infrastructure choice, indexing for articles/projects/users/orgs, re-index hooks for later types, query parsing/ranking/typo tolerance, filters and facets, permission-aware results (drafts, paywalled, protocol-gated). Partial ilike build already exists — Postgres FTS with tsvector/GIN likely suffices at this volume |
| Internationalisation & localisation | XL | 12 | ×3 | BE+FE | Locale routing and detection, string extraction and translation pipeline, per-locale formatting, RTL, translated-content model for UGC with fallbacks, translator tooling, localised email and notification templates, hreflang and localised sitemaps |
Two sequencing notes, no reordering implied.
| Segment | wks | +30% | 4 eng, realistic |
|---|---|---|---|
| Content surfaces (Ed Resources, Open Calls) | 18 | 23.4 | ~8 cal-wks |
| Compliance & hardening (reporting → GDPR) | 20 | 26.0 | ~8 cal-wks |
| Platform (Admin console, Search, i18n) | 30 | 39.0 | ~14 cal-wks |
| Invites | 6 | 7.8 | ~2 cal-wks |
| Phase 2 total | 74 | 96.2 | ~32 cal-wks |
This phase parallelises better than Phase 1 — compliance and hardening work is largely independent of the content surfaces, so two streams run cleanly for most of it. The exception is i18n: its cost scales with everything already shipped, so it gets more expensive every phase it waits.
12 open items · 75 wks · ~8 cal-months.
| Item | Size | wks | Par | Owner | Spec |
|---|---|---|---|---|---|
| Transactional email & delivery (ops) | L | 6 | ×1 | BE | Provider selection and SPF/DKIM/DMARC, template system, plain-text fallbacks, per-type routing with unsubscribe and preference centre, bounce/complaint suppression, deliverability monitoring and reputation warm-up, transactional/marketing separation with consent records, localisation hooks. Resend client already exists. Domain warm-up is calendar time, not work — start DNS phases earlier |
| Sidebar category filters | S | 2 | ×1 | FE | Global category colour filters in the sidebar, distinct from in-feed Feed filters. Contrast requirements interact with the Phase 2 accessibility audit |
| Indigenous Knowledge Hub | M | 3 | ×2 | BE+FE | Parallel cultural hierarchy with protocol-gated visibility and stewardship roles. Protocol gating must be enforced in RLS, not per-call — it has to hold in feeds, search and exports alike |
| Notes & bookmarks | M | 3 | ×2 | BE+FE | Personal saved content and notes. Extends the existing bookmarks table. RLS owner-only, no exceptions |
| Connections & blocking | M | 3 | ×2 | BE+FE | Rewire existing connections into profiles, re-enable blocking. Blocking must be enforced in RLS or shared query helpers, never per-call — every feed, search and comment path has to honour it, and a per-call check gets missed. Most likely item in this phase to overrun |
| Privacy settings | M | 3 | ×1 | FE | Dedicated privacy area binding visibility rules to the blocking enforcement layer. Adds no enforcement of its own |
| Organisation verification system | M | 3 | ×2 | BE+FE | Verified badges with application and review workflow. Needs the admin console from Phase 2 for the review side |
| Article reactions | S | 2 | ×1 | FE | Extends the existing reactions table. Optimistic UI, per-user uniqueness enforced in the database |
| Recommendation & ranking engine | XXL | 20 | ×4 | BE+FE | For You / Trending / Featured tab shell and per-tab sources, engagement signals, social-graph signals, scoring with trending velocity and decay plus anti-gaming, cold-start handling, permission-aware filtering (drafts, paywalled, protocol-gated, blocked), Featured curation tooling, right-hand sidebar, precomputation and caching. Needs real engagement history to tune — building it before there is traffic means tuning against noise |
| Events | L | 6 | ×2 | BE+FE | Creation and editing for users and orgs, calendar and list views with timezone handling, RSVP and capacity, reminders (depends on Notifications), recurring events and cancellation. NewEventDialog exists; schema does not |
| Messaging | XL | 12 | ×3 | BE+FE | Conversation and message model, realtime transport with delivery guarantees, read receipts and typing state, blocking and privacy enforcement, attachments and links, abuse reporting and a moderation surface for DMs, retention and export obligations. The DM abuse surface is real ongoing operational load, not a one-time build |
| Notifications — second pass | XL | 12 | ×3 | BE+FE | Settings screen with per-type preferences and mute, quick actions, grouping and digest rollups, fan-out and batching, retention and auto-clearing (30-day/one-year), realtime replacing polling, scheduled time-based notifications, plus the types held back in Phase 1: payments, funding, contributions, reviews, bounties, Open Call applications, role changes, email digests |
Blocking is load-bearing for two items above it. Privacy settings and Messaging both assume the enforcement layer from Connections & blocking. If blocking ships weak, both inherit the weakness.
| Segment | wks | +30% | 4 eng, realistic |
|---|---|---|---|
| Email + small surfaces (sidebar, reactions) | 10 | 13.0 | ~5 cal-wks |
| Social layer (IKH, notes, connections, privacy, verification) | 15 | 19.5 | ~6 cal-wks |
| Ranking engine | 20 | 26.0 | ~8 cal-wks |
| Events + Messaging + Notifications 2 | 30 | 39.0 | ~12 cal-wks |
| Phase 3 total | 75 | 97.5 | ~31 cal-wks |
The ranking engine is the widest item in the roadmap at ×4 and the only one that genuinely absorbs the whole team. It is also the one most dependent on having users — its estimate is the least reliable in this document.
17 open items · 188 wks · ~19 cal-months. 47% of everything remaining.
| Item | Size | wks | Par | Owner | Spec |
|---|---|---|---|---|---|
| Tokenomics simulation & parameter review (ops) | L | 6 | ×1 | BE | Model the PRG emissions ladder against projected activity and the $OZN mint rate under realistic PRG supply. Close the self-dealing loop: tipping earns 10 PRG per US$1 while 100 PRG staked wins 1 $OZN for 50 PRG, so trading between two accounts mints $OZN for the transaction fee alone. Sybil requirements and cost-per-fake-account, buff caps and runaway bounds, decay and recycling, revised parameter table reconciled against the white paper |
| Regulatory & custody assessment (Legal, ops) | L | 6 | ×1 | BE | External counsel across operating jurisdictions: MiCA classification of $OZN and PRG, FCA registration and financial-promotions scope, securities treatment of the ICO and of founding-member grants, custodial vs self-custody determination, KYC/AML obligations and provider, review of existing public claims. A gate, not a task — 4–12 week external lead time, and the answer changes the architecture below |
| Attestation & signed claims | L | 6 | ×2 | BE+FE | Attestor roles and governance control of the attestor set, claim schema/signing/verification, issuance surfaces for reviewers and pods, replay protection and single-use, revocation and downstream clawback, audit trail, on-chain path once wallets exist. The mechanism behind every variable PRG reward |
| Treasury accounting & disbursement (ops) | XL | 12 | ×2 | BE+FE | Foundation PRG balances, inflows and recycling; off-chain ledger and reconciliation; disbursement request/approval/execution; pod, org and project treasuries; budget allocation and spend caps; multisig binding later; DAO disbursement fee (0–1%); public reporting |
| Progress (PRG) contribution ledger | XL | 12 | ×3 | BE+FE | Balance and earning-event model; hooks into publishing, review, Open Calls, funding, tipping; bidirectional emissions ladder; inactivity decay and recycling; buffs and streaks with caps; attestor pathway; reconciliation reporting; backfill of pre-ledger events; anti-farming limits and audit trail; founding-member 1,000 PRG grant; reconciliation against white-paper supply tables. PRG is non-transferable, so this needs no chain — it is a ledger, and it is the authority that later mints $OZN |
| Quizzes | L | 6 | ×2 | BE+FE | Authoring, question bank, answer storage, taking, scoring, attempt history, per-learner progress, anti-cheat hardening. Answers never reach the client — scoring server-side, question payload excludes the correct answer. Retrofitting that after Learn2Earn pays out means re-issuing every grade |
| Learn2Earn rewards | L | 6 | ×2 | BE+FE | 1 PRG per correct answer plus 1 to the creator, answer-verification hardening against client tampering, per-user/per-resource/per-period caps, retake and repeat-answer rules, streak integration, creator earnings visibility |
| DAO pods | XL | 12 | ×3 | BE+FE | Pod creation, membership and roles; proposal lifecycle (draft, active, resolved, executed); pod-scoped vs public visibility; pod treasuries and wallet binding; pod-level bounty and Open Call authority; private founding-member pod. Overlaps Progress-weighted governance below — the two are merge candidates |
| Progress-weighted governance | XL | 12 | ×3 | BE+FE | Proposal deposits by actor type (100/200/300 PRG), per-actor vote caps, tiered refund ladder on a 72-hour window, 85% passing threshold and quorum, windows up to 30 days, deposit forfeiture routed to Treasury. Overlaps DAO pods |
| DAO-driven inclusion queue | L | 6 | ×2 | BE+FE | Moves Educational Resources curation from Foundation-selected to governance-approved: proposal submission, queue surface and states, vote binding, outcome execution into the library, migration from curated entries |
| Open Calls — DAO endorsement flow | L | 6 | ×2 | BE+FE | Moves endorsement from org-run to governance-approved: endorsement proposal from an existing call, vote binding, endorsed badge and ranking effect, migration |
Everything below gates on the two assessments above.
| Item | Size | wks | Par | Owner | Spec |
|---|---|---|---|---|---|
| Wallet & custody layer (Legal, ops) | XXL | 20 | ×3 | BE+FE | Custodial vs self-custody as set by the regulatory assessment, provisioning and account binding, key management/rotation/recovery, gas abstraction, transaction/pending/failure states across every money surface, chain and RPC selection with failover, security review of the key path |
| $OZN contracts & external audit (ops) | XXL | 20 | ×2 | BE | Capped ERC-20 $OZN, soulbound PRG if it moves on-chain, treasury multisig and signer policy, indexer with reorg handling and reconciliation against the platform ledger, deployment/upgrade/emergency-pause strategy, external audit with 4–12 week lead time, repeated after changes, remediation and re-audit |
| Public ICO & fiat on-ramp (Legal) | XXL | 20 | ×2 | BE+FE | Sale mechanics and allocation caps, KYC/AML provider and onboarding, third-party fiat on-ramp, exchange listing and liquidity, vesting for team/partnership/Foundation, jurisdiction gating and restricted territories. The build above is investor and grant funded — the ICO is a liquidity event, not what pays for it |
| Proof-of-Progress staking | XXL | 20 | ×3 | BE+FE | Rounds with minimum 50 PRG and full probability at 100 PRG, verifiable randomness (Chainlink VRF or equivalent), consecutive-loss boost at 314bp, minting from the 750M reserve with exhaustion handling, PRG cost on win routed to Treasury, auto-unstake below threshold. Highest-risk component in the system: the off-chain ledger becomes the minting authority for a liquid asset, so a scoring bug mints money |
| $OZN funding & tipping rails | XL | 12 | ×2 | BE+FE | Token payment flows on projects, articles and Open Calls; price oracles for PRG conversion; dual-rail UX where fiat and $OZN both apply; failure, retry and reconciliation against the fiat rails; bounty payouts |
| Platform fee engine (ops) | L | 6 | ×1 | BE | Governance-configurable rates with bounded min/max, fee bands (funding 5%, tipping 9%, bounties 9%), migration from the hard-coded Phase 1 Stripe take, DAO disbursement fee, revenue reporting and Reserve routing |
| Segment | wks | +30% | 4 eng, realistic |
|---|---|---|---|
| Assessments (tokenomics, regulatory) | 12 | 15.6 | ~8 cal-wks |
| Ledger & attestation (attestation, treasury, PRG) | 30 | 39.0 | ~13 cal-wks |
| Learning rewards (quizzes, Learn2Earn) | 12 | 15.6 | ~5 cal-wks |
| Governance (pods, weighted gov, 2 migrations) | 36 | 46.8 | ~15 cal-wks |
| Chain layer (wallet, contracts, ICO, staking) | 80 | 104.0 | ~34 cal-wks |
| Rails & fees | 18 | 23.4 | ~7 cal-wks |
| Phase 4 total | 188 | 244.4 | ~82 cal-wks |
Three things make this phase behave unlike the others.
The assessments are calendar, not effort. Twelve person-weeks, but external counsel and modelling run on someone else's clock — budget ~8 calendar weeks even though the team is barely occupied. Start them a phase early; they cost little and gate everything.
Extra engineers buy almost nothing after the milestone. The chain layer is 80 of the 188 weeks and is strictly sequential: custody decision → wallet layer → contracts → audit → remediation → staking. The external audit alone is 4–12 weeks of waiting, and it repeats after any change.
Governance has a merge candidate inside it. DAO pods and Progress-weighted governance are 24 weeks between them and cover overlapping ground. Resolving that overlap before building is the single cheapest saving available in this phase.
| Phase | Open | wks | +30% | 4 eng |
|---|---|---|---|---|
| Phase 1 | 13 | 63 | 81.9 | ~28 cal-wks |
| Phase 2 | 12 | 74 | 96.2 | ~32 cal-wks |
| Phase 3 | 12 | 75 | 97.5 | ~31 cal-wks |
| Phase 4 — Token economy | 17 | 188 | 244.4 | ~82 cal-wks |
| Total | 54 | 400 | 520 | ~173 cal-wks |
~3 years 4 months at four engineers with overhead applied, against the ~7 years 8 months the source estimate gives for a single stream. The difference is headcount, not optimism.
Two figures worth holding onto: