Meet TINO

TINO Is Not Office! Das passiert, wenn man Dokumente nicht mehr wie Dateien auf dem Desktop behandelt, sondern sie stattdessen als gemeinsamen, lebendigen Arbeitsbereich betrachtet.

Die Ausgangslage

Die meisten Geschäftsprozesse bei confirm IT sind vollständig automatisiert — Infrastructure as Code, CI/CD-Pipelines, reproduzierbare Deployments. Fast alles, was wir tun, wird wie Code behandelt: auditierbar, versioniert und automatisierbar. Die Dokumentenerstellung war die letzte Ausnahme. Eine Zeit lang nutzten wir Apple Pages — brauchbarer als O365, aber trotzdem unmöglich sinnvoll zu automatisieren.

Die Antwort war naheliegend: Dokumente genauso behandeln wie alles andere. In der Praxis hiess das:

• Webbasiert und selbst gehostet
• Versionskontrolliert mit vollständiger Historie
• Authentifizierung und Autorisierung via OpenID Connect
• API für Automatisierung und Integration
• Echtzeit-Zusammenarbeit
• Wiederverwendbare Templates und Corporate Design als Packages

Kein bestehendes Tool erfüllte alle Anforderungen. Die erste Frage war, auf welchem Dokumentenformat wir aufbauen. Markdown und reStructuredText fehlt die typografische Kontrolle, die für saubere Enddokumente nötig ist. LaTeX bietet diese Kontrolle, aber die Lernkurve macht es für nicht-technische Mitwirkende unpraktikabel.

Typst traf die richtige Balance: Ausdrucksstark genug für professionelle Ergebnisse, zugänglich genug fürs ganze Team. Typsts eigener Editor kommt einer Komplettlösung schon sehr nahe und bietet sogar eine selbst gehostete Variante — aber während der Compiler Open Source ist, ist der Web-Editor ein kommerzielles Closed-Source Produkt. Wir brauchten etwas, das wir vollständig kontrollieren können: Open Source, tief integriert mit unserem Identity Provider und unseren Git-Workflows, und erweiterbar auf unsere Anwendungsfälle.

Also haben wir TINO gebaut: eine kollaborative, selbst gehostete Editing-Plattform rund um Typst.

TINO entsteht

TINO begann als kleines internes Experiment. Ein paar von uns wollten herausfinden, ob wir unseren in die Jahre gekommenen Apple-Pages-Workflow durch etwas rund um Typst ersetzen könnten. Keine Roadmap, kein Budget, nur ein Wochenendprojekt und ein gemeinsamer Frust.

Es blieb nicht lange klein. Sobald Echtzeit-Zusammenarbeit und Git-basierte Versionierung tatsächlich funktionierten, begannen wir eigene Dokumente umzuziehen, ein Vertrag und ein Bericht nach dem anderen. Das Experiment wuchs schneller aus seinem «Nebenprojektstatus» heraus, als wir erwartet hatten.

Irgendwann stellten wir uns die naheliegende Frage: Warum behalten wir das für uns? TINO konkurrenziert nichts, was wir verkaufen; es löst ein Problem, das jedes Team wie unseres hat.

Also haben wir es aufgeräumt, richtige Dokumentation geschrieben und Open Source gemacht.

Doku, Doku, Doku

Ein internes Tool muss nur für die Leute Sinn ergeben, die es gebaut haben. Bei Open Source hat man diesen Luxus nicht. Bevor wir TINO der Welt vorstellen konnten, mussten wir alles aufschreiben, was wir bisher nur im Kopf hatten.

Daraus wurde eine richtige Dokumentationsseite zu Deployment und Konfiguration, zur täglichen Nutzung und zur Architektur dahinter. Das Schreiben zwang uns, ein paar Entscheidungen zu hinterfragen, welche wir zuvor nie wirklich hinterfragt hatten, was wiederum das Produkt weiter verbessert hat.

Alles davon findest du auf docs.tinotype.com.

TINO, Typst und Templates

Wir haben nicht nur Apple Pages ersetzt. Wir haben ein eigenes Typst-Package für unser Corporate Design gebaut, sodass jedes Dokument dasselbe Design hat, ohne dass jemand ein Stylesheet anfassen muss.

Zusätzlich haben wir Templates für die Dokumente gebaut, die wir am häufigsten erstellen: Verträge, Offerten, Briefe.

Dabei haben wir Kommentare ins Typst-Markup eingefügt; kurze Notizen, die erklären, was jedes Feld erwartet. Damit wird sichergestellt, dass alle im Team sowie spätere KI-Modelle ein Template ausfüllen können, ohne raten zu müssen. Das passt zu unserer Zen-Regel #4:

Clarify ambiguities to prevent assumptions.

Der KI ein MCP geben

Templates haben uns schon weit gebracht, aber eines von Hand auszufüllen ist immer noch ein biomechanischer Prozess. Also sind wir einen Schritt weitergegangen und haben einen MCP-Server für TINO gebaut, der Buckets, Files und den Editor selbst als KI-Tools bereitstellt.

Zuerst haben wir ein lokal gehostetes LLM verwendet. Teils aus Neugier, teils weil wir keine Kundendaten in die Nähe eines Drittanbieter-Modells lassen wollten, bevor wir dem Setup selbst vertraut haben.

Als das funktionierte, haben wir Calcimero, unseren Preisrechner, und unser ERP via MCP an dasselbe LLM angebunden.

Jetzt wird aus einer Offerte innert Minuten ein vollständiger Vertrag: Calcimero berechnet den Preis, das ERP verwaltet Abo und Rechnung, während das Modell das Dokument entwirft, ausfüllt und direkt in TINO committet.

Fazit

Dokumente waren lange ein unstrukturierter Teil unseres Workflows. Jetzt ist der Prozess standardisiert und das Ergebnis überzeugt: schneller, konsistenter, nachvollziehbar.

TINO ist Open Source und immer noch ein junges Projekt. Wenn dir all dies bekannt vorkommt, kontaktiere uns oder beteilige dich am Projekt.