Brainforge Knowledge

research-memo

7 min read

Research Memo: Marketing Asset Document Pipeline Evaluation

Date: 2026-04-16
Status: Draft research memo
Scope: One-pagers, two-pagers, and other multi-page branded PDF leave-behinds

Question

How should Brainforge streamline development of marketing one-pagers and multi-page PDFs while staying close to the way the repo already stores sales content and the way the Platform already distributes asset files?

Brainforge Current State

0. Final visual layouts currently live in Figma

The current one-pagers and multi-page leave-behinds were originally designed in Figma and exported from there. The relevant design file is:

  • Sales Assets - https://www.figma.com/design/mKTpR46wYleYtLKF0qciSc/Sales-Assets

Initial inspection of the file confirms Brainforge is using fixed-composition, print-oriented frames rather than purely fluid web layouts. The file includes multi-page asset structures such as:

  • Event Data Modeling
  • Event Data Modeling - Page 1
  • Event Data Modeling - Page 2

These frames are laid out as explicit print pages, which means the evaluation should optimize for faithful print composition, not just responsive web rendering.

Follow-up inspection shows the file is organized into actual asset families and reusable print components rather than standalone exports. Important signals:

  • 1-Pagers V1 is organized by status columns such as Archived, WIP, Needs Review, and Final.
  • Asset families include General Services, Service Offerings, Deep Dive on Data Services, Deep Dive on AI & Automation, Pricing Page, and FAQs.
  • The file includes a dedicated 1-Pager V1 Components section with reusable 1-Pager Heading, Successes, and Footer components.

The layout system is also highly regular:

  • dominant page size is 2550 x 3300
  • common content region is x=100, width=2350
  • the shared heading block is 2550 x 991
  • footer treatments are reused near the bottom of the page with a separate brand strip and, for multi-page assets, page numbers

Implication: Brainforge should evaluate a componentized print-layout system, not just generic HTML rendering quality.

1. Source material already exists in markdown

Brainforge already stores reusable GTM copy in markdown under knowledge/sales/marketing-assets/.

Relevant patterns:

  • knowledge/sales/marketing-assets/design-ready-copy/README.md defines these files as copy-only inputs for one-pagers and two-pagers.
  • knowledge/sales/marketing-assets/design-ready-copy/insurance-broker-lead-intake-2pager.md shows the current structure Brainforge wants from source documents: sectioned copy, KPI callouts, process steps, CTA, and optional wording variations.
  • knowledge/sales/agents/prompts/service-asset-prompts/one-pager-prompt.md already encodes a repeatable content structure for one-pagers.

Implication: Brainforge does not have an authoring problem first. It already has a source-content system.

Implication from Figma: Brainforge also does not have a visual-direction problem first. It already has a design source of truth. The gap is the translation layer between source copy, branded layout, and exported files.

2. The Platform already has a distribution layer

apps/platform/src/app/(main)/marketing-assets/page.tsx is a cataloging and browsing surface for marketing assets. It reads files plus metadata and supports filtering, editing metadata, and asset discovery.

Implication: the Platform already knows how to surface finished assets. The main missing layer is generation and publish automation.

3. The current GitHub integration is repo-wide, not PDF-specific

apps/platform/src/lib/githubApi.ts uses fetchPDFFiles, but the current implementation recursively collects lowercase files across the target GitHub repo rather than enforcing a strict .pdf filter.

Implication:

  • Brainforge’s asset distribution flow is broader than PDFs alone.
  • A future pipeline can publish HTML, markdown, or metadata sidecars alongside PDFs if useful.
  • The eventual generation system should fit the existing GitHub-backed asset model instead of bypassing it.

Existing Brainforge Workflow Shape

Today, the workflow looks roughly like this:

  1. GTM or Sales Engineering creates source copy in markdown.
  2. Design-ready copy is prepared for one-pagers and two-pagers.
  3. Finished assets are stored in brainforge-files and surfaced by the Platform marketing asset browser.

The gap is between steps 2 and 3:

  • there is no standardized renderer
  • there is no documented HTML/PDF export path
  • there is no clear recommendation for branded multi-page pagination

External Research Signal

Last-30-days research was most useful when narrowed to template-driven document generation rather than generic business phrasing.

The strongest recurring signal was:

  • teams solving this problem now typically use HTML/CSS templates plus server-side PDF rendering
  • the winning pattern is usually source content → reusable template → export pipeline
  • page-aware CSS and print tooling become important only when multi-page formatting quality matters

Implication: Brainforge should evaluate modern HTML-first rendering before introducing a separate document-authoring language.

OSS Landscape

Strong-fit candidates

1. Puppeteer

Repo: https://github.com/puppeteer/puppeteer

Why it fits:

  • renders branded HTML/CSS with high fidelity
  • easy match for a Platform-adjacent Node stack
  • flexible for one-pagers and multi-page PDFs
  • good baseline even if Brainforge later adds richer print tooling

