Jemand verließ dieses Meeting mit einer einseitigen Zusammenfassung. Zwei Entwickler, sechs Monate, vollständige Kontrolle über den Stack. Das Kassenbonsystem, die QR-Flows, die Datenerfassungsschicht, alles intern entwickelt, genau so, wie das Unternehmen es braucht. Die Zahl auf der Seite sah kleiner aus als jedes Anbieter-Angebot, das sie bisher gesehen hatten.
Achtzehn Monate später hatten sie einen Kassenbon-Sender. Kein Progressive Profiling. Eine E-Mail-Erfassungsrate von 9 %. Und eine Compliance-Lücke, die sich öffnete, als Deutschland die KassenSichV-Felder im Januar 2024 verschärfte, die niemand im Budget vorgesehen hatte zu schließen.
Die Frage war nie, ob sie es bauen konnten. Sondern was sie tatsächlich entschieden hatten zu bauen.
Was Sie tatsächlich entscheiden zu bauen
Die Schätzung deckt fast immer nur Schicht eins ab. Die Schichten zwei bis sechs sind es, die aus sechs Monaten achtzehn werden.
Die POS-Integrationsebene ist das, was das IT-Team vor Augen hat: eine Verbindung zwischen der Kasse und dem Kassenbonsystem. Die meisten mittelständischen Händler betreiben zwei oder drei verschiedene Kassensysteme, und jedes POS-Update erfordert Regressionstests. Diese Schicht wird nicht einmal gebaut. Sie wird kontinuierlich gepflegt, auf Kosten der Zeit Ihres Teams.
Die europäische Compliance-Engine ist das, was die meisten internen Schätzungen vollständig übersehen. Die KassenSichV schreibt für jeden Kassenbon TSE-Seriennummern, Prüfwerte, ERS-Seriennummern und fortlaufende Signaturzähler vor, mit Feldern, die im Januar 2024 verschärft wurden. Das französische AGEC-Gesetz (Loi anti-gaspillage pour une économie circulaire) legt konkrete Anforderungen an digitale Kassenbons fest, die seit August 2023 in Kraft sind: Händler sind verpflichtet, Kunden standardmäßig einen digitalen Beleg anzubieten, anstatt automatisch Papier auszudrucken. Italien verpflichtet Großhändler ab Januar 2027 zur Ausgabe digitaler Kassenbons. Diese Anforderungen sind nicht statisch. Jede Änderung wird zu einem Engineering-Sprint in Ihrem Kalender, nicht im gemeinsamen Roadmap eines Anbieters. Interne Teams kalkulieren diese Funktion in der Regel mit null.
Die DSGVO-Einwilligungs- und Opt-in-Architektur ist kein Ankreuzfeld. Sie ist eine prüfbare Aufzeichnung, pro Kunde, pro Markt, die gegenüber einer Aufsichtsbehörde nachweist, wie die Einwilligung für jedes einzelne Profil eingeholt wurde. Von Grund auf aufgebaut, bei sich ändernden Vorschriften gepflegt.
Das Progressive-Profiling-System verbindet einen ersten QR-Scan mit einem dritten Filialbesuch und einer Loyalty-Anmeldung. Es baut anonyme Geräteprofile zu identifizierten, eingewilligten Kundenbeziehungen aus, ohne dass der Kunde vorab etwas tun muss. Die meisten internen Roadmaps behandeln dies als Phase zwei. Phase zwei wird selten termingerecht geliefert.
Die Post-Purchase-Campaign-Engine verwandelt den Kassenbon von einem Dokument in einen Kanal: Segmentierung, automatisierte Kampagnen, Wallet-Pass-Ausgabe, personalisierte Inhalte. Kein statisches PDF.
Die CRM/CDP-Integrationsschicht sorgt dafür, dass Daten in die bestehenden Systeme des Händlers fließen, und baut diese Verbindungen neu auf, wenn sich der Stack ändert. Er wird sich ändern.
Das IT-Team schätzte die Kosten eines Kassenbon-Senders. Die eigentliche Entscheidung war, ob alle sechs Schichten einer vollständigen In-Store-Customer-Engagement-Technologie von Grund auf intern aufgebaut und gepflegt werden sollen.
Die Kosten, die in der Schätzung nicht auftauchen
Der Build-Befürworter im Raum vergleicht Anbieter-Lizenzkosten mit zwei Senior-Entwicklern für sechs Monate. Dieser Vergleich schließt den Großteil der tatsächlichen Kosten aus.
Die Wartungsrechnung beginnt am ersten Tag nach dem Launch. Forresters Total Economic Impact-Analyse (2024) beziffert die jährliche Software-Wartung auf 15 bis 20 % der ursprünglichen Build-Kosten, wobei 78 % der gesamten Software-TCO nach dem Launch anfallen. Bei einem System, das 200.000 bis 350.000 Euro gekostet hat zu bauen, entspricht das einer dauerhaften Engineering-Allokation von 30.000 bis 70.000 Euro pro Jahr, noch bevor neue Funktionen entwickelt werden. Das System, das in Monat achtzehn ausgeliefert wurde, ist nicht fertig. Es fängt gerade erst an.
Die Opportunitätskosten sind die Zahl, die in den meisten Schätzungen fehlt. Nehmen wir einen mittelständischen Händler mit 20 Filialen und 500 täglichen Transaktionen pro Filiale: 10.000 Transaktionen pro Tag. Eine gut eingesetzte Plattform erreicht eine Kundenidentifikationsrate von 50 %, was 5.000 identifizierbare Kunden pro Tag ergibt. Die Differenz zwischen einem internen Go-Live nach achtzehn Monaten und einem Anbieter-Deployment nach sechs Wochen beträgt rund 470 Tage. Bei 5.000 identifizierbaren Kunden pro Tag sind das 2,35 Millionen verpasste Identifikationsmöglichkeiten: keine Umsatzprognose, sondern die Kundendatenbank, die niemals aufgebaut wird. Führen Sie diese Kalkulation mit Ihren eigenen Zahlen durch.
Die Compliance-Monitoring-Funktion wird in den meisten internen Schätzungen mit null kalkuliert. Deutsche Ausführungsverordnungen lesen, italienische Gesetzgebungsfristen verfolgen, regulatorische Änderungen in Engineering-Sprints umsetzen, bevor ein Stichtag zur Pflicht wird: Das ist eine dauerhafte Aufgabe, kein einmaliges Projekt. Für einen Händler, der in drei europäischen Märkten tätig ist, deckt sie drei regulatorische Umgebungen ab, die sich nicht im Gleichschritt bewegen.
Der ehrliche TCO-Vergleich stellt Anbieter-Lizenzkosten dem vollständigen Build-Preis gegenüber: zuzüglich jährlicher Wartung von 15 bis 20 % dieser Kosten, plus Opportunitätskosten, plus der Compliance-Monitoring-Funktion. BCGs Analyse von über 1.000 Unternehmen in 59 Ländern (2024) ergab, dass mehr als zwei Drittel aller großangelegten Technologieprogramme nicht termingerecht, im Budgetrahmen oder im definierten Umfang abgeschlossen werden. Diese Zahl spiegelt wider, was passiert, wenn die Schätzung eine Schicht abdeckte und das System sechs erforderte.
Wann Eigenentwicklung wirklich die richtige Entscheidung ist
Es gibt zwei Situationen, in denen Eigenentwicklung die richtige Antwort ist. Beide verdienen eine ehrliche Betrachtung.
Der Engagement-Stack ist Ihr tatsächliches Alleinstellungsmerkmal. Einige Händler haben ein proprietäres In-Store-Erlebnis aufgebaut, bei dem die physische Customer Journey das Produkt selbst ist: eine spezifische, proprietäre Engagement-Architektur, die kein Anbieter replizieren könnte und die einen strukturellen Vorteil gegenüber Wettbewerbern schafft. Wenn die Datenerfassungsschicht tatsächlich Teil dieser Differenzierung ist und das Team die Expertise hat, sie aufzubauen und zu betreiben, ist Eigenentwicklung legitim. Die entscheidende Frage lautet: Schafft die Dateninfrastruktur den Wettbewerbsvorteil, oder das Erlebnis, das darauf aufgebaut ist?
Sie haben bereits ein großes, dediziertes Produktteam mit tiefer POS- und Compliance-Expertise. Einige Enterprise-Händler, typischerweise mit 500 oder mehr Filialen und internen Engineering-Teams von 50 oder mehr Personen, können eine Eigenentwicklung auf dem erforderlichen Niveau aufrechterhalten. Das entscheidende Qualifikationsmerkmal ist „bereits“. Das Team erst aufzubauen, um dann das Produkt zu bauen, ist eine andere Kalkulation, und sie gehört in die Schätzung.
Für die meisten mittelständischen europäischen Händler mit 20 bis 300 Filialen gilt keines dieser Kriterien. Der Engagement-Stack ist nicht ihr Alleinstellungsmerkmal. Ihr Produkt, ihre Marke, ihr Einkaufserlebnis ist es. Die Dateninfrastruktur darunter ist eine Commodity-Schicht. Commodities kauft man. Man baut sie nicht.
Die vier Fragen, die die Entscheidung klären
Diese Fragen sind nicht rhetorisch. Jede lässt sich mit Informationen beantworten, die bereits im Raum sind.
Ist dieser Stack Ihr Wettbewerbsvorteil oder die Infrastruktur darunter?
Wenn die ehrliche Antwort „Infrastruktur“ lautet, ist das ein Kaufsignal. Sie bauen kein eigenes Stromnetz, weil Sie zuverlässigen Strom brauchen. Wenn die Datenerfassungsschicht tatsächlich der Ort ist, an dem der Wettbewerbsvorteil liegt, und dieser Anspruch einer internen Prüfung standhält, ändert sich die Antwort. Die meisten Händler, die diese Frage ehrlich durchdenken, stellen fest, dass dem nicht so ist.
Haben Sie das Team, um dies heute zu bauen, oder müssten Sie erst einstellen und schulen?
Die Schätzung sollte die Kosten für die Zusammenstellung des Teams einschließen. Ravios Compensation Trends Report 2025 beziffert die vollständig belasteten Jahreskosten eines Senior Software Engineers in Deutschland auf 111.800 bis 130.000 Euro, einschließlich Arbeitgebersozialabgaben. Zwei Entwickler für sechs Monate entsprechen 100.000 bis 130.000 Euro, noch ohne Infrastruktur- oder Integrationskosten. Wenn diese Entwickler heute nicht vorhanden sind, kommen Recruiting, Onboarding und Einarbeitungszeit hinzu. Ein Anbieter-Deployment in sechs Wochen gegenüber erst Einstellen und dann Bauen ist ein fundamental anderer Vergleich.
Was ist die vollständige Compliance-Oberfläche, die Sie aufbauen, und wer überwacht sie bei Änderungen?
Listen Sie jeden Markt auf, in dem das Unternehmen tätig ist. Benennen Sie für jeden die fiskalischen und datenschutzrechtlichen Anforderungen, die für die In-Store-Datenerfassung gelten. Benennen Sie dann die Person im Team, die die Expertise hat, diese Anforderungen umzusetzen und zu überwachen, wenn sie sich weiterentwickeln. Wenn die Antwort „das würden wir herausfinden“ lautet, gehört dieses Risiko in die Schätzung, nicht in den Projektrückblick.
Was sind die täglichen Kosten, wenn Sie nicht live sind?
Führen Sie die Opportunitätskostenkalkulation aus dem obigen Abschnitt mit Ihren eigenen Zahlen durch. Nehmen Sie das tägliche Transaktionsvolumen des vergangenen Monats, wenden Sie eine Identifikationsrate von 50 % an, und multiplizieren Sie mit der Differenz zwischen dem geschätzten internen Go-Live und einem Anbieter-Deployment in sechs Wochen. Das ist die Kundendatenbank, die nicht existieren wird, wenn der Build zu lange dauert. Diese Zahl gehört in den Raum, bevor die Entscheidung getroffen wird.
Die meisten Händler, die diese vier Fragen durcharbeiten, kommen zur selben Antwort. Der Rahmen ist nicht so konstruiert, dass er in eine Richtung zeigt. Die Daten tun das meistens ohnehin.
Wenn Sie sich der Anbieter-Evaluation nähern, finden Sie im Leitfaden zur Bewertung digitaler Kassenbon-Plattformen eine strukturierte Methode, um Anbieter anhand der tatsächlich relevanten Kriterien zu vergleichen.
Was die richtige Plattform tatsächlich liefert (was Eigenentwicklung nie erreicht)
Interne Builds scheitern fast immer an den Schichten eins und zwei. Die ersten zwölf Monate gehen darauf, den Kassenbon korrekt darzustellen und die POS-Integration stabil zu machen. Die Engagement-Schicht, Progressive Profiling, Post-Purchase-Kampagnen, Loyalty-Anmeldung über den Kassenbon, Wallet-Pass-Kommunikation, wird auf Phase zwei verschoben. Phase zwei kommt selten nach dem ursprünglichen Zeitplan, weil die in Monat eins unterschätzte Compliance-Arbeit noch in Monat vierzehn Engineering-Kapazität bindet.
Die gekaufte Plattform beginnt dort, wo der interne Build hinstrebte. Die Compliance- und Integrationsschicht ist bereits gelöst. Die ersten Wochen des Deployments fließen in Receipt-Design und Kampagnenlogik, nicht in das Debuggen von KassenSichV-Feldvalidierungen auf einem Legacy-Terminal.
Der praktische Unterschied zeigt sich in den Erfassungsdaten. Interne Implementierungen, die tatsächlich ausgeliefert werden, erzielen typischerweise E-Mail-Erfassungsraten von 9 bis 15 %, weil die Profiling-Logik und die Einwilligungsarchitektur im Verhältnis zur Kassenbon-Zustellung unterressourciert waren. Starke Plattform-Deployments erzielen E-Mail-Erfassungsraten von 60 bis 70 %. Das ist kein Feature-Unterschied. Es sind Jahre der Iteration an genau dem Problem, das interne Builds noch im ersten Jahr lösen.
Die Compliance-Abdeckung reist mit der Plattform. Wenn Deutschland ein KassenSichV-Feld aktualisiert oder Italien ein Ausführungsdekret erlässt, wird der Engineering-Sprint über die gesamte Kundenbasis des Anbieters verteilt. Ein internes Team trägt ihn allein.
Was das in der Praxis bedeutet: Jemand liest die Ausführungsverordnung, interpretiert, welche Kassenbon-Felder sich wann ändern, scoped die Engineering-Arbeit, testet sie über alle Kassensystem-Umgebungen des Unternehmens und deployed vor dem Enforcement-Stichtag. Für einen Anbieter, der in mehreren europäischen Märkten tätig ist, wird dieser Sprint geteilt und in der Plattform-Subscription absorbiert. Für ein internes Team ist er ungeplant und nicht budgetiert, bis er keine Option mehr ist.
Das zeigt sich typischerweise, wenn Händler von einer Eigenentwicklung zu einer Plattform wechseln: Sie gaben keine Kontrolle auf. Sie lenkten Engineering-Kapazität von der Wartung von Commodity-Infrastruktur auf den Aufbau der Dinge um, die sie tatsächlich differenzieren.
Das ist es, was refives Plattform in der Praxis liefert: keinen Kassenbon-Sender, sondern eine deployte, regelkonforme Customer-Engagement-Infrastruktur, die ab Woche eins Daten erfasst. Demo buchen.
Der erste Schritt, egal wie Sie entscheiden
Ob die Schlussfolgerung Eigenentwicklung oder Kauf ist, der erste Schritt ist derselbe. Führen Sie die Opportunitätskostenkalkulation für das Unternehmen durch. Nehmen Sie das tägliche Transaktionsvolumen des vergangenen Monats. Wenden Sie eine Identifikationsrate von 50 % an. Multiplizieren Sie mit 365. Diese Zahl ist die Größe der Kundendatenbank, die das Unternehmen entweder aufbaut oder nicht aufbaut.
Für die meisten mittelständischen Händler ist die Zahl groß genug, dass die Frage nicht lautet, ob in diese Fähigkeit investiert werden soll, sondern wie schnell man live sein kann. Das In-Store-Customer-Engagement-Touchpoints-Framework zeigt, wie diese Fähigkeit über die gesamte Customer Journey aussieht.
Wenn die Zahl groß genug ist, um relevant zu sein, dreht sich das nächste Gespräch um die Geschwindigkeit bis zum Go-Live.
Die meisten sollten es nicht. Die Antwort hängt von drei Bedingungen ab: ob der Engagement-Stack ein echter Wettbewerbsvorteil ist, ob das erforderliche Team bereits vorhanden ist, und ob die vollständige Compliance-Oberfläche kalkuliert wurde statt nur der Kassenbon-Sender. Für die meisten mittelständischen europäischen Händler mit 20 bis 300 Filialen ist die Datenerfassungsinfrastruktur kein Alleinstellungsmerkmal. Bei 10.000 täglichen Transaktionen repräsentieren die Opportunitätskosten eines achtzehnmonatigen Builds über 2,35 Millionen verpasste Kundenidentifikationsmöglichkeiten.
Ein Kassenbon-Sender allein dauert drei bis vier Monate. Der vollständige Stack, der POS-Integration, europäische Fiscal-Compliance, DSGVO-Einwilligungsarchitektur, Progressive Profiling, Post-Purchase-Kampagnen und CRM-Integration umfasst, dauert mindestens zwölf bis achtzehn Monate. Die meisten internen Schätzungen decken nur das erste Element ab, und die Lücke zwischen dieser Schätzung und dem vollständigen Build ist der Ort, an dem die meisten Projekte ins Stocken geraten oder unvollständig ausgeliefert werden. Eine gekaufte Plattform wird in vier bis sechs Wochen deployed.
Die anfänglichen Build-Kosten für einen mittelständischen Händler liegen je nach Umfang und Teamzusammensetzung bei 150.000 bis 400.000 Euro. Die laufende Wartung beläuft sich anschließend laut Forresters Total Economic Impact-Analyse (2024) auf 15 bis 20 % dieser Build-Kosten jährlich, wobei 78 % der gesamten Software-TCO nach dem Launch anfallen. Die Anbieter-Lizenzgebühr sieht anders aus, wenn man sie mit der vollständigen Zahl vergleicht statt nur mit der ursprünglichen Schätzung.
Es gibt zwei echte Fälle. Erstens: Der Engagement-Stack ist ein zentrales Alleinstellungsmerkmal und das Team zu dessen Aufbau und Betrieb ist bereits vorhanden. Zweitens: Der Händler verfügt über ein großes Engineering-Team mit tiefer POS- und Retail-Compliance-Expertise. Für die meisten mittelständischen Händler mit weniger als 300 Filialen gilt keine dieser Bedingungen.
Der Build-TCO setzt sich zusammen aus initialer Entwicklung plus jährlicher Wartung von 15 bis 20 % der Build-Kosten plus Compliance-Monitoring plus Opportunitätskosten des verzögerten Deployments. Der Buy-TCO besteht aus Anbieter-Lizenzierung plus Implementierung plus Integration. Die meisten Build-Schätzungen schließen Wartung und Opportunitätskosten aus. Wenn diese einbezogen werden, kehrt sich der Vergleich in der Regel um.
Technisch ja. Aber die Compliance-Oberfläche ist größer und dynamischer, als die meisten Teams kalkulieren. Die KassenSichV erfordert TSE-Datenfelder, die im Januar 2024 verschärft wurden. Frankreichs AGEC-Spezifikationen sind seit August 2023 in Kraft. Italiens Anforderungen für Großhändler treten ab Januar 2027 in Kraft. Anbieter absorbieren jede Aktualisierung über ihre gesamte Kundenbasis. Ein internes Team trägt sie allein.
Möchten Sie sehen, wie eine regelkonforme, deployte Plattform aussieht, bevor Ihr Team diese Entscheidung trifft? Die refive-Demo dauert 20 Minuten.
