PHASOR · SOLO OPERATION
SHEET 03 · PART 02 DETAIL · PRODUCT STATUS: LIVE
PART 02 · OWN PRODUCT · LIVE 2026–

Doclinth

An AI-native PDF generation API — describe a document in plain English, POST JSON, get a pixel-perfect PDF back in ~2s.

LIVE · DOCLINTH.COM ↗

FUNCTION
Plain-English template → JSON → PDF
STATUS
Live · public API + SDKs
IN SERVICE
2026 – present
ROLE
Solo · design → support
Doclinth authoring a template from a plain-English description
FIG. 01 — PLAIN ENGLISH → TEMPLATE · AUTHORING
Doclinth visual template editor
FIG. 02 — VISUAL EDITOR · TWEAK LAYER

01The problem

Generating polished PDFs from code — invoices, receipts, statements, reports, contracts — is a chronically painful job.

Teams run and babysit a headless Chrome / Puppeteer fleet, wrestle low-level PDF libraries, or glue together brittle HTML-to-PDF pipelines. Doclinth removes all of it: you never touch a browser, a renderer, or layout math. You describe a template once, and from then on it's a single JSON API call.

02Approach

An AI authoring layer turns a plain-English description of an invoice, receipt, or report into the underlying HTML/CSS template and a matching JSON data schema. A visual editor sits on top as a tweak layer over that source — not a from-scratch canvas — so you adjust the rendered proof directly.

Rendering is deliberately boring and reliable. Handlebars compiles server-side — the browser CSP forbids eval and new Function — and a dedicated always-on service does the PDF work. No headless Chrome for the caller to run, no layout math, no renderer to operate.

03How it works

  1. Describe a template in plain English; an AI authoring layer generates the HTML/CSS template and a JSON data schema for it.
  2. Refine it visually — a tweak layer over the HTML source: drag, resize, recolor, and set typography on the rendered proof.
  3. At runtime, POST /v1/generate with a template ID and JSON data; a rendered PDF returns in roughly two seconds.
  4. Built for agents too: an MCP server, llms.txt, and an OpenAPI spec let AI tools author templates and generate PDFs directly.

04Capabilities

  • Public REST API — /v1/generate, /v1/templates, /v1/generations
  • API-key auth, idempotency, rate limiting
  • AI template authoring — Anthropic + Gemini via the AI SDK
  • Visual editor: drag / resize / recolor, snap guides, ⌘Z undo
  • PDF import — an existing PDF becomes a reusable template
  • MCP endpoint, llms.txt, OpenAPI spec, agent docs
  • 30 professionally-designed starter template packs
  • Published Python (PyPI) + JavaScript (npm) SDKs

05Stack

LANGUAGE
TypeScript
FRAMEWORK
Next.js 16 (App Router) · Vercel
AI
Vercel AI SDK v7 · @ai-sdk/anthropic + @ai-sdk/google · MCP (@modelcontextprotocol/sdk, mcp-handler)
PDF / RENDER
pdf-lib · pdfjs-dist · Handlebars · always-on render service on Fly.io
DATA / AUTH
Supabase (Postgres + RLS · Google OAuth)
INFRA
Upstash (QStash · Redis · rate-limit) · Dodo Payments billing
OBSERVABILITY
Sentry · PostHog · OpenTelemetry

06Engineering notes

  1. Server-side, CSP-safe compilation. The browser CSP forbids eval and new Function, so Handlebars compiles on the server. Template code never runs in the client, and the render path stays sealed off from the authoring UI.

  2. Quota reserved before the model call. AI template authoring reserves quota up front, so a slow or failed generation never silently drains a user's allowance — a consume-then-refund discipline around every model call.

  3. One always-on render path. A dedicated render service on Fly.io owns PDF generation, keeping the ~2s response off serverless cold starts and out of the Next.js request path — predictable latency instead of a per-call browser boot.

  4. Agents are first-class clients. The same generate and template capabilities ship as an MCP server plus llms.txt, llms-full.txt, and an OpenAPI spec, so an AI agent drives Doclinth through the same surface a developer does — not a bolted-on afterthought.

07In service

LIVE PRODUCT · DISTRIBUTION PHASE

Built: the public REST + MCP API, AI template authoring, the V3 visual editor, a full customer dashboard (API keys, usage logs, billing, ⌘K palette, and in-app support bridged to Telegram), PDF import, document stress-testing, 30 starter template packs, and docs-as-app with Python + JavaScript SDKs published to PyPI and npm.

Now: distribution. The engineering is largely built out; the active work is registry submissions, launch posts, and integration guides — getting it in front of developers.

08What's next

  1. Distribution: MCP + SDK registry submissions, launch posts, and integration guides — an n8n community node among them.
  2. Lean further into the "production-safe documents" north star — document tests and contracts so a PDF never silently breaks in production.