ProBot

Recruiters skim resumes. A static PDF cannot answer "has she used Kubernetes in production" or "is he open to relocating", and the candidate cannot sit online all day waiting for that chat either. The interesting part of a career story usually only shows up in conversation. It rarely makes it to the top of the funnel.

ProBot is a personal AI representative grounded only in the owner's own career data. Paste a resume, pick a model, bring your own API key, and you get a public chat URL plus a one-line embeddable widget. The bot answers from your material, captures recruiter leads, and shows who asked what.

Don't just send a resume. Send a representative.

I did not pick one deployment model and defend it. I shipped three and let the user choose. Read top to bottom: each one asks less of me.

One codebase, three deployment models, two published npm packages.

One Next.js 14.2 App Router application. Frontend pages and /api/* routes are co-deployed. No microservice split. For a solo project on a free tier that is the right call: one deploy, one log stream, one place to look when something breaks.

• Next.js
• TypeScript
• PostgreSQL
• RAG
• MCP

This is the part of the project I care about most. There are two storage modes.

Browser-held

The key sits in IndexedDB encrypted under a non-extractable Web Crypto AES-256-GCM master key. Because the master key is created with extractable: false, the browser itself refuses crypto.subtle.exportKey. The key travels to the server in an x-llm-api-key header.

Managed: envelope encryption

1. 1

   Generate a per-bot DEK

   A fresh random 32-byte data-encryption key, one per bot.

2. 2

   Encrypt the LLM key with the DEK

   AES-256-GCM, producing {ciphertext, iv, authTag}.

3. 3

   Wrap the DEK with the KEK

   The key-encryption key is one 32-byte AES key held only in an environment variable. Never in the database, never in git, never in a backup.

4. 4

   Zero the bare DEK

   dek.fill(0) inside a finally block. Node strings are garbage-collected and cannot be reliably wiped, so the code decrypts into Buffers and only materialises a string at the last moment the SDK requires one.

Rotation re-wraps DEKs rather than re-encrypting data, so it's one UPDATE per row and the {ciphertext, iv, authTag} columns stay byte-identical. Encrypting each key directly under a single server key would have meant decrypting and re-encrypting every secret. Slower, and a much larger window where plaintext exists.

Thirteen steps, each a composable function returning a discriminated union. The orchestrator reads as a flat sequence of early returns with no nested try/catch. Prompt construction order is deliberate: identity, immutable rules, tone, the owner's custom instructions, response style, what to do when the answer isn't in context, then the retrieved context itself. Response style comes after custom instructions on purpose, so a malformed custom block cannot override the structural rules.

Retrieval chunks at 750 tokens with 100 tokens of overlap using cl100k_base, embeds in batches of 96, and pulls the top 5 by cosine similarity. If anything in the embedding path breaks, it falls back silently to the bot's full assembled context. A degraded answer beats an error.

• The API key is not a column on users. That absence is the single most important line in the schema.
• leads.conversationId is ON DELETE SET NULL, not cascade. A captured recruiter email stays valuable to the owner after the transcript is purged for GDPR reasons. Cascade would have destroyed the lead with the log.
• conversations is unique on (botId, sessionId), so concurrent tabs coalesce into one conversation instead of fragmenting the transcript.
• A partial index on read_at IS NULL keeps the unread-notification count O(unread) rather than O(total) on every dashboard load.
• A CHECK constraint locks messages.role to four values, so a future typo cannot quietly corrupt analytics.

A per-provider circuit breaker opens after 5 failures, cools down for 30 seconds, then allows one half-open probe. A two-tier sliding-window rate limiter defaults to 10 requests per minute and 50 per day, overridable per bot. Both run in-process by default and switch to Upstash Redis when it's configured. The call sites don't change either way.

Why bring-your-own-key rather than billing users?

The zero-cost policy is a hard constraint, not an aspiration. BYO-key means the user pays their own inference bill, which removes both my cost exposure and the need to become a payments company. It also forces the interesting security work that makes the project worth talking about.

Why three deployment models instead of one good one?

Because key custody is a matter of taste, not correctness. Some users are happy with encrypted server-side storage. Others will not accept any server-side custody at all. Shipping the gradient means I never have to argue someone out of their threat model.

Why one Next.js app rather than a service split?

Team of one, free tier. A split would buy independent scaling I don't need and cost me a second deploy target, a second log stream, and cross-service tracing.

Why deterministic lead summaries instead of an LLM call?

Summarising the first few recruiter messages by truncation is free and predictable. An LLM call there would spend the owner's tokens on something they didn't ask for.