SENN Dev Stories

The story of SENN, and its latest version (beta)

SENN started as a QA tool, and we added what our team needed for its work, one thing at a time.
The latest version (beta) is built on all of that. But this is not the end.

The latest version is now available as a beta. We use it every day ourselves.

  1. Cover. The story of SENN, and its latest version (beta). We added what we needed. Seven months from a QA tool, built up one “we need this” at a time. The latest version is now available as a beta, and we use it every day ourselves.
  2. Each feature solved a real problem. In March, we wanted to run quality checks, so we added QA records. From April, we couldn't tell who was doing what, so we added tickets; we couldn't see when work would finish, so a Gantt chart; procedures and decisions were scattered, so a Wiki. From late June, dev work is hard to cut by deadlines, so points and cycles; we didn't know where to start, so dependencies. In September, we missed other people's updates, so real-time updates; every action meant waiting, so IndexedDB (local-first). Each addition revealed the next problem.
  3. We rebuilt the foundations each time, with AI. QA Tool (Django), WIP (Django and more features), SENN (Rust and React), local-first (IndexedDB and WebSocket), and the latest version (beta, visibility rules). From the very first QA tool in March, we have built it all together with AI.
  4. Latest version: open unless kept private. A team's tickets used to be visible only to its members; in the beta, anyone in your organization can see a public team's tickets. A team that needs privacy can be made private, and non-members can't even see that it exists. Tickets can be created as team tickets without a project. External people see only what they're invited to, and AI acts with the same access as the key owner. Who can see what is decided by one thing: public or private.
  5. Latest version: the rules live in one place. The UI, sync to IndexedDB, real-time updates, and AI and external access all reach the data through one set of visibility rules. We switch over with a trial run first: old and new rules run side by side, and we move step by step after checking the differences.
  6. But this is not the end. Features in development (planned for the next version): reports (see progress and workload without digging for it), document integration (move between external documents and tickets or the Wiki), meeting notes integration (turn meeting decisions directly into tickets and Wiki pages), incident automation (when an incident is found, pull past records with an LLM and RAG, and automate logging, investigation, and fixes), and a knowledge gateway (store and retrieve experts' knowledge and know-how with an LLM and RAG; SENN becomes the gateway). Each one came from a moment of “we need this” while working as a team.
  7. Architecture of the latest version (beta). In the browser (React SPA), the React and TanStack Query UI uses IndexedDB (Dexie), holding only scoped data through a sync engine and outbox. AI agents (Claude Code, Cursor, Antigravity) work through MCP with the same permissions as the API key's issuer (MCP is in the internal edition only). The REST API (axum), the Sync API (delta pull / push), WebSocket push, and MCP / API all reach PostgreSQL (sqlx, LISTEN / NOTIFY) through a single access policy (can() and scope_sql in domain::access, decided by Public / Private and by member, admin, guest, or AI). Features in development, such as reports, meeting notes, document integration, incident automation, and an LLM and RAG gateway, will go through the same policy. Everything we've built so far. But this is not the end. We will keep adding what we need, one thing at a time.