If you're shipping AI features in production, you have a problem you probably haven't named yet. Your prompts are everywhere — hardcoded in source files, pasted into Notion pages, buried in Slack threads from six months ago. When something breaks, you have no idea what changed. When someone "improves" the system prompt on a Friday afternoon, you find out on Monday morning via a support spike. We've solved this problem in software engineering. It's called version control. We just haven't applied it to prompts yet. Here's how most teams manage prompts today: Method The Real Problem Hardcoded in source code Every prompt change requires a full redeploy Copy-pasted in Notion No diff, no history, no way to know what changed Shared via Slack No single source of truth — teams work on contradictory versions Ad-hoc spreadsheets No execution, no testing — purely manual The non-deterministic nature of LLMs makes this especially dangerous. A minor, well-intentioned edit to a system prompt can degrade output quality across thousands of requests before anyone notices. And when you do notice, you can't answer the basic question: what exactly changed? Research on AI pilot programmes attributes prompt management chaos as one of the primary reasons 95% of AI projects fail to deliver measurable business impact. That number should terrify every team shipping AI today. Imagine treating every prompt change the way you treat a code change: # Before: hardcoded, untracked, unversioned system_prompt = "You are a helpful customer support agent. Always be polite." # After: fetched from your prompt registry at runtime from pvct import PromptClient client = PromptClient(api_key="...") prompt = client.get("support-bot") # Always loads the current production version Now every change to support-bot is: Committed with an author, timestamp, and message explaining why it changed Diffed at word level against any previous version Tested in staging before it touches production Rolled back instantly if something goes wrong No redeploy. No archaeology through Slack history. No guesswork. Every prompt edit creates a new version row in the database. The previous version is never modified — only superseded. You can compare any two versions side-by-side, with word-level highlighting of what changed. This alone solves the "what broke on Friday" problem. Prompts flow through dev → staging → production. Promoting to production requires an explicit action, and can be gated behind an approval workflow. The audit trail shows who promoted what, when, and why. Deploy two prompt versions simultaneously, split real traffic between them — e.g., 80% v1 / 20% v2 — and measure the impact with real metrics, not vibes. The routing is deterministic and stateless. The same user always sees the same variant within a test window, with zero latency overhead. Every prompt version accumulates: Cost per call — token usage priced per provider Latency (p50 / p95 / p99) — response time distribution Quality score — via LLM-as-judge, regex, or semantic similarity User feedback rate — thumbs up/down collected from end users Error rate — failed completions, timeouts, safety refusals When you're comparing two versions, you're comparing data — not opinions. Layer Choice Why Frontend Next.js 15 + React 19 Server components, fast initial load Prompt Editor Monaco Editor VS Code's engine — diff view built-in Backend API Node.js + Fastify Low latency, schema-based validation Database PostgreSQL 16 JSONB for prompt metadata, immutable versioning A/B Routing Redis 7 Sub-millisecond routing decisions Background Jobs BullMQ Eval jobs, metric aggregation Auth Clerk RBAC + SSO without rebuilding from scratch The data model is intentionally simple. prompt_versions is an append-only table — you never update a row, only insert new ones. deployments tracks which version is active in which environment. executions is date-partitioned telemetry, one row per API call. -- The 'repository' — one row per named prompt CREATE TABLE prompts ( id UUID PRIMARY KEY, workspace_id UUID NOT NULL, name TEXT NOT NULL, slug TEXT NOT NULL, created_at TIMESTAMPTZ DEFAULT NOW(), UNIQUE(workspace_id, slug) ); -- Immutable version history — INSERT only, never UPDATE CREATE TABLE prompt_versions ( id UUID PRIMARY KEY, prompt_id UUID REFERENCES prompts(id), content JSONB NOT NULL, -- {system, user, assistant templates} model_params JSONB, -- {model, temperature, top_p, max_tokens} parent_id UUID REFERENCES prompt_versions(id), author_id UUID NOT NULL, commit_msg TEXT, created_at TIMESTAMPTZ DEFAULT NOW() ); -- Which version is active in which environment CREATE TABLE deployments ( id UUID PRIMARY KEY, prompt_version_id UUID REFERENCES prompt_versions(id), environment_id UUID REFERENCES environments(id), deployed_at TIMESTAMPTZ DEFAULT NOW(), deployed_by UUID NOT NULL ); -- Per-call telemetry — append only, partitioned by date CREATE TABLE executions ( id UUID PRIMARY KEY, prompt_version_id UUID REFERENCES prompt_versions(id), latency_ms INTEGER, tokens_in INTEGER, tokens_out INTEGER, cost_usd NUMERIC(10,6), score NUMERIC(3,2), created_at TIMESTAMPTZ DEFAULT NOW() ) PARTITION BY RANGE (created_at); The SDK is intentionally minimal. You fetch by name, you get content: # Python from pvct import PromptClient client = PromptClient(api_key="pvct_...") prompt = client.get("support-bot") # prompt.system → string # prompt.user_template → string with {variable} placeholders # prompt.model_params → {model, temperature, max_tokens} // TypeScript import { PromptClient } from 'pvct' const client = new PromptClient({ apiKey: 'pvct_...' }) const prompt = await client.get('support-bot') The SDK handles fetching the current active version, A/B test routing, local caching with configurable TTL, and async execution logging. It does not make the LLM API call — that stays in your application code. It's a thin fetch + cache + logging layer, not a full LLM client. Component Decision Reason Prompt editor UI Build (Monaco) Free, VS Code quality, diff view included Auth & RBAC Buy (Clerk) Saves weeks; enterprise SSO included A/B routing engine Build Core IP — must own this logic LLM-as-judge evaluator Build Just an API call + storage Email / notifications Buy (Resend) Commodity — not a differentiator Billing Buy (Stripe) Never build payment infrastructure Before: An engineer modifies the system prompt directly in code on a Tuesday. It ships in the next deploy on Wednesday. Friday afternoon, the support team notices response quality has dropped. Two hours of debugging later, the team finds the change. A fix ships Monday. After: The engineer creates a new prompt version with a commit message: "Tightened tone guidance — previous version was too verbose in edge cases." It goes to staging. QA runs their test suite against it. A tech lead approves the promotion. It goes to production at 10% traffic first. Metrics look good. Full rollout. The whole process is auditable and reversible at every step. The LLMOps space is maturing fast, but there's a clear gap. Existing tools fall into two buckets: Full platforms (Langfuse, LangSmith, Maxim AI) — powerful, but heavyweight, expensive, and require significant setup. Built for teams that need full observability across a complex AI pipeline, not teams that primarily need prompt management. Basic loggers (PromptLayer, Helicone) — great at capturing history, but light on evaluation, A/B testing, and deployment workflows. The gap is a focused, developer-friendly tool that does exactly what Git does for code — but for prompts. Lightweight enough to adopt in a day, powerful enough to run in production. If you build something like this, keep your success metric simple: Number of prompt versions successfully promoted to production per week. This captures everything: prompts being actively managed, teams collaborating, and the platform actually working end-to-end. If that number grows week over week, you're solving a real problem. These are not solved problems in the current tooling ecosystem: How do you handle prompt templates with variables? ({{variable}} vs {variable} vs a custom DSL) How do you version multi-turn conversation templates — system + user turn + expected assistant shape? How do you handle prompt composition — shared snippets that appear in multiple prompts? How do you enforce evaluation before production promotion — gate the API behind a minimum sample size and score threshold? The tooling is early. The problem is real. The timing is right. 🔗 Follow the build: promptvault Have you solved prompt management at your company? What worked, what didn't? Drop a comment below — especially curious how teams are handling multi-turn prompt versioning in production.