Buchly hinter den Kulissen

Wir machen seit über 20 Jahren Webdesign. Aber das vielleicht beste Lernfeld unseres Lebens war ein eigenes Produkt zu bauen: Buchly.at. Eine Buchhaltungs- und Rechnungs-SaaS speziell für österreichische Selbstständige und Kleinunternehmer, mit OCR-basierter Beleg-Erkennung und KI-Klassifikation. Hier ein offener Blick hinter die Kulissen – was funktioniert hat, was nicht, und was wir bei einem Kundenprojekt nie so machen würden.

Warum überhaupt?

Wie viele Web-Agenturen haben wir jahrelang mit klassischer Buchhaltungssoftware gekämpft. BMD, RZL und Co. sind großartige Tools – aber für Steuerberatungs-Kanzleien gebaut, nicht für Selbstständige, die einmal pro Monat ihre Belege sortieren. Wir wollten:

• Belege fotografieren statt einscannen
• Daten automatisch ausgelesen und vorklassifiziert
• Smart-Matching von Bank-Bewegungen mit Belegen
• Ein-Klick-Monatspaket für die Steuerberatung
• Volle DSGVO-Konformität, AT-Hosting, kein US-Drittlandtransfer

Es gab das nicht in der gewünschten Form. Also haben wir es gebaut.

Der Tech-Stack

• Backend: Node.js mit Fastify, PostgreSQL als Datenbank, Redis für Caching und Job-Queue. Auf Hetzner Cloud (CPX21 für Web, CPX31 für DB) in Nürnberg gehostet.
• Frontend: Klassisches HTML/CSS/Vanilla-JS – kein React, kein Vue. Bewusst „boring tech“. Spart Bundle-Size, vereinfacht Onboarding neuer Devs.
• OCR: Eigene Pipeline mit AWS Textract als Fallback und einem feinabgestimmten Mistral-Modell für deutsche Belege.
• KI-Klassifikation: Claude-API mit kategorisiertem Few-Shot-Prompt für Kontenrahmen-Klassifikation (EKR07).
• Storage: Cloudflare R2 für Belegbilder (deutlich günstiger als S3, EU-Region möglich).
• Bank-Anbindung: über Klarna Kosma / Tink für PSD2-konforme Schnittstellen zu österreichischen Banken.
• Mailings: Brevo für transaktionale E-Mails (Rechnungs-Versand, Bestätigungen) und Newsletter.
• Monitoring: Sentry für Fehler-Tracking, Plausible Analytics für Datenschutz-konforme Statistiken.

Was wir richtig gemacht haben

Boring Tech. Wir haben uns gegen alle modernen Frameworks entschieden – kein React/Next.js, kein TypeScript-Backend mit fancy DI-System, kein Microservice-Setup. Stattdessen ein Monolith in Node.js, der heute noch gut wartbar und performant läuft. Wir bereuen keine dieser Entscheidungen.

Frühe Fokussierung auf einen Markt. AT, Selbstständige und Kleinunternehmer mit pauschalierter Steuerberechnung. Kein „auch DE“, kein „auch Schweiz“. Der enge Fokus hat uns erlaubt, Features sehr spezifisch auf österreichisches Steuerrecht zuzuschneiden – inklusive 13a-EStG-Pauschalierung, OSS-Reporting, ÖGB-Hinweise, AT-Bank-Integration.

Privacy by Design. Alle Daten in EU-Rechenzentren. Keine US-Drittland-Transfers. Sentry self-hosted, Analytics ohne Cookies. Das hat uns mehr Kunden gebracht, als wir gedacht haben – „endlich eine Buchhaltungs-Software, die kein US-Cloud-Backend hat“ war das häufigste positive Feedback.

Was wir falsch gemacht haben

Zu früh skaliert. Mit den ersten 200 Kunden haben wir bereits Multi-Region-Setups, Hochverfügbarkeits-DBs und Read-Replicas eingebaut. Hätten wir uns getrost noch ein Jahr sparen können. Performance war auch ohne diese Komplexität jederzeit ausreichend.

Featuritis. Wir haben in der Beta zu viele Features nebenher gebaut, weil einzelne Kunden das wünschten. Das Resultat: ein Produkt, das alles ein bisschen kann, aber nichts richtig. Mussten 9 Monate später vier dieser Features wieder abschalten.

OCR-Genauigkeit überschätzt. Wir dachten, AWS Textract reicht. Die Realität bei zerknüllten Kassenbelegen, Thermopapier-Verfärbungen und durchgescannten PDFs war ernüchternd. 6 Monate Eigenentwicklung mit feinabgestimmten Modellen waren nötig, um auf 92 % Auto-Erfassung zu kommen.

Onboarding zu komplex. Erste Version erforderte 14 Klicks bis zum ersten erfassten Beleg. Drop-off-Quote im Free-Trial: 65 %. Heute sind es 3 Klicks – und der Drop-off liegt bei 22 %.

Lessons Learned, die jedes SaaS-Team kennen sollte

1. Bau zuerst eine schmerzhafte Lösung für dich selbst. Wir hätten das Produkt nicht so präzise gebaut, wenn wir nicht selbst die Zielgruppe wären.
2. Sage „Nein“ zu 80 % der Feature-Wünsche. Erst wenn drei unabhängige Kunden das gleiche Feature wollen, wird darüber nachgedacht.
3. Customer-Support ist Produktentwicklung. Jede Support-Anfrage ist ein Hinweis auf eine UX-Lücke.
4. Pricing nie zu früh festlegen. Erste Version war € 9,90/Monat – viel zu billig. Heute starten wir bei € 19, für Premium € 39. Conversion ist nicht schlechter geworden.
5. DSGVO als Verkaufsargument. In Österreich, Deutschland und der Schweiz gibt es eine wachsende Zielgruppe, die explizit nach EU-Hosting sucht.
6. Boring Tech siegt. Wir haben in 2,5 Jahren weniger als 10 Tech-Migrationen erlebt. Bei Konkurrenten mit hippem Stack waren es deutlich mehr.

Was als Nächstes kommt

Auf der Roadmap für 2026: native iOS-/Android-Apps für die Beleg-Foto-Erfassung (aktuell läuft das nur als PWA), tiefere Integration mit AT-Steuerberatungs-Software (BMD, RZL), und ein „Steuerberater-Workspace“, in dem Steuerberater mehrere Klienten verwalten können.

Fazit

Buchly war und ist unsere härteste Lehrstunde. Webdesign-Kundenprojekte sind in vielerlei Hinsicht einfach – Anforderung, Umsetzung, Launch, fertig. Ein eigenes Produkt zu bauen heißt, jeden Tag aufs Neue zu entscheiden, was wichtig ist und was nicht. Was Roadmap-Item ist und was Bug. Was Kunden wirklich wollen und was sie nur sagen, weil sie es gerade frustriert sind. Diese Erfahrung fließt in jedes Kundenprojekt zurück. Wer einmal selbst ein Produkt gebaut hat, baut bessere Produkte für andere.