Building kb.miin.ai

White Paper: A Personal Knowledge Base Build

Summary

I built kb.miin.ai as a searchable, web-based knowledge base that turns a Google Workspace folder into a private retrieval system with semantic search, source references, OCR, spreadsheet parsing, and a clean public-facing interface. The project started as a local prototype, moved through a Vercel and Supabase production version, and now uses Firebase as the Google-native home for hosting, backend functions, document data, vector retrieval, and deployment operations. Gemini 2.5 Flash generates answers from retrieved excerpts. The big lesson: modern AI infrastructure is accessible if you break the build into small, testable pieces, and when in doubt, ask your favorite coding agent!

Tech Stack

The current system combines a static personal website, a Firebase-backed knowledge-base app, Google Drive ingestion, Gemini models, and Firestore retrieval. Codex automated much of the implementation work: scaffolding the Next.js app, writing the Google Drive sync pipeline, switching from local Ollama to Gemini, migrating the data layer from Supabase to Firebase, updating the UI, pushing code to GitHub, and helping debug deployment and authentication issues along the way.

Source
Google Workspace Knowledge Base folder with PDFs, Docs, Sheets, images, and Excel files.
Ingest
Local Sync Script Parses files, extracts text, OCRs images, and chunks documents.
Embed
Gemini Embeddings Creates 768-dimension vectors for semantic matching.
Retrieve
Firebase Firestore Stores chunks, metadata, embeddings, and vector-search results.
Answer
Firebase + Gemini Firebase serves the app and Gemini 2.5 Flash answers with references.

Application

Next.js App Router, TypeScript, custom CSS, GitHub, and Firebase Hosting or App Hosting.

Models

Gemini 2.5 Flash for answers and Gemini Embedding for retrieval vectors.

Data Layer

Firebase Firestore document collections for sources, chunks, metadata, embeddings, and vector indexes.

Automation

Codex for code generation, refactors, Git operations, local testing, and deployment support.

What I Built

1. A Google-style search surface

The front end began as a minimal Google-like search page, then evolved into a branded containerized page that matches the visual language of miin.ai: dark mode, pill buttons, block-M logos, and a clean search field.

2. A retrieval-augmented answer flow

User questions are embedded, matched against stored document chunks in Firebase, and then passed to Gemini 2.5 Flash with only the retrieved excerpts. The response includes concise source references without exposing direct file links.

3. A local sync pipeline

The ingestion process runs locally against the Google Drive Knowledge Base folder. It reads Google Docs, PDFs, Word documents, Sheets, Excel files, plain text, and images. Image OCR and Excel parsing were added after the initial version so the index could cover more real workspace content.

4. A production deployment

The personal profile remains on GitHub Pages, while the knowledge base runs as a dynamic Firebase-backed app at kb.miin.ai. GoDaddy DNS maps the subdomain to Firebase, and the runtime reads Firebase and Gemini configuration without exposing secrets in the repository.

Tradeoffs

The first design considered Ollama with a local Gemma model. That was attractive because it kept inference local and avoided hosted model costs, but it created production complexity: a public site would need a persistent machine capable of running the model. Moving to Gemini 2.5 Flash reduced hosting burden and made the system easier to operate.

The first hosted version used Vercel for the dynamic Next.js runtime and Supabase for Postgres plus pgvector. That was a strong developer stack, but it split the system across multiple vendors. The Firebase migration trades some SQL flexibility for simpler operations, closer alignment with Google Workspace and Gemini, and a clearer path to private access controls.

For Google auth, we avoided long-lived service-account JSON keys and used Application Default Credentials for local sync, which is safer but occasionally requires re-authentication.

Current Firebase Architecture

After the Vercel and Supabase version was working, the architecture moved into Firebase. The current direction keeps the knowledge base close to Google Workspace and Gemini while letting Firebase own hosting, server code, document storage, vector retrieval, secrets, previews, monitoring, and billing under the same Google project.

What Vercel + Supabase did well

Vercel made the Next.js deployment path fast, and Supabase gave the app Postgres, pgvector, SQL inspection, and RPC search in a very direct package. That stack is flexible and familiar for relational data.

What pushed the move

The split stack required more vendor boundaries, environment variables, service-role handling, logs, dashboards, and deployment surfaces. Firebase reduces that operational spread for a small, personal knowledge product.

What Firebase improves

Firebase keeps the app close to Google auth patterns, Cloud Functions or App Hosting, Firestore document data, vector indexes, and the existing Gemini workflow. It also creates a cleaner path for future private access and user-aware permissions.

What Firebase costs

The migration trades away plain Postgres ergonomics and requires reshaping chunk metadata into Firestore documents, rebuilding vector indexes, and watching read and function costs. It also deepens commitment to the Google ecosystem.

Final call

Firebase won because this knowledge base values low-ops maintenance, Google-native integration, and a coherent deployment story more than the extra SQL flexibility Supabase provides. For this use case, simpler ownership beat a more modular architecture.

Implementation Notes

These are the key command groups and setup steps behind the project. The exact values for secrets stay in local or hosted environment variables, not in the repository.

Local app setup
cd "/path/to/your/knowledge-base-app"
npm install
cp .env.example .env.local
Google Drive authentication for local sync
gcloud auth application-default revoke
gcloud auth application-default login \
  --client-id-file="$HOME/Downloads/knowledge-site-oauth-client.json" \
  --scopes=https://www.googleapis.com/auth/drive.readonly,https://www.googleapis.com/auth/cloud-platform
Firebase content sync
# Configure the Firebase project, Firestore collections, and vector indexes first.

npm run sync:drive
SYNC_ONLY_MISSING=1 npm run sync:drive
SYNC_ONLY_MISSING=1 SYNC_MAX_FILES=2 npm run sync:drive
Local testing
npm run lint
npm run typecheck
npm run build
npm run dev
Deploy and link the sites
git add .
git commit -m "Build your-domain knowledge base app"
git push origin main

# Firebase App Hosting can roll out from the connected GitHub repo.
# For CLI-managed Hosting or Functions deployments:
firebase deploy --only hosting,functions

# Firebase production config:
# GEMINI_API_KEY
# FIREBASE_PROJECT_ID
# GOOGLE_APPLICATION_CREDENTIALS for local sync only, if needed
# GEMINI_CHAT_MODEL=gemini-2.5-flash
# GEMINI_EMBED_MODEL=gemini-embedding-001
# GEMINI_EMBED_DIMENSIONS=768

Content updates do not require a redeploy. Once the app is live, syncing new files locally updates Firebase, and the production app reads the latest indexed content at query time.