TOSSE v1 · internal
Built for ourselves · running in production

The CRM we built to replace Notion, wired into our AI agents.

Two freelance engineers. One monorepo. An MCP server, cascading AI context on every entity, and a full-stack workflow Claude can understand without being told twice.

Lines of TS
~42k
MCP tools
30+
Services on Railway
3
Humans using it
2
TOSSE dashboard — active projects, balance between the two freelancers, upcoming invoicing

The pillar

Every entity carries the context an AI needs to help.

Clients, missions, projects, tasks — each one owns a dedicated AI Context block. We write there what matters: who the decision-maker is, the rollback rule, the cadence of reviews, the compliance constraint. TOSSE exposes that cascade through an MCP server, so Claude Code (and any MCP-capable agent) reads it with a single tool call and acts with the same understanding we would.

This is the reason we built TOSSE in the first place. Every other feature serves this one.

Client · Nordway Labs
Client detail — AI context with company profile and working style
Mission · Payments v3
Mission detail — AI context with critical path and rollback rule
Task · KYC migration
Task detail — AI context with contract, validation rules, resumability
Repo · nordway/payments
Repository detail — AI context with conventions, testing, deployment

Each AI Context block is scoped to its level — client-wide details on the client, mission-specific on the mission, task-specific on the task, codebase-specific on the repository. The MCP cascade stitches them together on demand; duplication is forbidden at the data layer.

MCP in action

What a Claude conversation looks like on top of TOSSE.

Same session, our terminal, Claude Code. No prompt engineering, no pasted context — just MCP tools reading the cascade.

alexandre@studio — claude · tosse-mcp
you › What should I focus on today for Nordway? Anything blocked?
tool get_context(entity_type="client", name="Nordway Labs")
tool get_tasks(mission_id="…Payments v3…", include_subtasks=true)
tool get_task_relations(task_id="KYC data migration script")
claude ›

Two critical items on Payments v3:

  • Checksum diff job — the last dual-write guard before cutover. Eira wanted it green for 24h before T-0; currently in progress, ETA Friday.
  • KYC migration scriptblocked by the dual-write shim. Can't move it yet.

The Nordway context says decisions are fast but PRs should include a Loom; I'd prepare the checksum diff walkthrough before posting it. Want me to draft the Loom outline?

you › Yes — and create a follow-up task to schedule the compliance review once the shim is green.
tool create_task(project_id="…Payments service v3…", title="Schedule compliance review once dual-write is green", …)
tool add_task_relation(blocking="Checksum diff job", blocked="Schedule compliance review…")
claude › Done. Task created on Payments service v3, priority Haute, due next Tuesday, blocked by the checksum diff job so it won't surface in briefings early.

Task management

Kanban, subtasks, and a dependency graph that behaves.

Drag a task, it moves. Complete every subtask, the parent auto-ships to Review. Mark one task as blocking another; the graph view redraws with the critical path, and the blocker shows an outgoing chain on the kanban card. Only a human flips a task to Done.

Dependency graph · Payments v3 · 15 tasks, 23 blocking relations
Project dependency graph — parallel tracks converging on cutover
Kanban · grouped by project
Kanban board grouped by project

Finance

Our accounting lives here, plugged into every mission.

  • Every revenue line is attached to a mission and tagged with an author — a live 50/50 balance shows who owes whom.
  • Our Qonto account is plugged in: incoming transactions are matched to invoices automatically, ambiguous ones surface side-by-side for a one-click confirm.
  • Analytics, recurring invoices, and cash-in forecasts are one page away — no Notion, no spreadsheet.
Finance page with 50/50 balance and Qonto reconciliation tab
Settings page with connected integrations and health checks

Integrations

Connected to the tools we already use.

Every integration runs a health check on a cron; a red pill on the Settings page is how we hear about a broken OAuth token before the user does.

  • Google Calendar

    OAuth2 · read-only sync of client meetings

  • iCloud Calendar

    Shared .ics URL · read-only sync

  • GitHub

    Repos linked to projects · PR + commit activity

  • Qonto

    Bank API · transactions sync + reconciliation

How it stays clean

Four invariants we don't negotiate.

Anti-redundancy on context

Context cascades from client → mission → project → task. We never repeat parent context in a child. The MCP server exposes the whole chain in a single call so agents see only what matters, once.

Deletion is archival

DELETE endpoints set status = Archivé. Nothing is actually gone. Analytics, activity logs, and the audit trail stay trustworthy.

Human-in-the-loop, by default

Agents can create, edit, and move tasks to Review. Only a human flips a task to Done. The rule is enforced in the backend, not the prompt.

Auto-sync, auto-broadcast

Every mutation emits an SSE event and appends to activity_log. Any open browser tab updates without a refresh.

Stack

Modern, opinionated, boring on purpose.

No microservices. No Kubernetes. Three Railway services, one monorepo, one language across the stack. The interesting choices are the Bun runtime and the MCP server; everything else is boring infra that stays out of the way.

Next.js 16

App Router, React Server Components

Hono on Bun

Sub-10ms API latency at idle

PostgreSQL 16

Prisma ORM, SQL views for aggregates

Better Auth

Cross-domain sessions, password reset

MCP SDK

Streamable HTTP + OAuth2 per-user

SSE

Realtime mutations to all open clients

Playwright

E2E tests + automated screenshots

Railway

Three-service Docker deployment

We're Alexandre & Armand.

Two freelancers. We built TOSSE for ourselves — to cut friction in our day-to-day, ship faster, and weave AI into the way we actually work, not as a chatbot bolted on the side. It's the tool we wished existed.

If this is the kind of software you'd want in your stack, get in touch.