Zeigen Sie, was Sie geliefert haben.
Nicht nur die Stunden.
Für Entwickler, die für Kunden arbeiten: ein kurzer Delivery Brief, belegt durch das, was tatsächlich gebaut wurde.
DevReceipt liest Git-History und Zeiterfassung eines Zeitraums, zum Beispiel 14 Tage, und macht daraus einen Client Delivery Brief, den Ihr Kunde in zwei bis drei Minuten liest. Jede Aussage darin stützt sich auf einen Nachweis, den der Kunde öffnen kann.
Local-first · Git + Zeiterfassung · Private Beta
Ihr Kunde bezahlt für Ergebnisse.
Sie schicken ihm Stunden.
Am Ende eines Zeitraums bekommen die meisten Kunden eines von zwei Dingen: eine Stundenliste oder einen langen technischen Report. Die Liste sagt, wie lange Sie gearbeitet haben. Der Report sagt, wie.
Keines von beiden zeigt, was der Kunde tatsächlich bekommen hat.
Die Arbeit ist vollständig da, im Repository und in Ihrer Zeiterfassung. Sie erreicht den Kunden nur selten in einer Form, die er auch liest.
Stunden sagen nichts über Ergebnisse
Eine Stundenliste zeigt Aufwand. Sie sagt dem Kunden nicht, welche seiner Probleme jetzt gelöst sind.
Technische Reports bleiben ungelesen
Commit-Logs und Änderungslisten sind für Entwickler geschrieben. Kunden überfliegen sie oder öffnen sie gar nicht.
Schätzung und Realität werden diskutiert statt gezeigt
Fragt ein Kunde, wie gut die ursprüngliche Schätzung gehalten hat, hängt die Antwort davon ab, wer sie gibt, und nicht davon, was erfasst wurde.
Ihre Arbeit hat längst Spuren hinterlassen.
DevReceipt macht sie lesbar.
DevReceipt arbeitet mit dem, was schon da ist: den Commits in Ihrem Git-Repository und der Zeiterfassung, die Sie ohnehin führen. DevReceipt schlägt die Struktur vor, Sie bestätigen, was zählt, und Ihr Kunde bekommt einen kurzen Brief mit dem vollständigen Nachweis dahinter.
- Git-History + Zeiterfassung
- DevReceipt gruppiert und schlägt vor
- Sie bestätigen, was zählt
-
Brief Client Delivery Brief, 2–3 Minuten LesezeitLedger Evidence Ledger hinter jeder Aussage
Der Brief bleibt kurz. Der Nachweis bleibt vollständig.
Vier Schritte.
Die meisten davon ein Klick.
Repository und Zeitraum wählen
Wählen Sie ein Git-Repository und den Zeitraum, über den Sie berichten wollen, zum Beispiel die letzten 14 Tage.
Zeiterfassung hochladen
Importieren Sie die Exportdatei Ihrer Zeiterfassung. DevReceipt liest Ihre Einträge, es ersetzt Ihr Tool nicht.
Vorschläge bestätigen
DevReceipt schlägt Gruppierung, Beschreibungen und Zuordnungen vor. Jede Frage sagt, warum sie gestellt wird, was DevReceipt empfiehlt und was sich dadurch im Kunden-Report ändert.
Brief herausgeben
Geben Sie den Client Delivery Brief an Ihren Kunden. DevReceipt bewahrt eine unveränderliche Kopie auf, inklusive Evidence Ledger.
DevReceipt fragt nur dort nach, wo Ihre Antwort eine Aussage gegenüber dem Kunden verändert. Im echten Dogfooding-Zeitraum waren es 15 Fragen. Eine davon war blockierend.
Ein Brief, den Ihr Kunde liest.
Ein Nachweis, den er prüfen kann.
Client Delivery Brief
Drei bis fünf Ergebnisse in der Sprache des Kunden, je mit kurzer Erklärung. Dazu kleinere Verbesserungen und die offenen Punkte, die für den Kunden relevant sind, etwa verschobene Arbeit oder bekannte Einschränkungen.
Evidence Ledger
Jede Aussage stützt sich auf einen ausführlichen Nachweis, den der Kunde öffnen kann: Commits, Zeiteinträge, Schätzungen, Scope-Änderungen und Quellen.
Fairer Vergleich mit der Schätzung
Ursprüngliche Schätzung und erfasste Stunden stehen nur dort nebeneinander, wo beide dieselbe Arbeit abdecken. Hat sich der Scope geändert, sagt der Brief, dass ein direkter Vergleich irreführend wäre.
Review mit einem Klick
DevReceipt schlägt Gruppierung, Beschreibungen und Zuordnungen selbst vor. Es fragt nur dort nach, wo eine Antwort verändert, was der Kunde erfährt, und meist reicht ein Klick.
Claude Code schreibt, der Nachweis entscheidet
Claude Code schreibt den Brief über Ihr vorhandenes Abo. Jede Aussage muss durch die Arbeit belegt sein, auf die sie sich bezieht, und was nicht belegt ist, fliegt raus. Die Zahlen setzt DevReceipt, nie das Modell.
Local-first
Repositories, Zeiterfassung und Reports bleiben auf Ihrem Rechner. DevReceipt hat keinen Cloud-Dienst.
Zwei Zahlen nebeneinander.
Den Schluss zieht Ihr Kunde.
Mit KI-gestützter Entwicklung beschreiben Stunden allein die Arbeit nicht mehr. Eine Behauptung wie „dreimal schneller“ ist aber schnell aufgestellt und schwer zu verteidigen.
DevReceipt stellt Schätzung und erfasste Stunden nur dann nebeneinander, wenn beide dieselbe Arbeit abdecken, und benennt genau, welche Arbeit das ist. Zum Beispiel:
Die 10 Arbeitspakete waren ursprünglich auf 235 h geschätzt. Auf genau diese Arbeitspakete wurden direkt 101 h erfasst.
Wo sich der Scope unterwegs geändert hat, sagt der Brief das: Ein direkter Vergleich wäre irreführend, deshalb unterbleibt er.
Kein Verhältnis. Kein „schneller“. Kein Produktivitäts-Score. Keine aus Commits abgeleiteten Stunden.
Das Projekt Ihres Kunden bleibt auf Ihrem Rechner.
DevReceipt braucht Ihr Repository und Ihre Zeiterfassung. Das heißt nicht, dass eines davon zu Cloud-Daten werden muss. DevReceipt hat keinen Cloud-Dienst.
Bleibt lokal:
Eines verlässt Ihren Rechner doch: Für das Schreiben des Briefs übergibt DevReceipt die Fakten des Zeitraums an Claude Code, über Ihr eigenes Claude-Code-Abo. Claude Code arbeitet dabei in einem leeren Ordner ohne Zugriff auf Ihr Repository.
Für Entwickler, die für Kunden bauen.
DevReceipt richtet sich derzeit an Freelancer und kleine Entwicklungsagenturen, die mit Git arbeiten und ihre Zeit bereits erfassen.
Passt
- Freelancer und kleine Agenturen mit Git und Zeiterfassung
- Sie wollen Kunden zeigen, was geliefert wurde, nicht nur, wie lange es gedauert hat
- Sie liefern mit KI schneller und wollen Ihre Arbeit nicht mehr allein an Stunden messen lassen
Passt noch nicht
- Teams, die Rechnungsstellung oder Payroll suchen
- Projekte ohne Git
- Wer ein Dashboard mit Produktivitäts-Scores will
DevReceipt ist keine Zeiterfassung, kein Rechnungs-Tool, kein Produktivitäts-Score und kein Ersatz für Projektmanagement.
DevReceipt entsteht in dem Workflow, den es verbessern soll.
Die Private Beta läuft derzeit im Dogfooding an einem echten Kundenprojekt, bevor externer Zugang öffnet.
Der erste Fokus liegt auf macOS, Git-Repositories und Claude Code.
Dokumentation und Issue-Tracker für Beta-Tester sind öffentlich auf GitHub.
Was Entwickler zu DevReceipt fragen
Ist DevReceipt eine Zeiterfassung?
Nein. DevReceipt erfasst keine Zeiten. Es liest die Zeiterfassung, die Sie ohnehin führen, zusammen mit Ihrer Git-History und macht daraus einen kurzen Brief für Ihren Kunden.
Berechnet DevReceipt Produktivität?
Nein. Es gibt keinen Produktivitäts-Score, kein "x-mal schneller" und keine aus Commits abgeleiteten Stunden. Wo eine Schätzung und die erfassten Stunden dieselbe Arbeit abdecken, stehen beide Zahlen nebeneinander, mit genau benanntem Umfang. Die Schlüsse zieht Ihr Kunde.
Was sieht der Kunde tatsächlich?
Einen Client Delivery Brief: drei bis fünf Ergebnisse in seiner Sprache, je mit kurzer Erklärung, dazu kleinere Verbesserungen und die offenen Punkte, die für ihn relevant sind. Die Lesezeit liegt bei zwei bis drei Minuten. Hinter jeder Aussage steht das Evidence Ledger, das der Kunde öffnen kann.
Was verlässt meinen Rechner?
Repositories, Zeiterfassung und Reports bleiben auf Ihrem Rechner. DevReceipt hat keinen Cloud-Dienst. Für das Schreiben des Briefs gehen die Fakten des Zeitraums an Claude Code, über Ihr eigenes Claude-Code-Abo, in einen leeren Ordner ohne Zugriff auf Ihr Repository.
Brauche ich Claude Code?
Ja, in der aktuellen Beta. Claude Code schreibt Brief und Beschreibungen über Ihr vorhandenes Claude-Code-Abo. DevReceipt prüft jede Aussage gegen die Nachweise und setzt alle Zahlen selbst.
Welche Zeiterfassungs-Tools funktionieren?
DevReceipt importiert Exportdateien aus Ihrer Zeiterfassung, statt sich mit bestimmten Tools zu verbinden. Wenn Sie unsicher sind, ob der Export Ihres Tools funktioniert, nennen Sie das Tool in Ihrer Beta-Anfrage.
Zeigen Sie, was Sie geliefert haben.
Mit Nachweis.
Wenn Sie Software für Kunden entwickeln und DevReceipt mitgestalten wollen, fragen Sie Zugang zur Private Beta an.
Zugang anfragenNoch kein öffentlicher Start. Kein Versprechen auf lebenslang kostenlos. Frühe Tester bekommen Beta-Zugang, während das Produkt validiert wird.