Brainforge Knowledge

brainforge-internal-tools-roadmap

7 min read

Brainforge Internal Tools Roadmap

Status: Living document
Last updated: 2026-03-02
Overview: Master roadmap of internal tools for the brainforge-platform, categorized by business area, ranked by impact, with size estimates and data source dependencies. Includes the two detailed plans already created (Calendar Clockify Redesign and Allocation vs. Actuals Dashboard).

Active Plans (detailed, ready to build)

0a. Calendar Clockify Redesign — IN PROGRESS

  • Status: Plan confirmed, pending execution
  • Branch: codex/linear-mention-ai-768-integrate-google-calendar-events-wit
  • Scope: Redesign the Calendar Clockify sync tool with best-in-class time tracking UX (Toggl/Harvest patterns), inline project assignment, already-synced detection, weekly navigation, and metric cards
  • Key files: apps/platform/src/components/CalendarClockifySync.tsx, new API routes for projects/user/entries
  • UX research: Toggl (color-coded blocks, calendar view, gap detection), Harvest (weekly grid, inline project assignment), Tymewise (progress bars, clear hierarchy)

0b. Allocation vs. Actuals Dashboard — PLANNED

  • Status: Detailed plan stored at .cursor/plans/allocation_vs_actuals_dashboard_2627d554.plan.md
  • Scope: Pull planned allocations from Operating API + actual hours from Clockify, eliminate manual copy-paste between systems
  • Data sources: Operating API (assignments, allocations, persons, projects, reports), Clockify API (time entries)
  • Key deliverables: Operating SDK, person-matching logic, utilization API route, three-view dashboard (team/person/project)

Tier 1: High Impact, Small Build (do these next)

