AI Chatbot Maker

Upload a folder of documents. Built a private AI assistant that answers from your own documents. Runs on your own server, no data leaves the building.

• 01User surface

  The whole experience the user sees

  This frame shows the live product: one-click saas to build a company's own ai chatbot · upload a folder, point at a site feed, everything stays on your server. Every component is ours · scope, design, code, deploy.

• 02Stack behind the screen

  What's powering it: Python, LangChain, PostgreSQL

  6 stack components run behind this frame · Python, LangChain, PostgreSQL drive the visible UI; the rest sit in the data layer. All studio-owned.

• 03What we shipped

  Knowledge sources: uploaded files, folders, website URLs · mix any

  Live chatbot in 5 minutes, answering only from your own data

• 04Status

  Private deploy · under NDA.

  Per the client's request the URL stays private · the build, architecture, and lessons can be shared in a scoping call.

• 01 · BRIEF

  Solve the GDPR + speed-to-live conflict.

  OpenAI integrations leak data; bespoke chatbot builds take 6 months. We scoped a SaaS that runs locally on the customer's server · GDPR-safe by default, one Docker image to deploy.

• 02 · ARCHITECTURE

  Stack decisions before any code.

  Decision doc captured the data flow, Python, LangChain, PostgreSQL, Docker role split, and the failure modes we'd handle in v1 vs defer. Cross-service boundaries (where AI ends and the web app begins) were drawn here so neither side leaked into the other later.

• 02 · BUILD

  FastAPI + Ollama + Postgres pgvector.

  FastAPI carries the multi-tenant API, Ollama runs the local LLM, Postgres + pgvector handles per-tenant retrieval with row-level security · LangChain glues the retrieval-augmented generation pipeline.

• 04 · POLISH

  Performance, accessibility, and observability.

  PSI / a11y / coverage budgets enforced as launch gates. Logging + metrics wired before cut-over · the team can answer 'is it working?' from a dashboard, not a Slack thread. Threat-model checklist signed off before traffic hits the box.

• 03 · SHIP

  One Docker image, embeddable snippet.

  Customer pulls a single image, runs one command, gets a dashboard. From there: upload data → click 'create chatbot' → paste the embed snippet on their site. 5 minutes end-to-end on a fresh box.

• 01Local LLM

  Ollama + Postgres pgvector on-prem

  Zero external API calls · the answer never leaves the customer's server. GDPR + audit-ready out of the box.

• 02Sources

  Files, folders, website URLs · mix any

  Knowledge base accepts uploaded docs and crawls a site feed in the same project · re-ingest is one click.

• 03Multi-tenant

  Per-tenant RLS isolation

  Postgres row-level security guarantees no tenant ever sees another's data · also enforced at the retrieval layer.

• 04Deploy

  One Docker image, one command

  Customer ops team handles it on their own infra · no AWS-account-share, no shared SaaS tenant.

• 
  01Frame

  Knowledge intake · URL + folder + AI hierarchy

  Left: 'Add from URL' (with same-origin crawl) and 'Add a folder' (recursive, .git skipped). Right: AI-organized topic hierarchy (Cafe Events, Menu, Company Info, Ordering, Policies, Products) auto-clusters the knowledge base.

• 
  02Frame

  Try-it tab · live conversation, no client setup

  Settings, Knowledge, Tools, Try it, Preview, Embed in one tab strip. Test the chatbot directly inside the admin · the conversation is logged for inspection, no separate staging environment.

• 
  03Frame

  Embed preview · widget on a mock customer site

  Right pane runs a sandboxed mock customer site with the chat bubble open · operator clicks the bubble and talks to the bot exactly as a website visitor would, before pasting the embed snippet.

• 
  04Frame

  RAG answer · with source citations

  The bot answers in Hungarian with the actual menu items, then lists the retrieval sources (products/subscriptions.md, cafe/menu.md, wholesale/onboarding.md) so the operator sees exactly which doc grounded the answer.