Internal tools, sorted by the team that needs them.

Build a Customer Feedback Inbox. Core objects: Feedback (source email/call/chat/review, customer, body, sentiment positive/neutral/negative, themes as tags, product area, date, linked ticket). Screens: 1. Inbox — chronological list with filter chips for sentiment, theme and product area, plus full-text search. 2. Themes view — each theme with its volume, sentiment split, and a sample of quotes. 3. Weekly digest — the top five themes of the last seven days with counts and representative quotes. Rules: allow bulk tagging from the inbox. Show a simple bar chart of feedback volume per theme. Design: dashboard with left sidebar, dark mode, quotes rendered as bordered pull quotes.

Build a Legal Intake and Review Queue. Core objects: LegalRequest (title, requesting team, request type Contract review/Marketing claim/Data privacy/Partnership/Other, description, urgency, attachments, risk level Low/Medium/High, reviewer, status New/Triaged/In review/Needs info/Approved/Approved with changes/Rejected, submitted at, closed at). Screens: 1. Intake form with type-specific questions. 2. Triage queue — new requests sorted by urgency, with a risk level selector and reviewer assignment. 3. Review workspace — request details, internal notes, outcome selection with required rationale. 4. Metrics strip — median turnaround time and open requests by risk level. Rules: turnaround = closed at minus submitted at, only counted for closed requests. Design: dashboard with left sidebar, restrained palette with accent used only for risk and status, dark mode support.

Build a Project Portfolio Dashboard. Core objects: Project (name, owner, sponsor, team, start date, target date, status Not started/On track/At risk/Off track/On hold/Done, summary), Milestone (project, title, due date, done) and Risk (project, description, impact, likelihood, mitigation, owner, status). Screens: 1. Portfolio grid — one card per project showing RAG status, next milestone, days to target and open risk count. 2. Project detail — milestone timeline, risk register and a status update feed. 3. Weekly review — a printable summary of all projects with this week's status commentary. Rules: a status change requires a short commentary. Automatically flag At risk when the next milestone is overdue. Design: dashboard with left sidebar, RAG shown with restrained colour, dark mode support.

Build a Meeting and Action Tracker. Core objects: Meeting (title, series, date, attendees, agenda, notes), Action (meeting, description, owner, due date, status Open/Done/Cancelled) and Decision (meeting, description, decided by). Screens: 1. Meetings list grouped by series, newest first. 2. Meeting workspace — agenda on the left, notes in the middle, actions and decisions captured inline with quick-add. 3. Actions view — all open actions across meetings, filterable by owner, with overdue items flagged. Rules: opening a new meeting in a series automatically carries over open actions from the previous one. Design: dashboard with left sidebar, fast keyboard-friendly capture, dark mode support.