1. SOW Burn Tracker

  • Area: Operations / Delivery
  • Impact: HIGH
  • Size: Small
  • What: Shows budget consumed vs. remaining per client/SOW, updated from Clockify actuals. Alerts at 80% burn.
  • Why now: Prevents over-delivery and scope creep. SOW data exists in knowledge/clients/*/sows/, actuals exist in Clockify. Just needs a join + UI.
  • Data sources: Clockify time entries, Operating project budgets, vault SOW files (for seeding)
  • Depends on: Calendar Clockify redesign (establishes Clockify API patterns)

2. Timesheet Reminder Bot

  • Area: Operations / Data Quality
  • Impact: HIGH (force multiplier — fixes input quality for every other tool)
  • Size: Small
  • What: Slack bot checks Clockify on Friday: “You’ve logged 28 of 40 hours. Missing Tuesday and Thursday.” Links to Calendar Clockify sync page.
  • Why now: Incomplete timesheets are the #1 reason planned-vs-actual data is useless. This fixes the input problem.
  • Data sources: Clockify API (time entries per user per week), Slack API
  • Depends on: Clockify SDK (already exists), Slack bot infrastructure (apps/slack-apps/brainforge-assistant/)

3. Meeting Context Card (Page)

  • Area: Client Relationships
  • Impact: MEDIUM-HIGH
  • Size: Small
  • What: Persistent page per client showing last 3 meeting summaries, open Linear tickets, hours burned this month, blockers. The meeting-prep skill (.cursor/skills/meeting-prep/SKILL.md) as a UI anyone can access.
  • Why now: The skill already exists. Wrapping it in a page multiplies value across the whole team, not just whoever asks the agent.
  • Data sources: Vault transcripts (knowledge/clients/{client}/transcripts/), Linear API (issues), Clockify (hours this period)
  • Depends on: Existing meeting-prep skill, Linear API (apps/platform/src/lib/linearApiServer.ts)

Tier 2: High Impact, Medium Build

4. Client Health Scorecard

  • Area: Client Relationships / Retention
  • Impact: HIGH
  • Size: Medium
  • What: Auto-generated score per client based on: hours on track (Clockify vs SOW), ticket velocity (Linear), meeting cadence (Google Calendar), responsiveness (email/Slack). Red/yellow/green at a glance.
  • Why now: Leading indicator of churn. By the time you notice a client is unhappy, it’s often too late.
  • Data sources: Clockify, Linear, Google Calendar API, Operating (project status)
  • Depends on: SOW Burn Tracker (reuses budget data), Calendar Clockify (reuses calendar patterns)

5. Pipeline Capacity Overlay

  • Area: Sales / Revenue
  • Impact: HIGH
  • Size: Medium
  • What: Pulls deals from HubSpot pipeline, maps needed roles/hours to Operating availability. Shows: “If we close Deal X and Deal Y, we need 2 more senior engineers by March.”
  • Why now: Prevents the feast-or-famine cycle. Gives weeks of lead time on hiring/contracting decisions.
  • Data sources: HubSpot CRM (deals, pipeline stages), Operating API (persons, availability, skills)
  • Depends on: Operating SDK (from Allocation vs. Actuals plan), HubSpot MCP (already available)

6. Client Handoff Automator

  • Area: Operations / Sales-to-Delivery
  • Impact: HIGH
  • Size: Medium
  • What: When a deal closes in HubSpot, auto-creates: Operating project, Linear board, vault client folder structure, Slack channel. Pre-populates from SOW/proposal data.
  • Why now: The sales-to-delivery handoff is where context gets lost. All the APIs exist (HubSpot MCP, Linear MCP, Operating MCP). This wires them together.
  • Data sources: HubSpot (deal close trigger), Operating (create project), Linear (create team/board), vault (folder templates)
  • Depends on: Operating SDK, Linear API, HubSpot MCP

7. Revenue Forecast Dashboard

  • Area: Finance / Sales
  • Impact: MEDIUM-HIGH
  • Size: Medium
  • What: Confirmed revenue (Operating allocations x rates) + weighted pipeline (HubSpot deal probability). Monthly rolling view: “March: Y probable, $Z possible.”
  • Why now: Cash flow visibility is critical for a growing agency. Operating has project financials, HubSpot has the pipeline.
  • Data sources: Operating API (projects, budgets, rates), HubSpot CRM (pipeline, deal amounts, probability)
  • Depends on: Operating SDK, Pipeline Capacity Overlay (shares data layer)

Tier 3: Medium Impact, Small-Medium Build

8. Skills Heatmap

  • Area: People / Team
  • Impact: MEDIUM
  • Size: Small
  • What: Pulls skills data from Operating (skills with levels and sentiments per person). Matrix view: people on Y-axis, skills on X-axis, colored by proficiency. Shows gaps like “nobody knows Kubernetes above beginner.”
  • Why now: Makes hiring and staffing decisions data-driven. Operating already stores this data — just needs visualization.
  • Data sources: Operating API (persons, skills, skill levels, skill sentiments)
  • Depends on: Operating SDK

9. Proposal Hours Estimator

  • Area: Sales / Delivery
  • Impact: MEDIUM
  • Size: Medium
  • What: Given a project description, pulls historical data from similar past projects (Clockify actuals, Operating budgets) to suggest hours per role. “Projects like this typically take 120 engineering hours and 40 design hours.”
  • Why now: Estimation accuracy directly impacts margin. Historical data makes you better over time.
  • Data sources: Clockify (historical time entries), Operating (past project budgets and actuals)
  • Depends on: Allocation vs. Actuals Dashboard (establishes the data join), Operating SDK

10. Weekly Team Pulse

  • Area: People / Culture
  • Impact: MEDIUM
  • Size: Small
  • What: Friday async check-in via Slack: “How was your week?” (1-5 scale) + optional comment. Aggregated anonymously on a dashboard.
  • Why now: Small teams avoid surveys, but burnout sneaks up. A 5-second pulse catches it. Low effort, high signal.
  • Data sources: Slack bot (input), Supabase (storage), dashboard (output)
  • Depends on: Slack bot infrastructure
  • Area: Knowledge / Learning
  • Impact: MEDIUM
  • Size: Small-Medium
  • What: Full-text search across the vault (transcripts, SOWs, resources, meeting notes). “What did we discuss with Lilo about the API migration?”
  • Why now: The vault is growing but discovery is hard. A search page makes documented knowledge actually usable.
  • Data sources: Vault markdown files (indexed), Supabase or Algolia for search
  • Depends on: None (standalone)

Tier 4: Nice to Have

12. Playbook Compliance Checker

  • Area: Knowledge / Quality
  • Impact: LOW-MEDIUM
  • Size: Small
  • What: GitHub Action that checks knowledge/playbook PRs follow the right template. “This transcript is missing the date-stamp header.”
  • Why now: Keeps the vault clean as more people contribute. Preventive.
  • Data sources: Git diff, playbook templates
  • Depends on: None (GitHub Action)

13. Deploy Status Dashboard

  • Area: Engineering
  • Impact: LOW-MEDIUM
  • Size: Small
  • What: Railway service health, last deploy time, build status across all services in one page.
  • Why now: Multiple Railway services exist. Checking each individually is tedious.
  • Data sources: Railway MCP (already available)
  • Depends on: None

14. Dependency / Security Scanner

  • Area: Engineering
  • Impact: LOW
  • Size: Small
  • What: Weekly npm audit across the monorepo. Slack alert if critical vulnerabilities found.
  • Data sources: npm audit, GitHub Actions
  • Depends on: None

Suggested Build Order

NOW:        0a. Calendar Clockify Redesign (in progress)
NEXT:       0b. Allocation vs. Actuals Dashboard
            1.  SOW Burn Tracker
            2.  Timesheet Reminder Bot
THEN:       3.  Meeting Context Card
            4.  Client Health Scorecard
            5.  Pipeline Capacity Overlay
LATER:      6.  Client Handoff Automator
            7.  Revenue Forecast Dashboard
            8.  Skills Heatmap
BACKLOG:    9.  Proposal Hours Estimator
            10. Weekly Team Pulse
            11. Vault Search
            12-14. Nice to haves

Shared Infrastructure

Several tools share the same data layer. Building them in the suggested order means each new tool reuses work from the previous one:

  • Operating SDK (built in 0b) is reused by: 1, 4, 5, 6, 7, 8, 9
  • Clockify API patterns (built in 0a) are reused by: 0b, 1, 2, 4, 9
  • Slack bot infrastructure (exists at apps/slack-apps/brainforge-assistant/) is reused by: 2, 10
  • Linear API (exists at apps/platform/src/lib/linearApiServer.ts) is reused by: 3, 4, 6
  • HubSpot MCP (already available) is reused by: 5, 6, 7
  • Vault file access is reused by: 3, 11

Graph View