QuestPDF im Mittelstand: Die Bibliothek ist gut — aber wer pflegt sie morgen?

Nick Chapsas zeigt, wie elegant PDF-Erzeugung in .NET sein kann. Ich zeige, was das für ein KMU mit 30 bis 300 Mitarbeitenden wirklich bedeutet — und warum die Frage oft nicht 'Welche Bibliothek?' lautet, sondern 'Wer schreibt das in drei Jahren noch?'

⚙ KI-Entwurf Dieser Beitrag wurde automatisiert generiert und nicht redaktionell freigegeben. Behandelt ihn entsprechend.

Letztes Jahr, Frühsommer. Maschinenbauer, 80 Mitarbeitende, Nordbayern. Die kaufmännische Leiterin ruft mich an, weil die Lieferscheine seit dem ERP-Wechsel „irgendwie schief aussehen". Ich schaue rein: Der Vorläufer-Entwickler hatte damals Crystal Reports genommen, die Vorlagen wanderten durch drei Systemwechsel, keiner weiß mehr, warum ein bestimmtes Feld manchmal oben rechts auftaucht und manchmal nicht. Der Entwickler selbst ist seit zwei Jahren weg. Das Projekt, das „mal eben" die PDFs reparieren sollte, kostet am Ende 14.000 Euro — nicht weil Crystal Reports schlecht ist, sondern weil niemand mehr die Verantwortung dafür übernommen hatte.

Genau diese Geschichte habe ich im Kopf, wenn ich Artikel über PDF-Bibliotheken lese.


Nick Chapsas hat auf seinem Blog einen sauberen, praxisnahen Artikel über QuestPDF veröffentlicht. Er zeigt, wie man mit einer fluenten API in wenigen Zeilen C# professionelle PDF-Dokumente baut — von „Hello, World!" in Rot bis zu mehrseitigen Layouts mit Header, Footer, Bildern und dynamischen Inhalten. QuestPDF ist Open Source, MIT-lizenziert, auf Performance ausgelegt, und kommt mit einem integrierten Previewer-Tool, das schnelle Iteration erlaubt. Für Unternehmen unter einer Million US-Dollar Jahresumsatz ist die Community-Lizenz kostenlos. Darüber gibt es Professional- und Enterprise-Stufen. Der Artikel erklärt den Einstieg klar, die Code-Beispiele sind direkt kopierbar, und Nick trifft damit ein echtes Problem: PDF-Erzeugung in .NET war jahrelang unnötig kompliziert.

Ich stimme ihm zu. QuestPDF ist technisch sehr überzeugend.


Und trotzdem ist „einfach QuestPDF nutzen" für viele KMUs nicht die richtige Antwort — oder zumindest nicht die vollständige.

Fangen wir mit der Lizenz an, weil das oft übersehen wird: Die Community-Lizenz gilt für Unternehmen mit weniger als einer Million US-Dollar Jahresumsatz. Das klingt nach viel, ist aber eine Schwelle, die viele meiner Mandanten — Handelsunternehmen, Zulieferer, Dienstleister mit 30 bis 300 Leuten — locker überschreiten. Bei einem Betrieb mit 15 Millionen Euro Jahresumsatz greift die Professional-Lizenz. Die kostet zum Zeitpunkt dieses Artikels einige Hundert Dollar pro Jahr, was ich für fair halte. Aber ich erlebe regelmäßig, dass Entwickler oder IT-Verantwortliche die Community-Lizenz installieren, weil die Einschränkung im Onboarding-Stress nicht auffällt — und sechs Monate später sitzt die Geschäftsführung mit einem Compliance-Problem. Also: Lizenz lesen, bevor der erste dotnet add package läuft.

