FounderOS-DEMO: a seeded Next.js command center for a one-person company

What a solo operator gets that a task app does not

The problem Founder OS addresses is fragmentation rather than missing features. A one-person company already has an inbox, a Slack workspace, a client pipeline, a social calendar, a spreadsheet of expenses, and a pile of notes. Each of those lives in a separate tool with its own login and its own idea of what a client is. The README describes the goal as turning "the tabs, tools, and mental overhead of running a solo business into one screen," and the route table backs that up: /comms merges email, Slack, WhatsApp and dictation into one feed, /funnel renders the client journey as both a left-to-right flow and a radial acquisition wheel, /finances charts income and expenses by category, and /brain exposes a knowledge graph. The intended user is a single operator, not a team. The /org route models a hierarchy of operator, conductor, pillars and workers, which is a way of drawing one person's work as if it had departments. Anyone running a company with an actual reporting structure will find that model awkward.

The repository layer is the load-bearing decision

The README calls the architecture "larp-first, real-ready" and states the rule plainly: every page and API route reads through a repository layer, never a raw query. In practice that means lib/data.ts exposes a getDb() singleton that seeds the SQLite database on first touch, and lib/db.ts provides openDb() plus typed repositories for agents, departments, social, funnel and finances. All demo content sits in lib/seed.ts. The part worth copying is lib/schemas.ts: Zod schemas validate every row on the way out of the database, so malformed data fails loudly instead of rendering as an empty chart. That is a deliberate cost. Every new data type needs a repository method, a schema, a seed entry and a test, and the README says so directly. The payoff is that replacing seeded tables with live sources is a change inside the repository layer rather than a rewrite of the views.

Connector status is a three-state enum, not a green light

There are more than 20 connector groups in lib/connectors, covering email over IMAP, Slack, Stripe, Notion, calendar, CRM and social sources. Each one returns a typed ConnectorStatus of connected, not_configured or error. The README is emphatic that this is never a fake green light, and /integrations is the page that renders the honest state. This is a small design choice with a large consequence: an unwired connector is visibly unwired, so a demo that looks busy cannot be mistaken for a system that is actually talking to Stripe. It also means the failure mode of a half-configured deployment is a page full of not_configured badges rather than silent empty charts. If you fork this for your own stack, the enum is the piece to keep. The connector code itself is only as useful as the credentials you supply, and none are supplied here.

Running the demo: four commands and a port

The README requires Node 18 or later. The quick start is npm install, then optionally cp .env.example .env.local, then npm run dev, which serves on http://localhost:4100. The environment file is only needed to wire live integrations. A local SQLite database is seeded with demo data on first run, so no credentials are required to browse. Navigation is through the sidebar or a Command Palette bound to Cmd or Ctrl plus K. Five themes ship, and the README singles out Monolith as the default: white on black, with color reserved for status. For a production build the README gives npm run build followed by npm start. The verification commands are npm test for the vitest suite, npm run typecheck for tsc --noEmit, and npm run seed to re-seed the demo database, which the README describes as idempotent. That last claim is the one to check yourself, since it is a property of lib/seed.ts rather than something the command enforces.

The knowledge layer is documented, not shipped

The /brain graph is the visible surface of two systems the README describes as powering the production build. G-Brain stores plain Markdown files as the source of truth, chunks and embeds them into a vector store, and answers both keyword and semantic queries using hybrid retrieval with reciprocal-rank fusion. If the vector backend is unreachable, retrieval falls back to a local grep over the markdown, which trades accuracy for zero downtime. Optimal Engine governs memory instead of documents, organized as a Tenant, Organization, Workspace, Node topology with a lifecycle of Source, Signal, Claim, Fact, Memory. Agents may write sources, signals and pending claims, but facts are promotion-gated: nothing becomes known without passing review. The README's own summary is that G-Brain is the library and Optimal Engine is the librarian. Here is the constraint: the demo ships a stub provider for G-Brain, and Optimal Engine is described as part of the production build. Neither is something you can run from this repository today.

What the demo does not contain, and what to use instead

The README's production plan names Railway as the hosting target, with the Next.js app as a service, the seeded SQLite store replaced by a managed database, and the knowledge services running as companion services. Agents would run their run() against live connectors and the knowledge layer on a schedule, with runs persisted. None of that is in the demo. If your actual need is a personal dashboard rather than a business operating system, Grafana against a Prometheus or SQLite datasource gives you charts and alerting without an agent roster or a knowledge graph, and it will not ask you to model an org hierarchy. If your need is a knowledge base with governed memory, a plain Markdown repository plus a static site generator covers the storage half of G-Brain and skips the retrieval machinery entirely. Founder OS sits between those two: more opinionated than a dashboard, less complete than a knowledge platform, and honest about which half you are getting.

Licence, maintenance and the cost of keeping the contract

The repository is MIT licensed, which permits commercial use and modification provided the copyright notice and permission notice are retained. That is the extent of what can be said here; questions about your own distribution or derivative work belong with a lawyer. On maintenance, the README states the rule that governs every future contribution: new data means a new repository method, a Zod schema, a seed entry and a test. That rule is what keeps the demo honest, and it is also the upgrade cost. Adding one connector or one table touches four files, and skipping the schema step breaks the guarantee that bad data fails loudly. There are no retrieved releases for this repository, so versioning and upgrade cadence cannot be assessed from the material. The last push date is recent, which tells you the repository is active but nothing about how breaking changes would be communicated.

Editorial conclusion

Adopt it if you want a working Next.js and SQLite shell for a solo-business dashboard, or if you are evaluating the Founder OS cohort and want to see the interface before paying. Do not adopt it expecting a runnable business OS: the knowledge layer ships as a stub provider, the connectors are unwired, and the production backends are described in the README rather than included. Before you commit, run npm run seed twice to confirm the idempotency claim, open /integrations to see how not_configured is rendered, and read lib/schemas.ts to check whether Zod validation on rows leaving the database matches the shape of your own data.

Official sources

1. Bennettxai/FounderOS-DEMO on GitHub
2. Issues
3. License: MIT
4. Project website
5. README