Good question!
I tried to explain it in the rationale, but I can try to explain it here more detailed:
Most of our processes are automated – deployments, documentation, and even CI/CD (corporate identity & design, not the pipeline thingy). We generate all the required colour asset fully automatically, and reference / distribute them where required. Basically 99% is treated as code – which makes things awesome, reproducible, transparent, and mostly maintainable. Even accounting is automated to 98-99%.
However, one last thing wasn’t: The whole document generation & authoring stuff. We’re a “mac company”, and thus we used Apple Pages – which I think is more usable than the crap O365. However, it’s still not very good to automate.
So we started researching different solutions and we came across Typst. We immediately loved it (as probably most users). The compiler is amazing, the web editor just works, and the community provides an extraordinary value. Thus we’ve decided we want to use Typst.
However, the official web editor didn’t meet our requirements in a few points:
- We were looking for a full open-source solution.
- We love to understand what’s going on behind the scenes.
- Most of our services authenticate against an SSO via OIDC (Keycloak). Typst supports LDAP – which is amazing – but this is not what we were looking for.
- Most of our services are protected by mTLS and we didn’t knew if we can use it for Typst.
Because we’re going to integrate Typst into our workflows and automation processes, these requirements become crucial:
- We’re going to automate letters, contracts, quotes, and much more.
- We need a clean API to automate these processes.
- We also need a proper history & audit trail to see «who» did «what» & «when».
Now in our product & services web app, I can select the services I want for a customer, and it automatically generates a template contract for me.
Apart from that, we also have a vision where users can interact with different systems via AI. We already have a working prototype, but basically I want to be able to say:
Hey, create a new maintenance contract for customer X and product Y, starting at 01.06.2026. Use the customers standard discount.
Because we’ve connected the ERP and our billable services / products (different system, also handled as code) in a PoC, the AI is already capable of getting the required information. However, the missing part was the generation of the document itself. Product metadata, sales orders are fine, but the shiny document was missing. I got a generic Markdown, txt or a f* Word file.
This is where Typst comes into play. Since I’ve all the metadata, and thanks to Typst genius encapsulation model of packages (split the layout from the content), we can easily create new documents, with full CI/CD conformity.
Designing this «layer on top of Typst» cleverly means that Typst just becomes another «AI tool» (tool like an AI-specific tool like in an MCP or similar). Users can now add many other tools (web crawlers, ERPs, product databases, monitoring systems) and can suddenly create these amazing documents and reports. For example:
- A customer asks for an uptime report, and the AI has already access to the metrics? Easy, just fetch the metrics, then create a new shiny report with Typst.
- A customer asks for a change in a contract? Just tell the AI what to change, and it will do it, and commit it as a new version – diff included.
- A customer of a lawyer asks for a prenup? No problem, just fetch all the customer data from the systems, add the missing parts (e.g. assets), and create the template.
Typst was really the missing piece in all of that, because Pages or O365 were not made for automation (crap proprietary format), Markdown & ReST don’t support layouting, and the learning curve of LaTeX is quite high ;)
These are some reasons why we chose Typst, and why we were looking for that «layer on top», which we can use for further automation.
.