Sinapt: Two Products, Not One

A product idea benefits from a second architectural pass: separate the problems, dependencies and audiences before committing to a build.

I published the first Sinapt piece yesterday — the consolidation of a year of AI-native practice plus the brainstorm of a single application that would close the loop. A closer architectural review reveals a distinction the first article almost surfaced but did not name.

Sinapt is not one product. It's two.

This piece is the architectural correction.

Two products, not one

Re-read yesterday's piece through the lens of which problem does each part solve, and the seam between two products becomes obvious in retrospect:

• Problem 1: This proposed local cockpit does not yet provide shared or remote knowledge-base access. Separate storage can still be shared through a repository, synchronized storage, mounted data or an authenticated retrieval service; each choice needs its own access model.
• Problem 2: Cognitive load from too many cockpits. The operator now juggles four-plus apps and is the integration layer.

Yesterday's article proposed a single product — Sinapt — that solved both. A closer review gives a different reading: these are two problems with different shapes, different audiences, different timelines, and very different complexity profiles. They should be two products. And one of them should come first. Decisively first.

Product 1 — Sinapt (the knowledge base)

Cloud-native knowledge-base infrastructure for AI-native engineering. Markdown files, hybrid lexical + vector search via QMD, team scoping, integrations, web app for manual curation, full API + MCP surface, CLI for terminal-native workflows. Universally useful — your existing local cockpit pattern keeps working, just with the KB layer moved to the cloud and shareable. Not opinionated about which agents you use. Not opinionated about which editor you use. Not opinionated about your workflow.

This becomes the core. Build this first.

Product 2 — Sinapt Cockpit (the future opinionated layer)

The desktop + mobile application that integrates Claude Code CLI, Codex CLI, the editor, the scratch buffer, and your project view in one window. The collapse-the-complexity move from yesterday's piece — operator burden of pre-AI, same power as today.

Three things make this the second product, not the first:

• It depends on Product 1. The cockpit's value comes from being one window over the cloud KB + integrations + team scoping. Without the KB layer in the cloud, the cockpit is just another desktop app over local files — no improvement on what already exists.
• It's deeply opinionated. People have their own editors, their own terminal preferences, their own agent setups, their own muscle memory. Asking them to switch a workflow they've spent a year tuning is a much harder sale than asking them to add a cloud KB their existing workflow can talk to.
• The cockpit adds a separate integration problem: native desktop/mobile surfaces, agent processes and editor workflows. Start with a bounded knowledge-base proof of concept, then estimate the next stage using what it demonstrates. No delivery duration is established here.

Build the cockpit later, as a layered product on top of the KB. Build the KB now.

Sinapt — the knowledge base, deeper

Here's the architectural shape. Sinapt-the-product is a hub with a knowledge-base core surrounded by the layers that make it useful to a team or a company.

Walking the spokes:

Markdown files — the substrate

Same shape as the cockpit pattern from The Knowledge Base That Builds Itself: short overview.md entry points + deeper documents linked from there. Cloud-stored (S3 or equivalent), versioned, agent-curated. Files stay text — no opaque vector-store-only formats. Your KB is still readable and grep-able even if Sinapt disappears tomorrow.

QMD engine — the search layer

The proposed search layer would serve ranked results from the Markdown corpus through a managed interface. A compatible query shape could reduce migration work, but prompts, skills, permissions and maintenance hooks still require configuration changes and testing.

Auth + Permissions + Teams + Sharing

The layer that makes a knowledge base usable by more than one person. Per-collection visibility (private to me / shared with a team / public to the org / mixable). Per-collection permissions (read / write / curate). Team invitations, role assignments, audit log. The thing that's missing entirely from the local cockpit pattern.

Integrations — the ingestion side

Slack threads, Confluence pages, Linear tickets, Jira issues, GitHub PRs/discussions, Notion docs, Google Docs — pull them into the KB on a schedule or on demand. Each integration emits markdown into the right collection with the right metadata. The KB becomes the canonical place where the team's distributed context converges.

Web application — the curation surface

A clean web UI for the operator who isn't currently in their terminal. Browse collections, search, view a document, edit a document, share a document, add a teammate, configure permissions, set up integrations. Not the primary interface for daily use — that stays in the terminal — but the right surface for setup, occasional review, and collaborative editing.

API + MCP — the programmatic surface

REST API for everything. MCP (Model Context Protocol) servers for native AI-agent consumption — Claude Code, Codex, future agents all see Sinapt as a standard MCP-attached knowledge source. The same backend powers the web app, the CLI, third-party integrations, and your own custom tools.

CLI tool — the workflow-preserving surface

The proposed sinapt CLI aims to preserve a familiar query workflow while accessing a shared service. Migration would require configuration changes, authentication, permission checks and tests of the supported commands. The command names here are design sketches, not a claim that a released CLI already implements them.

Configuration — the cross-machine substrate

Account, credentials, integration tokens, default collections, search preferences — all stored in the cloud, follow the operator across machines. Switch laptops, log in, everything is there. Onboard a teammate, they get the team's shared KB instantly.

Proof of Concept first, MVP second

The temptation with a clear product vision is to jump to MVP. Don't. There's a meaningful step before that.

Proof of Concept answers: can this even work? Build the absolute minimum infrastructure that proves the core architecture is feasible. Markdown files in cloud storage, QMD running as a managed service, a thin API in front of both, a CLI client that talks to the API, and exactly enough auth to sign in. No integrations. No web app. No teams. No sharing. No billing. Just: can a single user point their existing CLAUDE.md at a cloud-resident KB and have the same workflow keep working transparently?

The proof of concept should establish feasibility for its tested workload, including latency, cost and failure behavior. It will not by itself validate production scale, the complete permission model or every planned integration.

MVP is the next phase: take the validated PoC and build it into a real product. Web app for setup and curation. Team support. Multiple integrations. Per-collection permissions. Billing. Onboarding flow. Documentation. Support. The thing a real team can adopt and pay for.

Test the smallest useful slice before expanding the product. Early experiments can expose architectural assumptions at a smaller scope; the cost of later correction depends on the implementation and cannot be summarized by an unsupported fixed multiplier.

sinapt.ai — AI tools for developers, engineers, and teams

sinapt.ai becomes the home for the company, not just the product. Positioning: AI-native infrastructure for engineering teams. Sinapt the knowledge base is the first product, and the first thing the site sells. The cockpit is the second product on the roadmap. Future tools and services in the same orbit (eval infrastructure, agent observability, team workflow analytics) live under the same brand and brand promise.

This framing matters because it's the difference between "a knowledge-base tool" and "the company that builds the infrastructure layer for AI-native engineering teams." The first is a feature comparison. The second is a category. Categories command attention and pricing power that features cannot.

It also gives the cockpit (Product 2) a natural home when its time comes — same brand, same audience, same positioning, just a different surface of the same underlying infrastructure.

Where this lands

Yesterday's piece introduced an idea. This piece refines it. The next one — when there's something to show — will be the proof-of-concept demo and the lessons from actually building it.

If you want to follow how an idea evolves from words to code in real time, this is the cleanest place to watch it happen. Subscribe.