Cinch: a production collaboration platform built on evidence, not demos

Cinch started with a plain question: what would a collaboration platform look like if it kept what people value in Slack but was calmer, more transparent, more inclusive, and more disciplined about enterprise trust? Answering it properly meant building the whole thing, not a prototype.

I work on it as a hands-on product owner, engineer, and operator. The operating loop is deliberately practical.

• Identify a product need, usability problem, operational risk, or competitive gap.
• Inspect the current implementation and its architectural boundaries.
• Define the expected behavior, permissions, failure modes, and privacy implications.
• Implement the smallest coherent increment.
• Test it against a clean database and a realistic application environment.
• Exercise it in production when risk and maturity justify it.
• Preserve evidence and record the architectural decision.
• Promote a public claim only when the evidence supports it.

Cinch is a functioning multi-tenant collaboration platform: workspaces on dedicated tenant hostnames, public and private channels, direct and group messages, threads, reactions, mentions, ranked search, scan-gated file uploads, reminders, drafts, scheduled messages, presence, and keyboard-first navigation.

It also tries to do more than deliver an endless stream. Focus gives each person an explainable starting point built from unread conversations, assigned actions, and saved items, with no hidden ranking. Briefs, Canvas, decisions, actions, and My Actions let a conversation turn into durable work without losing the thread it came from.

Huddles run on managed LiveKit infrastructure (audio, screen sharing, moderation, encrypted media) rather than a home-grown media network. Identity and administration cover TOTP, recovery codes, passkeys, OIDC, SCIM users and groups, verified domains with optional automatic enrollment, guest expiry, session controls, retention, export, and access reviews. A private operations console runs the service across workspaces with narrow, audited authority.

Accessibility is treated as a product capability: reduced motion, reflowed reading modes, optional suppression of presence cues, explicit author and time context, image descriptions, consistent focus management, and optional "how I work best" profiles.

The stack is a TypeScript monorepo: Next.js for the account, tenant, API, and administration surfaces; PostgreSQL with Drizzle as the durable source of truth; Rocicorp Zero maintaining tenant-scoped browser replicas for local-first interaction; Redis for ephemeral signals; S3 for private file bytes; LiveKit for media. It runs on Fly Machines behind Cloudflare, with Terraform managing storage, monitoring, DNS, state, and backups.

The technologies matter less than the boundaries around them. Five are load-bearing.

• Host boundary: account, tenant, sync, and marketing origins have distinct responsibilities and credentials. A routine application release cannot publish the marketing site or touch apex DNS.
• Tenant boundary: a hostname selects a tenant but never authorizes one. The server re-proves identity, membership, workspace, role, and trial state on every request.
• Data boundary: PostgreSQL owns durable state, Zero owns rebuildable replicas, Redis carries ephemeral signals, S3 holds file bytes.
• Mutation boundary: trusted server code performs authoritative writes. Client-supplied context is never treated as authority.
• Release boundary: releases may change only the web and sync services, and routine releases leave the sync tier untouched.

Workspace identifiers participate in database relationships, authorization is enforced server-side, and PostgreSQL row-level security is verified against disposable databases in the test gate. Replication queries are constrained by tenant and permission boundaries, so the local-first layer cannot leak what the server would refuse.

Authentication cookies are host-only. Real-time credentials are tenant-scoped and short-lived. Authorization changes are tied to session and replication lifecycles, so a browser cannot quietly keep another user's authority after account switching, sign-out, or a membership change.

Telemetry is content-minimized by design. Request references, bounded route names, release ids, and status classes can be retained. Message content, concrete URLs, mutation inputs, credentials, and arbitrary exception text cannot.

• Bounded and validated mutation payloads
• Same-origin and CSRF protections, timing-safe comparisons
• Encrypted sensitive configuration, signed webhook verification, rate limiting
• Malware scanning with scan-gated file availability and short-lived download authorization
• Immutable dependency and runtime-image inputs

The clean-database gate currently holds 351 test files, 2,566 unit and integration tests, 40 deterministic demo and load tests, and 96 asserted row-level security policies. A 92-scenario Chromium suite exercises the production web image against a full PostgreSQL, Redis, and Zero stack rather than a mocked frontend.

Local CI parity is a deliberate cost decision. `pnpm ci:local` reproduces the repository-owned verification paths, so confidence does not depend on paying GitHub Actions for every run. Documentation-only changes skip runtime work; release candidates and high-risk changes still run the full production-image browser suite.

Infrastructure is code. Terraform modules manage AWS storage, AWS monitoring, Cloudflare, the state backend, and Zero backups. The web tier is two stateless Fly Machines replaced through a health-gated blue/green cutover; the sync tier is a single volume-backed service that routine releases do not touch, which keeps the blast radius of an ordinary web release small.

A production release has to clear every gate below before traffic moves. The prior image is retained as rollback evidence, and the latest release passed twelve direct post-deploy checks covering liveness, readiness, release identity, push delivery, sync keepalive, security headers, and the separation between the application and the public marketing surface.

• Clean, committed main in sync with origin
• Frozen dependency install, lint, and TypeScript validation
• Generated-schema and replication-artifact validation
• Public-proof validation
• Clean-database migration and the full test suite
• Database role and policy verification
• Production build, dependency audit, immutable container image
• Software bill of materials and vulnerability-policy evaluation
• Backward-compatible production migrations
• Blue/green deployment with health verification before promotion
• Release-identity verification and preserved rollback evidence
• Post-deployment production checks

Every durable architecture decision is recorded in an ADR: 157 so far. Each one answers why a boundary exists, how it is tested, what remains unproven, and whether it changes something Cinch may responsibly say in public.

That last question feeds a public-proof ledger. Each capability carries a maturity state (designed, implemented, validated, or exercised in production) and a separate public-approval flag. Approval and merchandising are different decisions, and a validator refuses any claim that names a credential, internal host, or private identifier. The result is a system that can describe itself honestly without a human remembering to be careful.

Cinch should be described as a serious, production-deployed, private-pilot platform with substantial enterprise foundations. It should not be described as enterprise-complete. Saying so plainly is part of the engineering story.

• No SOC 2 certification
• The sync tier is not yet highly available; a sync runtime change is still a maintenance event
• SSO and SCIM are implemented but not yet exercised with real identity providers
• No native mobile or desktop applications, no internationalization
• eDiscovery, DLP, and legal-hold workflows are incomplete
• Billing is a content-free shadow model with no charges or access consequences
• No broad app marketplace or arbitrary customer code execution