A day-rate freelancer's guide to knowing the real day
· 6 min read
A day rate sells a unit most freelancers have never measured. Record the real length and shape of your working days for a month, then set the rate against the day you actually deliver, write the length of a day into your terms, and use the record to recognize when a client’s “day” was really a day and a half.
The unit you sell is undefined
An hourly rate has a unit everyone agrees on. A day rate does not. To you, a day might mean seven focused hours; to a client, it means from when they first message you until the thing is done, and it includes the evening if the thing is not done. Neither of you has said which, and the gap is paid for by one of you. Usually it is you.
The first step is not to negotiate the definition. It is to find out what your days actually are, because you cannot write terms for a unit you have never seen.
Measure the real day for a month
One week is not enough; day-rate work is lumpy, and a week can be all long days or all short ones. A month of working days shows the distribution.
- Set a closing time that matches what you think a day is. If you believe a day ends at six, set six. This is the line against which the long days will be measured.
- Record every working day for a month, automatically. Punchcard does this from the menu bar without a timer: it notices which app is in front, and at closing time prints a receipt of the day itemized by app with a total. When a day runs past closing time, the receipt still comes, headed SORRY WE MISSED YOU, with the full total. For a day-rate freelancer those late prints are the whole point of the exercise.
- Add a one-line note per day saying whose day it was. A tracker that records app names knows a day was 9 hours 15 minutes; it does not know which client bought it. “Tues: Client A, full day. Wed: A until 2, then proposal for B.” Thirty lines over a month.
- Do not adjust your behavior. Work the way you work. The month is a measurement, not a regime.
- At the end, lay out the month roll. Punchcard prints one; it lists every day with its total. Sort the days into groups by length and see what you actually sold.
What a month of real days tends to show
Everyone’s month is different, but the same features appear in most of them.
The day is longer than the rate assumed. The working day you had in mind when you set the rate was perhaps seven hours. The receipts show a median nearer eight and a half, with a tail of ten- and eleven-hour days on delivery deadlines. If the rate was built on seven, you have been discounting every day by the difference.
The short days are not as short as they feel. A “half day” for a client often shows up as five or six hours on the receipt, because a half day with a 10 am call, an afternoon of changes and a 6 pm “one quick thing” is not half of anything. Counting the days goes into how these add up across a month.
Spillover is concentrated. Long days cluster around specific clients or specific phases, usually the end of a project. That matters because it means the fix is targeted: a delivery surcharge or a defined end-of-day for those clients, not a general rate rise.
Context days are invisible on invoices. Days that were half client work and half running your business appear on the receipts as full days and on your invoices as half days. That is the cost of being self-employed, and it belongs in the rate.
Write the day into your terms
Now you know what a day is, and you can say so. Three lines in your terms cover most of it.
The length of a day. “A day is up to eight hours of work, within a single calendar day.” Pick the number from your own median, not from what sounds reasonable.
What happens past it. “Work beyond eight hours in a day, where requested, is charged at [rate] per hour” or “at a half day.” Clients do not mind this clause; they mind being surprised.
What a half day is. “A half day is up to four hours, booked as a block.” This stops the 10 am call plus the evening fix from being billed as a half.
Write these before the next booking, not during a dispute. Terms introduced after the long day are a negotiation; terms introduced before are just the terms.
Pricing the long day and the short one
With the record in front of you, two pricing questions become simple.
What is the rate? Take the income you need per working hour, multiply by your measured median day, and that is the day rate. If the measured median is eight and a half hours and you had been pricing for seven, the rate should be about a fifth higher than it is, with no other change to justify it.
When is a day two days? A day that ran to eleven hours on the receipt, at a client’s request, was a day and a half, and your terms now say so. Without the receipt, you would have called it “a long one” and billed a day. With it, you have a timestamped total and a rule, and the conversation is a sentence.
The post on setting a closing time and keeping it is the companion to this: once the terms define a day, the closing time is what makes the day end.
What the receipt cannot tell you
A receipt shows the length and the app mix of the day. It does not show who the day was for; Punchcard records app names only, never window titles, document names or URLs, and it has no client or project field. The one-line daily note from step 3 is not optional if you work for more than one client in a day.
It also cannot see the day you spent on site, on the phone, or at a whiteboard. Add those from the calendar. And it does not produce invoices, apply rates, or total a client’s days for the month; it produces the day, honestly, and the arithmetic is yours.
Questions
My days vary enormously. Is a day rate even the right model?
If the month roll shows a wide spread, a day rate with a defined length and an overage clause still works, because the clause converts the long days into income. If the spread is so wide that most days need the clause, consider quoting hours or a fixed fee per deliverable instead. The record is what lets you make that call with numbers.
Should I show a client the receipt for a long day?
You can; the receipt exports as a PNG or plain text and shows a total and an app breakdown with no document names or content. Most of the time you will not need to. Stating the terms and the hours is enough, and the receipt is there if asked.
How do I handle a day that was interrupted by another client?
Bill the first client for the hours they had, at the hourly or half-day rate your terms define, and note it. A receipt gives you the day total; your note gives the split. Do not bill two full days for one calendar day unless both were, in fact, full.
Does Punchcard know which client a day belonged to?
No. It has no clients, projects, tags or rates, and it will not gain them. It tells you how long the day was and which apps filled it. The client is a line you write yourself.