Roadmap

What runs where, and why

• Protect / Remove password — real PDF encryption needs a real crypto implementation, so this calls a server API backed by qpdf.
• Word/Docs → PDF — the one conversion direction headless LibreOffice handles reliably (its PDF import is image-only, which is why the reverse direction below is handled differently).
• PDF → Word / PowerPoint / Markdown — text is extracted client-side and rebuilt as an editable file, with headings inferred from font size. This preserves content and rough structure, not the original visual layout (columns, exact fonts, images).
• PDF → Excel, Bank Statement / Trade Confirmations → CSV — one shared table-extraction engine that clusters text by position into rows/columns. Works well on clearly aligned tables; irregular layouts may need manual cleanup.
• Redact PDF / Redact account numbers — genuine redaction: pages are rendered to flattened images with the matched text's pixels destroyed, then rebuilt into a PDF. The original text is gone, not just covered.
• Developer API — API-key-authenticated REST endpoints wrapping the same engine as the website, gated to Pro/Lifetime. Key management lives at /tools/api-access.

Explicitly not done yet

These need something only the project owner can provide, not more code: real Stripe verification against a live account, real Google OAuth credentials, and a chosen production deployment target (which itself needs Postgres, qpdf and LibreOffice installed on the host).

Also on the list

• Queue-based processing for the LibreOffice-backed conversion, so it scales past low-volume synchronous use
• Webhooks for the Developer API, once it grows longer-running jobs
• OCR for scanned PDFs, so text-based tools work on image-only documents
• Team/workspace accounts with shared billing
• Usage dashboard surfacing the existing usage-log data

Have a request? Every suggestion helps prioritize what ships next.