Show what you delivered.
Not just the hours.
For developers who work for clients: a short delivery brief, backed by what was actually built.
DevReceipt reads the Git history and the time records of a period, for example 14 days, and turns them into a Client Delivery Brief your client reads in two to three minutes. Every statement in it rests on evidence the client can open.
Local-first · Git + time records · Private Beta
Your client paid for outcomes.
You send them hours.
At the end of a period, most clients get one of two things: a list of hours, or a long technical report. The first says how long you worked. The second says how.
Neither shows what the client actually got.
The work is all there, in the repository and in your time records. It just rarely reaches the client in a form they read.
Hours say nothing about outcomes
A timesheet shows effort. It doesn't tell the client which of their problems are now solved.
Technical reports go unread
Commit logs and change lists are written for developers. Clients skim them, or don't open them at all.
Estimates vs reality get argued, not shown
When a client asks how the original estimate held up, the answer depends on who tells it, not on what was recorded.
Your work already left a record.
DevReceipt makes it readable.
DevReceipt works with what already exists: the commits in your Git repository and the time records you already keep. It proposes the structure, you confirm what matters, and your client gets a short brief with the full evidence behind it.
- Git history + time records
- DevReceipt groups and proposes
- You confirm what matters
-
Brief Client Delivery Brief, 2–3 minutes to readLedger Evidence Ledger behind every statement
The brief stays short. The evidence stays complete.
Four steps.
Most of them one click.
Choose repository and period
Pick a Git repository and the period you want to report on, for example the last 14 days.
Upload your time records
Import the export file from your time tracking. DevReceipt reads your records, it doesn't replace your tool.
Confirm the proposals
DevReceipt proposes grouping, descriptions and assignments. Each question says why it is asked, what DevReceipt recommends and what changes in the client report.
Issue the brief
Hand the Client Delivery Brief to your client. DevReceipt keeps an immutable copy, Evidence Ledger included.
DevReceipt only asks where your answer changes a statement to the client. In the real dogfooding period, it asked 15 questions. One of them was blocking.
A brief your client reads.
Evidence your client can check.
Client Delivery Brief
Three to five outcomes in the client's language, each with a short explanation. Plus smaller improvements and the open points that matter to the client, such as deferred work or known limitations.
Evidence Ledger
Every statement rests on a detailed record the client can open: commits, time entries, estimates, scope changes and sources.
Fair estimate comparison
Original estimate and recorded hours appear side by side only where both cover the same work. Where the scope changed, the brief says a direct comparison would mislead.
One-click review
DevReceipt proposes grouping, descriptions and assignments itself. It asks only where an answer changes what the client is told, and one click is usually enough.
Claude Code writes, evidence decides
Claude Code writes the brief through your existing subscription. Every statement must be backed by the work it refers to, and anything unsupported is removed. DevReceipt sets the numbers, never the model.
Local-first
Repositories, time records and reports stay on your machine. DevReceipt has no cloud service.
Two numbers, side by side.
The conclusion is your client's.
With AI-assisted development, hours alone stop describing the work. But a claim like "three times faster" is easy to make and hard to defend.
DevReceipt puts the estimate and the recorded hours next to each other only when both cover the same work, and names exactly which work that is. For example:
The 10 work packages were originally estimated at 235 h. 101 h were recorded directly against those same work packages.
Where the scope changed along the way, the brief says so: a direct comparison would be misleading, so it isn't made.
No ratio. No "faster". No productivity score. No hours derived from commits.
Your client's project stays on your machine.
DevReceipt needs your repository and your time records. That doesn't mean either has to become cloud data. DevReceipt has no cloud service.
Stays local:
One thing does leave your machine: to write the brief, DevReceipt passes the facts of the period to Claude Code, through your own Claude Code subscription. Claude Code works in an empty folder without access to your repository.
For developers who build for clients.
DevReceipt is currently aimed at freelancers and small development agencies that work with Git and already track their time.
Good fit
- Freelancers and small agencies with Git and time tracking
- You want to show clients what was delivered, not only how long it took
- You deliver faster with AI and no longer want hours alone to speak for your work
Not yet
- Teams looking for invoicing, billing or payroll
- Projects without Git
- Anyone who wants a dashboard with productivity scores
DevReceipt is not a time tracker, not a billing tool, not a productivity score and not a replacement for project management.
DevReceipt is being built in the workflow it is designed to improve.
The private beta is currently being dogfooded on a real client project before external access opens.
The initial focus is macOS, Git repositories and Claude Code.
Documentation and the issue tracker for beta testers are public on GitHub.
What developers ask about DevReceipt
Is DevReceipt a timesheet?
No. DevReceipt doesn't track time. It reads the time records you already keep, together with your Git history, and turns both into a short brief for your client.
Does DevReceipt compute productivity?
No. There is no productivity score, no "x times faster" and no hours derived from commits. Where an estimate and the recorded hours cover the same work, both numbers appear side by side with that work named. The conclusions are your client's.
What does the client actually see?
A Client Delivery Brief: three to five outcomes in their language, each with a short explanation, plus smaller improvements and the open points that matter to them. It takes two to three minutes to read. Behind every statement is the Evidence Ledger, which the client can open.
What leaves my machine?
Repositories, time records and reports stay on your machine. DevReceipt has no cloud service. To write the brief, the facts of the period go to Claude Code through your own Claude Code subscription, into an empty folder without access to your repository.
Do I need Claude Code?
Yes, in the current beta. Claude Code writes the brief and the descriptions through your existing Claude Code subscription. DevReceipt checks every statement against the evidence and sets all numbers itself.
Which time-tracking tools work?
DevReceipt imports export files from your time tracking instead of connecting to specific tools. If you're unsure whether your tool's export works, name the tool in your beta request.
Show what you delivered.
Let the evidence speak.
If you build software for clients and want to help shape DevReceipt, request access to the private beta.
Request accessNo public launch yet. No lifetime-free promise. Early testers get beta access while the product is being validated.