Build a Bug Triage Board. Core objects: Bug (title, reporter, area, environment, steps to reproduce, expected, actual, severity S1-S4, status New/Triaged/Accepted/In progress/Fixed/Won't fix/Duplicate, assignee, duplicate of, first seen, occurrences). Screens: 1. Triage inbox — new bugs sorted by severity, with quick actions to accept, mark duplicate or decline with a reason. 2. Board — columns by status, cards showing severity badge and area. 3. Bug detail — full report, occurrence count, linked duplicates, and a comment thread. Rules: S1 bugs pin to the top of every view. Marking a duplicate links the two and merges occurrence counts. Design: dashboard with left sidebar, monospace for environment and steps, dark mode support.

Build a Deployment and Release Log. Core objects: Release (version, environment staging/production, deployed at, deployed by, changes list, risk level, rollback of, status Deployed/Rolled back/Failed, notes) and Incident (release, description, severity, started at, resolved at). Screens: 1. Timeline — reverse-chronological releases per environment with version, author and change count. 2. Release detail — the full change list, linked incidents, and a rollback action that creates a linked rollback record. 3. Release notes view — a clean, shareable summary of changes between two versions. Rules: never edit a released entry; corrections are appended as notes. Show time since last production release. Design: dashboard with left sidebar, monospace for versions and timestamps, dark mode support.

Build a Data Request Queue. Core objects: DataRequest (title, requester, team, business question, decision it informs, deadline, effort estimate, priority score, analyst, status New/Prioritised/In progress/Blocked/Delivered/Declined, answer summary, dashboard link). Screens: 1. Intake form that forces a business question and the decision it will inform. 2. Prioritisation board — requests scored by impact and effort, sorted, with drag to reorder. 3. Request detail — thread with the requester, answer summary and links to the resulting dashboard or query. 4. Delivered archive, searchable, so repeat questions get an instant answer. Rules: a request cannot move to In progress without an analyst and an effort estimate. Design: dashboard with left sidebar, dark mode, mono labels for scores.

Build a Metrics Definition Catalogue. Core objects: Metric (name, synonyms, plain-English definition, formula, grain, source system, owner, refresh cadence, caveats, related dashboards, status Draft/Approved/Deprecated) and DefinitionVersion (metric, body, changed by, changed at, reason). Screens: 1. Catalogue — searchable list grouped by domain, matching on name and synonyms. 2. Metric detail — definition, formula in a monospace block with a copy button, caveats callout, and links to dashboards. 3. Change history for each metric with a reason per change. Rules: only approved metrics appear in the default catalogue view; deprecated ones show a clear banner pointing to their replacement. Design: documentation-style dashboard, left sidebar, monospace formulas, dark mode support.

Build an Experiment Tracker. Core objects: Experiment (name, owner, surface, hypothesis, primary metric, guardrail metrics, variants with traffic split, start date, end date, sample size, status Planned/Running/Concluded/Abandoned, result lift, confidence, decision Ship/Rollback/Iterate, learnings). Screens: 1. Experiments list with status filters and a running-now section. 2. Experiment detail — hypothesis and metric definitions up top, results panel below, decision and learnings at the bottom. 3. Learnings library — concluded experiments searchable by surface and metric, showing only hypothesis, result and learning. Rules: an experiment cannot be concluded without a result, a decision and a written learning. Design: dashboard with left sidebar, dark mode, results shown with mono numerals and a clear lift indicator.

Build a Content Calendar. Core objects: ContentPiece (title, channel blog/newsletter/social/video, campaign, owner, reviewer, brief, target publish date, status Idea/Drafting/In review/Scheduled/Published, asset checklist, published URL). Screens: 1. Calendar month view with pieces on their target dates, colour-coded by channel. 2. Pipeline list grouped by status with owner filters. 3. Piece detail — brief, draft link, asset checklist (copy, image, thumbnail, alt text) and review comments. Rules: a piece cannot move to Scheduled until every asset checklist item is ticked and a reviewer has approved. Design: dashboard with left sidebar, calendar cells with subtle channel accents, dark mode support.

Build a Product Feature Request Board. Core objects: FeatureRequest (title, description, submitted by, area, votes, linked accounts with value, status Under review/Planned/In progress/Shipped/Not planned, merged into, roadmap item) and Vote (request, voter, account, note). Screens: 1. Board — requests sorted by weighted demand (vote count plus linked account value), with area filters and search. 2. Request detail — description, supporting notes from voters, linked accounts, and status with a public-facing update. 3. Merge flow — combine duplicates, transferring votes and linked accounts. Rules: changing status requires an update note that is shown to everyone who voted. Not planned requires a reason. Design: dashboard with left sidebar, compact request rows with vote counts in mono, dark mode support.

Build a Product Roadmap Planner. Core objects: RoadmapItem (title, outcome, success metric, horizon Now/Next/Later, quarter, owner, team, confidence High/Medium/Low, effort T-shirt size, dependencies, linked feature requests, status) and Change (item, field, from, to, reason, date). Screens: 1. Roadmap board — Now / Next / Later columns with cards showing outcome, confidence and effort. 2. Quarter view — items grouped by quarter and team, with dependency warnings when an item depends on something scheduled later. 3. Item detail — outcome, metric, linked requests and full change history. Rules: every item must state an outcome and a success metric before leaving Later. Moving an item between horizons requires a reason. Design: dashboard with left sidebar, confidence as mono uppercase badges, dark mode support.