About FounderFly
This document explains the full FounderFly system: how workspaces are created, how structured memory is stored, how HydraDB retrieval works, how OpenAI produces briefs and answers, and how the application is isolated by organization in production.
Overview
FounderFly is not a single generic chatbot attached to company data. It is a workspace-native system that treats each strategic thread as its own operating surface. Investor prep, customer renewals, board planning, and hiring loops all live in separate workspaces so the application can preserve context without mixing distinct jobs together.
At runtime, FounderFly combines four kinds of state: product state in Postgres, retrieval memory in HydraDB, identity and organization ownership in Clerk, and final synthesis through OpenAI. That separation is deliberate. It keeps the product reliable, explainable, and multi-tenant.
Architecture
The founder or teammate works inside a single workspace. Every investor process, customer renewal, board prep cycle, and hiring loop is intentionally isolated so context does not bleed across threads.
Next.js App Router handles both the interface and the server-side orchestration. Route handlers enforce organization context, persist product state, retrieve memory evidence, and coordinate final response generation.
Neon Postgres is the source of truth for product state. This includes workspaces, memories, archived workspaces, conversations, and messages. Prisma defines and accesses that relational model.
HydraDB acts as the recall engine. FounderFly syncs structured workspace memory into HydraDB and retrieves relevant evidence for the active workspace when preparing a brief or answering a question.
OpenAI synthesizes the retrieved context into the final founder-facing brief and answer. The prompts are tuned to summarize, prioritize, and coach rather than merely restating raw notes.
Workspace lifecycle
An admin creates a workspace with a name, type, focus, and suggested opening question. This creates the operating container that future memories and questions belong to.
Team members add investor objections, customer insights, internal decisions, and roadmap updates. FounderFly stores them as structured memory, not just loose text blobs.
Every question asked inside the workspace is added to a persistent conversation thread. That means the next brief can take recent Q&A context into account.
When the founder clicks Generate brief, FounderFly loads saved context, retrieves external evidence, and prepares a concise workspace-specific briefing surface.
When the founder asks a hard question, FounderFly answers from the active workspace context instead of from generic global memory.
Ingestion pipeline
FounderFly’s ingestion path is intentionally layered. It never depends on HydraDB alone. The application first persists the memory as durable product state, then attempts to sync it into the retrieval layer so future briefs and answers can show evidence cards.
The ingestion form is structured by memory type so investor pushback, customer feedback, internal decisions, and roadmap changes can be captured with clearer prompts.
The application writes the memory to the workspace in Postgres first so the product state remains durable even if HydraDB is temporarily unavailable.
FounderFly attempts to create or verify the organization tenant in HydraDB, uploads the memory, and stores the returned Hydra source id back into Postgres when available.
After ingest, the UI updates memory history immediately and tries to refresh source evidence so the user can see what the system just absorbed.
Brief generation
The brief path is not a static template. FounderFly combines stored workspace memory, recent conversation turns, and HydraDB evidence, then asks OpenAI to synthesize a short document shaped around three jobs: what matters now, what to be ready for, and what to do next.
Answer generation
Answer generation follows a similar path to brief generation, but it is optimized for a narrower task: take one strategic question, retrieve the best relevant evidence, answer concisely, and suggest the next best action.
API routes
Data model
The top-level operating container. A workspace is a single strategic thread such as a fundraise, renewal, board cycle, or hiring loop.
A structured workspace memory entry. It stores what happened, why it matters, and optionally which Hydra source id corresponds to the synced retrieval memory.
A persistent thread attached to one workspace. This is how FounderFly remembers what has already been asked and answered in that operating context.
An individual user or agent turn. Messages are ordered by creation time and surfaced in the conversation memory panel.
Multi-tenancy
Clerk identifies the signed-in user and active organization. Without an active organization, FounderFly does not allow workspace access.
Every workspace, memory, and conversation query is scoped by organization id so one company never reads another company’s product state.
Hydra tenant ids are derived from Clerk organization ids. That keeps retrieval memory separated by company as well as by workspace.
Workspace selection, memory history, conversation thread, and source evidence are all rendered from the currently active workspace only.
Deployment
FounderFly runs as a full-stack Next.js application on Vercel. The UI and backend routes deploy together, while Neon stores the application database, Clerk owns identity and organizations, HydraDB powers memory retrieval, and OpenAI powers the final synthesis layer.