config/projects/business/memory/decisions.md

Decisions Log

2026-02-14 — Product: PDF API (approved by user)

Chose HTML/Markdown to PDF API over webhook relay and JSON schema validation. Fastest to ship, proven demand, clear monetization.

2026-02-14 — Name: DocFast

Product name "DocFast" — short, memorable, describes value prop (fast document generation). Domain TBD.

2026-02-14 — Tech Stack: TypeScript + Express + Puppeteer

• TypeScript for type safety and fast iteration
• Express for simplicity (no framework overhead)
• Puppeteer for high-fidelity PDF rendering (Chrome-based = pixel-perfect)
• Marked for markdown parsing
• Chose Puppeteer over wkhtmltopdf/pdfkit for better CSS support and template rendering quality

2026-02-14 — Templates: Invoice + Receipt first

Built-in invoice and receipt templates as differentiator. Most PDF API competitors are raw converters — templates add immediate value for common use cases.

2026-02-14 — Pricing model (planned)

• Free tier: 100 PDFs/month
• Pro: $9/mo for 5,000 PDFs
• Business: $29/mo for 25,000 PDFs
• Enterprise: custom Not yet implemented — need Stripe integration.

2026-02-14 — Phase 2: Go to market

QA Session 14 verified all 3 investor-reported bugs are fixed. 3 minor edge cases (BUG-004/005/006) logged but not blocking launch. Product is shippable — moving to marketing and customer acquisition.

2026-02-14 — Phase 2 confirmed after full Playwright QA

BUG-004 (CSP inline scripts) and BUG-005 (CSP inline onclick) both fixed and verified. Zero console errors, full signup+checkout+API flow works in real browser. Only BUG-006 (cosmetic copy feedback) remains — not blocking launch.

2026-02-14 — Free tier limit: 50 PDFs/month (in-memory tracking)

Reduced from 100 to 50 for free tier enforcement. In-memory tracking for MVP (resets on restart). Will need Redis or SQLite for production persistence. Pro keys bypass limits via PRO_KEYS env var.

2026-02-14 — URL→PDF endpoint added

High-demand feature that differentiates from simpler HTML-only converters. Validates URLs (http/https only), 30s timeout, configurable wait strategy. Security note: may need SSRF protection before production (block private IPs).

2026-02-14 — Phase 2: All bugs resolved, QA passed

After 4 QA rounds and multiple fix cycles, all 11 test cases pass. BUG-006 required CEO intervention — clipboard API fails silently in headless browsers, needed fallback with execCommand. Moving to security audit before marketing.

2026-02-14 17:21 UTC — Product decisions on BUG-012/013/014

BUG-012: Remove email requirement for free tier

Rationale: Collecting unverified emails adds friction with zero value. Fastest path to API key = more signups. Can add optional email later for recovery/marketing. Decision: instant key generation, no email needed.

BUG-013: Pro key delivery — success page display

The Stripe success redirect already shows a key. Verify this works end-to-end. For now, success page + copy button is sufficient. Email delivery deferred (no email infra).

BUG-014: Key recovery — deferred

Without email verification, secure recovery is impossible. Ship with a clear warning: "Save your API key — we can't recover it." Revisit after launch when we have email infra.

429 form handling

Frontend must show a user-friendly message when rate limited instead of hanging.

2026-02-14 17:37 UTC — Reversing BUG-012 decision: Email required again (BUG-020)

Session 19 removed email to reduce friction. But the investor correctly identified (BUG-020) that no-email = zero accountability. Anyone can generate unlimited keys from different IPs. Re-adding email requirement: email in → key out instantly (no verification yet), but one key per email. This gives us: accountability, a contact list for marketing/upsell, and abuse mitigation. Friction is minimal (one field).

2026-02-14 17:37 UTC — BUG-019: Remove "Custom templates" from Pro plan

We don't have custom templates. Listing them is false advertising. Removed from landing page. Can build the feature later and re-add when it actually works.

2026-02-14 17:37 UTC — BUG-015: Migrate to SQLite

File-based JSON won't survive concurrent requests. SQLite is the right choice for our scale (single server, <1000 users). No need for PostgreSQL yet. DB file on Docker volume for persistence.

2026-02-16 — Email Infrastructure: Scaling Strategy

Context: Currently running Postfix on the single app server (docfast-1). Investor asked how this scales behind a load balancer.

Options evaluated:

• A) Dedicated mail server — Separate VM running Postfix/Exim. Centralizes DKIM/SPF/PTR config, app servers relay through it. Moderate cost (~€4/mo for CX22), full control.
• B) External email service (Postmark, SES, SendGrid) — Best deliverability, no infra to manage, built-in analytics/bounce handling. ~$15-25/mo at our scale. Postmark recommended (focused on transactional email, excellent deliverability).
• C) Keep Postfix on app server with relay — Each app server relays through a central SMTP. Quick to set up but still managing Postfix everywhere.

Recommendation: Option B (External service — Postmark)

Reasons:

1. Deliverability — Services like Postmark have pre-warmed IPs with established reputation. We're fighting spam scores on a fresh Hetzner IP.
2. Scaling — Zero config when adding app servers. Just use the API/SMTP credentials.
3. Operational cost — No PTR/DKIM/SPF debugging. No Postfix maintenance. Engineer time > €15/mo.
4. Analytics — Bounce rates, open tracking, delivery confirmation built-in.
5. When to implement — After launch validation. Current Postfix setup is fine for MVP with the deliverability fixes applied today.

Migration path: Keep Postfix for now (with today's SPF/DMARC/PTR fixes). Switch to Postmark when we hit paid customers or add a second server, whichever comes first.

⚠️ SUPERSEDED (2026-02-20): All Postfix infrastructure was removed. SMTP is now managed by Cloonar via mail.cloonar.com:587 with authenticated relay. No mail infrastructure runs on K3s.

2026-02-16 — Email Deliverability Fixes (PTR, SPF, DMARC)

Problem: Emails scoring 10.90 spam score. Three issues identified:

1. PTR record showing generic Hetzner hostname → changed to mail.docfast.dev
2. SPF using ~all (softfail) → changing to -all (hardfail)
3. DMARC using p=none → changing to p=quarantine

Status: PTR fixed via Hetzner Cloud API. SPF and DMARC require Hetzner DNS API token (not currently in credentials). A record for mail.docfast.dev also needed.

2026-02-14 17:37 UTC — Deferred items (with reasoning)

• BUG-016 (backups): Deferred to next session. Need to research Hetzner object storage or simple cron+scp backup.
• BUG-017 (benchmarking): Deferred. Need load testing tools, will do before scaling marketing.
• BUG-018 (rate limits): Depends on BUG-017. Can't set data-backed limits without benchmarks.