Main tradeoff:

  • Brainforge would own rendering conventions and print CSS discipline

2. Gotenberg

Repo: https://github.com/gotenberg/gotenberg

Why it fits:

  • clean backend service for HTML-to-PDF conversion
  • good option if Brainforge wants document rendering as infrastructure instead of app code
  • can centralize conversion concerns

Main tradeoff:

  • adds another service to operate
  • still depends on Brainforge owning the HTML/template layer

3. Paged.js

Repo: https://github.com/pagedjs/pagedjs

Why it fits:

  • improves pagination and print-specific layout behavior
  • useful when one-pagers expand into polished multi-page leave-behinds
  • can sit on top of an HTML-first pipeline instead of replacing it

Main tradeoff:

  • more complexity than Brainforge likely needs for a first pass

4. Vivliostyle

Repo: https://github.com/vivliostyle/vivliostyle.js

Why it fits:

  • stronger typesetting and paged-media capabilities for editorial-quality documents
  • attractive if Brainforge wants more formal multi-page publishing quality

Main tradeoff:

  • likely heavier than needed for the first evaluation cycle

Contrast options worth understanding, but not leading with

5. React PDF

Repo: https://github.com/diegomura/react-pdf

Pros:

  • React-native authoring model
  • attractive if the team wants every document as a React component

Cons:

  • weaker fit for HTML/CSS reuse
  • pushes Brainforge toward component-authored documents instead of source-first template rendering

6. pdfme

Repo: https://github.com/pdfme/pdfme

Pros:

  • helpful for form-like or structured templates
  • strong designer/template tooling in some workflows

Cons:

  • less obvious fit for polished marketing one-pagers and narrative multi-page leave-behinds

7. Typst

Repo: https://github.com/typst/typst

Pros:

  • strong typesetting model
  • attractive for teams willing to adopt a document language

Cons:

  • introduces a new authoring surface and workflow
  • does not align as naturally with existing markdown-first GTM assets

Recommendation

Best-fit baseline

Brainforge should start with:

markdown or structured copy -> branded HTML template -> server-side PDF render -> publish to existing asset flow

Why this is the best starting point:

  • matches current markdown-heavy GTM workflow
  • fits the Platform and Node ecosystem
  • keeps authoring simple for GTM and Sales Engineering
  • leaves room to add stronger print-layout tooling later
  • does not require a new document language up front
  • can be tuned to approximate current Figma exports closely enough for branded leave-behinds if the template layer respects the fixed page geometry and reusable section system already present in Figma

Important caveat after Figma review

Because the existing assets were composed in Figma as print-first layouts, Brainforge should not assume that a generic markdown-to-PDF pipeline will be sufficient. The first architecture spike should be judged against real Figma compositions for:

  • spacing rhythm
  • typography scale
  • section density
  • page break behavior
  • placement of proof blocks, KPI bands, and roadmap sections

It should also explicitly test whether the renderer can support the recurring Figma component families without manual post-layout work:

  • shared hero/header variants
  • bottom CTA/footer variants
  • success metrics blocks
  • service card rows
  • pricing / comparison matrices
  • FAQ question-answer stacks
  • roadmap step modules

Preferred order of evaluation

  1. HTML templates + Puppeteer
  2. HTML templates + Gotenberg
  3. HTML templates + Paged.js or Vivliostyle for advanced pagination
  4. React PDF only as a contrast path
  5. Typst only if Brainforge decides it wants a separate publishing language

Brainforge-Specific Architectural Direction

The likely target system is:

  1. Source files live in knowledge/sales/marketing-assets/ and related GTM docs.
  2. A renderer normalizes those sources into a structured document model.
  3. Branded templates render HTML for archetypes like one-pager, service two-pager, case study, and leave-behind, with asset-family-specific layout components.
  4. A server-side export step generates PDF.
  5. Outputs publish into the existing GitHub-backed asset library used by the Platform.

This keeps Brainforge’s content layer, rendering layer, and distribution layer cleanly separated.

Open Questions

  • Should rendering live inside apps/platform, in a small adjacent service, or as a background job?
  • Should Brainforge publish only final PDFs, or also intermediate HTML for review/debugging?
  • How much print-specific layout sophistication is actually needed for the first archetypes?
  • Should the pipeline start with markdown parsing only, or define a stricter structured schema for document sections?

Bottom Line

Brainforge already has the source assets and the distribution layer. The highest-leverage missing capability is a reusable HTML-first rendering pipeline with server-side PDF generation. The first tests should focus on that architecture before considering separate document languages or designer-heavy template systems.

The new constraint is that the generated output should be evaluated against the existing Figma compositions, because those are the current visual benchmark for what Brainforge considers a finished asset.

Last updated: 2026-04-16

Graph View

Backlinks