Most companies make a proposal in one tool, a poster in another, a video in a third, and a customer-facing page in a fourth. Four tools, four sets of brand assets, four opportunities for the logo to be slightly the wrong blue.
We went looking through four months of our own output and found we had stopped doing that without ever deciding to.
The shape
Everything begins as text — Markdown or HTML — with the brand as a stylesheet rather than a template. That single source then leaves through one of four exits.
- To PDF, for the proposal or deck that gets attached to an email
- To PNG, at four canvas sizes at once — print, square, story, link preview — from the same file
- To video, by rendering each scene to a frame and stitching them with motion and crossfades
- As HTML itself, sent as a link, where the thing stays interactive
The renderer in the middle is a browser. That is the whole trick, and it is not a clever one. A browser already knows how to lay out a page, hyphenate a paragraph, embed a font and draw a chart. Every format above is that same layout, captured differently.
We did not build a design tool. We built four ways of taking a photograph of a web page.
What it means in practice
A launch poster exists once. Rendering it gives an A4 for printing, a square for Instagram, a vertical for stories and a wide card for when the link is pasted into a chat. Change the headline in one place and all four are correct.
Our event decks are a small factory: give it an event name and a date, and it generates the QR code, stamps every placeholder, refuses to build if any placeholder is still unfilled, and outputs both the PDF and every slide as an image for social. Five events have gone through it.
One explainer video was built the same way — seven HTML scenes, each screenshotted, then given slow zooms and crossfades. It is silent on purpose, because chat apps autoplay muted and text on screen survives that.
The honest part: what did not survive
The audit was less flattering about our ambitions than our habits.
Every tool still in daily use is a short script — under a hundred and fifty lines — that checks its dependencies are installed and writes a date-stamped file. Every tool we designed as a multi-stage pipeline with configuration profiles, scoring rubrics and a manifest format was never built. In one case we found ten pipelines documented as active with not a single configuration file behind them.
The sharpest finding was about a good tool nobody used. We built a genuinely better PDF renderer, ran it twice, and then — when another project needed the same capability — somebody copied the file into a different folder and hardcoded it rather than calling it. That is not a discipline failure. It means the tool was easier to copy than to reuse, and that is a design fault in the tool.
Why this is a client-facing point and not an internal one
Because it is the same argument as the rest of our work, applied to documents. Keep one source of truth. Make the output a build step. Let the format be a decision you make late, and change your mind about, without redoing the content.
And because it is a fair test to put to anyone who wants to sell you a system. Ask them what happens when the headline changes. If the answer involves opening four files, you are buying four things that will drift apart.
This piece exists because we ran that audit on ourselves and published the result, including the abandoned renderer and the ten pipelines that were never real. We would rather be the company that checks.