Zweiter Punkt: Code-First bedeutet Developer-First. QuestPDF ist eine Programmierbibliothek, kein Tool für Sachbearbeiter. Das Rechnungslayout, das die Buchhaltung nächste Woche anpassen möchte — weil das Logo drei Millimeter nach links soll und die Kontonummer in 9 Punkt statt 10 Punkt — das ist ein Entwickler-Ticket. Bei einem Unternehmen mit festem .NET-Entwickler-Team ist das kein Problem. Bei einem KMU, das externe Entwickler auf Stundenbasis beschäftigt, kostet jede Layout-Änderung eine Stunde Kommunikation plus eine Stunde Arbeit plus eine Woche Wartezeit. Drei solche Anpassungen pro Quartal, das ist schnell ein paar Tausend Euro im Jahr — für Arbeit, die vorher die kaufmännische Assistentin in Word in zwanzig Minuten erledigt hat.

Das ist kein Vorwurf an QuestPDF. Es ist eine Architekturentscheidung, die man bewusst treffen muss.


Wann lohnt sich QuestPDF im Mittelstand dann wirklich?

Wenn Du intern .NET-Kapazität hast und häufig gleichartige Dokumente in größeren Stückzahlen produzierst. Klassischer Fall: Ein Online-Shop mit eigener Fulfillment-Infrastruktur, der täglich hunderte Lieferscheine generiert. Oder ein SaaS-Anbieter, der mandantenfähige Auswertungen als PDF exportiert. Oder ein Unternehmen mit Individualentwicklung, das sowieso schon eine .NET-Backend-Basis betreibt und PDF-Export als Feature nachzieht. In diesen Szenarien ist QuestPDF ausgezeichnet: Es ist schneller als die meisten Alternativen, der Code bleibt lesbar, und das Previewer-Tool erspart sinnlose Render-Zyklen in der Entwicklung.

Was Nick im Artikel nicht anspricht — wohl weil sein Publikum .NET-Entwickler sind, nicht KMU-Entscheider — ist die Frage der Ownership über Zeit. Wer ist in zwei Jahren noch für diesen Code verantwortlich? Ist QuestPDF dann noch aktiv gepflegt? (Aktuell ja, das Projekt ist lebendig.) Gibt es eine Dokumentation, die auch ein neuer Entwickler versteht, der nicht beim Aufbau dabei war? Diese Fragen klingen bürokratisch, aber ich sehe zu oft, was passiert, wenn sie nicht gestellt werden — der Crystal-Reports-Fall vom Anfang war kein Einzelfall.

Was ich meinen Mandanten empfehle:

  • Unter einer Million Euro Umsatz, internes .NET-Team vorhanden: QuestPDF, Community-Lizenz, sofort anfangen.
  • Zwischen einer und zehn Millionen Euro Umsatz, gelegentlicher Extern-Entwickler: QuestPDF Professional ist das Geld wert, aber explizit eine Person intern als „Dokumenten-Owner" benennen — nicht nur technisch, sondern inhaltlich verantwortlich.
  • Kein .NET-Team, Dokumente ändern sich häufig durch Nicht-Techniker: Ich schaue mir zuerst an, was das bestehende ERP oder CRM schon kann. Viele Systeme — Lexoffice, sevdesk, auch SAP Business One — haben PDF-Export eingebaut, der für 80 Prozent der Anforderungen reicht. Erst wenn dieser Deckel zu eng wird, kommt eine Bibliothek ins Spiel.
  • Wenn es .NET sein soll, aber das Team klein ist: Erwägt, Templates in HTML/CSS zu bauen und per Headless-Browser zu rendern. Das ist ein anderes Trade-off-Profil, aber die Layout-Kontrolle liegt dann bei Leuten, die HTML können — und das sind meistens mehr Leute als solche, die C# können.

Nick hat einen technisch erstklassigen Artikel geschrieben, der zeigt, was mit QuestPDF möglich ist. Was er zeigt, stimmt. Was er nicht zeigt — weil es nicht sein Job ist — ist der organisatorische Kontext, in dem eine solche Entscheidung im Mittelstand landet.

Der vollständige Original-Beitrag von Nick Chapsas: Creating PDFs in .NET using QuestPDF


Du fragst Dich gerade, ob QuestPDF für euren Anwendungsfall passt — oder ob Ihr schon eine Lösung im Einsatz habt, die eigentlich niemand mehr richtig versteht? Dann reden wir dreißig Minuten Klartext darüber.

30 Min Klartext-Sparring

— Bernhard