The decision frame
SaaS teams usually compare four paths when they need PDFs: self-host a browser renderer such as Playwright or Puppeteer, license a specialist print engine, use a generic HTML-to-PDF API, or build a structured document service. Teleza is deliberately in the last category.
| Path | Good fit | Operational burden | Teleza position |
|---|---|---|---|
| Playwright or Puppeteer | HTML-first output, browser-exact rendering, CSS-heavy layouts. | Browser dependencies, process pools, memory spikes, font/runtime drift. | Teleza avoids a Chromium browser pool for core operational documents. |
| PrinceXML or similar print engines | High-quality paged CSS where licensing and print-CSS expertise are acceptable. | Commercial licensing, CSS print complexity, separate automation model. | Teleza favors template schema, field mapping, and API-first SaaS handoff. |
| WeasyPrint and lighter renderers | Document-style HTML where full browser compatibility is not required. | CSS support boundaries and layout edge cases still sit with the integrator. | Teleza keeps report structure, totals, grouping, and schema discovery in the product contract. |
| Generic HTML-to-PDF APIs | Fast convenience for low-volume pages, marketing documents, or simple receipts. | External service dependency, duplicated templates, unsafe styling pressure, less domain context. | Teleza is narrower: operational records, vertical starter packs, private-cloud deployment, and evidence. |
The browser-pool problem
Self-hosted browser rendering sounds attractive because the browser is familiar. At scale, the hidden work is not the first PDF; it is maintaining browser binaries, sandbox permissions, fonts, process pools, memory ceilings, retries, and crash recovery while customer requests are arriving.
Teleza's core path treats the document as structured data instead: rows enter through a scoped API key, fields are normalized against a template schema, optional mappings translate source-system names, and the render pipeline returns the document bytes. Where render isolation matters, Teleza also has a separate render-worker container path so report compilation can be kept outside the main API routing process.
Structured-document infrastructure
Teleza is built for records that need to be repeated, audited, and explained: invoices, statements, packing slips, shipping labels, quotations, claims packets, inspection reports, compliance notices, field-service packets, and customer-ready spreadsheets.
Schema before render
Template schema endpoints expose canonical fields, accepted aliases, formatting hints, grouping hints, and examples before a developer sends production data.
Mappings once
Source names from ERP, CRM, WMS, claims, or field systems can be mapped to Teleza fields so teams do not reshape every payload by hand.
Evidence after render
Lineage fields such as lineage.contractHash and lineageContractHash help support teams identify the exact template, mapping, and option contract used.
Blueprints and safe design themes
Arbitrary marketplace layouts often depend on floating text boxes, static copy, and decorative assets that break when real customer data wraps. Teleza uses a safer multiplier: functional document blueprints plus allowlisted design themes.
typecentric-minimalistfor whitespace-heavy operational documents.corporate-high-contrastfor dense B2B packets with shaded metadata blocks.bold-geometricfor stronger visual accents without arbitrary CSS injection.- Branding options such as company name, logo text, colors, header details, footer notes, currency, decimals, grouping, totals, and page size remain validated input, not raw styling code.
This gives design variety without making every customer's report a one-off HTML/CSS maintenance problem.
Private cloud and data sovereignty
For regulated or risk-sensitive buyers, document generation often sits close to customer data. Teleza supports a hosted beta path for fast evaluation and a Docker/VPS/private-cloud path when the buyer needs data, credentials, logs, and generated documents to remain inside their own environment.
That is the practical difference from many generic API services: Teleza can be evaluated as a hosted API, then deployed nearer to the customer's database and network boundary when sovereignty or latency requires it.
Evidence-backed claims only
Teleza should not publish synthetic concurrency numbers or broad enterprise claims before the evidence exists. Current docs separate local resource manifests from hosted/VPS render-load evidence, and the resource profile explains which results are measured locally and which require target load runs.
The claim discipline is simple: publish what a working route, rendered sample, verification evidence file, or design-partner pilot artifact proves. Everything else stays as a roadmap item.