The formula

effective rate   = fee ÷ hours used
cost             = hours used × team cost per hour
margin           = fee − cost
utilization      = hours used ÷ hours included
overage value    = max(0, used − included) × (fee ÷ included)
break-even hours = fee ÷ team cost per hour

As a function:

function retainer({ fee, included, used, costPerHour }) {
  if (!(fee >= 0 && included > 0 && used >= 0 && costPerHour >= 0)) return null;
  const cost = used * costPerHour;
  const over = Math.max(0, used - included);
  const contracted = fee / included;
  return {
    contracted,
    effective: used > 0 ? fee / used : null,
    margin: fee - cost,
    marginPct: fee > 0 ? (fee - cost) / fee * 100 : null,
    utilization: used / included * 100,
    overageValue: over * contracted,
    breakEvenHours: costPerHour > 0 ? fee / costPerHour : null,
  };
}

console.log(retainer({ fee: 4000, included: 40, used: 46, costPerHour: 60 }));
// contracted 100, effective 86.96, margin 1240, marginPct 31, utilization 115, overageValue 600, breakEvenHours 66.67

A 4,000 retainer for 40 hours is 100 an hour on paper. The client used 46: the effective rate is 86.96, the margin falls from 1,600 (40 %, if they had used exactly 40) to 1,240 (31 %), and six hours worth 600 at the contracted rate went unbilled.

Three details in the code

• effective is null at zero hours, not infinity. A month with no work is not an infinitely profitable month; it is a month with no rate to report.
• Overage is valued at the contracted rate, not the cost rate. The 600 is what the client would have paid for those hours under the contract, which is the number to bring to a conversation about scope. At cost it would be 360.
• Break-even hours ignore the hours included. At 60 an hour of team cost, the retainer stops covering cost at 66.67 hours, whatever the contract says. That is the line to watch on a client who keeps asking for "one more thing".

Utilization over 100 % is not good news

On a timesheet, a team at 115 % looks busy. On a retainer it means the client is getting 15 % more than they pay for. Track the effective rate per client per month, and the drift shows up before the quarterly review.

Try it in the browser

The same function runs in our free calculator, nothing stored: retainer profitability calculator.

The formulas and every number above were checked by running the code shown. We built the free calculator linked above.

The formula

revenue needed = income goal ÷ (1 − tax set-aside) + business costs
billable hours = (52 − weeks off) × hours per week × billable share
hourly rate    = revenue needed ÷ billable hours

As a function:

function hourlyRate({ income, tax, costs, weeksOff, hoursPerWeek, billable }) {
  if (!(tax >= 0 && tax < 100 && billable > 0 && billable <= 100 && hoursPerWeek > 0
        && weeksOff >= 0 && weeksOff < 52 && income >= 0 && costs >= 0)) return null;
  const revenue = income / (1 - tax / 100) + costs;
  const hours = (52 - weeksOff) * hoursPerWeek * billable / 100;
  return { revenue, hours, hourly: revenue / hours, day: revenue / hours * 8 };
}

console.log(hourlyRate({ income: 60000, tax: 25, costs: 6000, weeksOff: 6, hoursPerWeek: 40, billable: 60 }));
// revenue 86000, hours 1104, hourly 77.90, day 623.19

An income goal of 60,000 with 25 % set aside for tax needs 80,000 before tax, plus 6,000 of costs: 86,000. Forty-six working weeks of 40 hours at 60 % billable give 1,104 paid hours. 86,000 ÷ 1,104 = 77.90 an hour.

Trap 1: dividing by (1 − t), not multiplying by (1 + t)

To keep 60,000 after setting aside 25 %, you need 60,000 ÷ 0.75 = 80,000. Multiplying by 1.25 gives 75,000, and 25 % of 75,000 leaves you 56,250. The gross-up is a division.

Trap 2: the billable share

Change one input at a time from the example above:

Four extra weeks off raise the rate by about 10 %. Dropping from 60 % to 45 % billable raises it by 33 %. Sales calls, proposals, invoicing and learning all sit in the unbilled share, and a first-year freelancer rarely bills more than half of their working hours. If you guess the billable share, guess low.

The day rate is a multiplication, not a new formula

day = hourly × hours per day. It is a presentation choice: some clients compare day rates, and quoting one hides the billable-share maths from them, which is fine as long as it does not hide it from you.

Try it in the browser

The same function runs in our free calculator, nothing stored: freelance hourly rate calculator.

The formulas and every number above were checked by running the code shown. We built the free calculator linked above.

I published a free 100-row sample of that table under CC BY 4.0: screened-product-ideas on Hugging Face. This post is about the schema, the three design choices that made it worth querying, and a few lines of Python to read it.

The columns

Design choice 1: code the reason at the moment of the kill

Free-text reasons are easy to write and painful to count. Every kill in this pipeline writes a short code from a fixed list (below_line, sibling_family, crowded_no_wedge, not_sharp, market_too_small, …) next to the sentence. The sentence is for reading one row; the code is for reading all of them.

An idea can fail for more than one reason, so kill_codes is multi-valued: crowded_no_wedge;llm_substitute means "existing products already do this, and a chatbot answer would replace it too". Counting has to split the field:

import csv, io, urllib.request
from collections import Counter

URL = ("https://huggingface.co/datasets/bardachtech/screened-product-ideas"
       "/resolve/main/idea-database-sample-100.csv")

with urllib.request.urlopen(URL) as resp:
    rows = list(csv.DictReader(io.TextIOWrapper(resp, encoding="utf-8")))

codes = Counter(code
                for row in rows
                for code in row["kill_codes"].split(";") if code)
print(len(rows), "rows")
for code, n in codes.most_common(6):
    print(f"{code:<20} {n}")

100 rows
below_line           43
sibling_family       25
crowded_no_wedge     9
weak_evidence        4
not_a_unit           4
not_sharp            4

(On macOS with the python.org build, run Install Certificates.command once if urlopen fails with a certificate error, or download the CSV and open it locally.)

Design choice 2: empty means "not measured", not zero

Only ideas that passed the first screens got the ten-criterion scores. In the sample, 2 of 100 rows have c1 … c10 filled. If those blanks were stored as 0, every average over the column would be wrong and every "lowest score" query would return ideas that were never scored. The CSV keeps them empty, and the reading code must keep them apart:

scored = [r for r in rows if r["c1"] != ""]
print("rows with C1-C10 scores:", len(scored))   # 2

Design choice 3: store the line next to the score

Different fields were screened with different scales. In the sample, one digital-download idea has screen_total 47 against a line of 55, a book idea has 3.12 against 3.5. Comparing raw totals across rows would rank a 47 above everything on the 1-to-5 scale. Because each row carries its own screen_line, the honest comparison is the gap to the line:

def margin(row):
    if not row["screen_total"]:
        return None
    return float(row["screen_total"]) / float(row["screen_line"]) - 1

failed = [r for r in rows if margin(r) is not None and margin(r) < 0]
near_misses = sorted(failed, key=margin, reverse=True)[:5]   # closest to the line first

A margin of −0.05 means "5 % short of the line", whatever the scale. The closest miss in the sample is a content idea at 3.18 against 3.2.

What the codes say across all 2,512 ideas

Counting codes over the whole table (any position in kill_codes; these counts come from the export report of all 2,512 rows, the sample alone gives the numbers above), the top four are:

The second line is the lesson I did not expect. An idea generator produces many variants of one idea. Without a "sibling" rule, the screen would have spent its budget re-checking the same dead end 770 times. If you build any kind of generate-and-filter pipeline, group near-duplicates before you score them.

Limits of the data

• The scores are rubric scores from the screen run between 10 October and 10 November 2026, not sales results. A killed idea is not proven bad; it failed this screen.
• Titles were scrubbed: rows with personal or third-party sources were dropped before export.
• The sample is 100 rows stratified by field, so its code counts differ from the full table's.

Links

The sample, its data card and the licence: huggingface.co/datasets/bardachtech/screened-product-ideas. About the author: the same project runs a set of free browser calculators, and this screen is how it picks what to build next: tools.bardach-technologies.com.

The counts and code were checked by running them against the published CSV. I built the pipeline and published the free sample linked above.

The formula in four lines

1. Revenue needed = income goal ÷ (1 − tax set-aside) + business costs → 60,000 ÷ 0.75 + 6,000 = 86,000.
2. Working weeks = 52 − weeks off → 46 (six weeks off assumed).
3. Billable hours = working weeks × hours per week × billable share → 46 × 40 × 0.60 = 1,104.
4. Hourly rate = revenue needed ÷ billable hours → 77.90. Day rate = revenue needed ÷ billable days (46 × 5 × 0.60 = 138) → 623.19.

What to do with it

• Quote day rates for project work: clients compare days, not hours, and you stop selling admin time for free.
• Track unbilled time for one month. If your billable share turns out under 50 %, fixing that beats any rate increase.
• Re-run it when costs, taxes or holidays change, not only when you feel underpaid.

Run your own numbers, free and without sign-up: freelance hourly rate calculator.

Disclosure: I built the calculator linked above and make Clientsroster, a Notion client hub for freelancers.

The layout

Step 1 — price every ingredient per usable unit

Cost per usable unit = pack price ÷ (pack size × usable share), in Ingredients!F: =D2/(B2*E2). Trim is real cost: a 12 kg case of chicken thighs at 54.00 that is 75 % usable after trimming costs 6.00 per usable kg, not 4.50. Keep recipe quantities in the same unit as the pack (kg with kg).

Step 2 — recipes as rows, not as cells

One row per ingredient per dish lets two short formulas cost everything:

unit cost (Recipes!E2):  =XLOOKUP(B2, Ingredients!A:A, Ingredients!F:F)
line cost (Recipes!F2):  =C2*E2

Step 3 — from batch to plate

plate cost = SUMIF(Recipes!A:A, dish, Recipes!F:F) × (1 + waste %) ÷ portions + extras

Example: a curry batch of 30.00, 4 % waste, 6 portions, 0.50 extras (rice garnish, bread) → 30 × 1.04 ÷ 6 + 0.50 = 5.70 a plate.

Step 4 — the two ratios that matter

• Food cost % = plate cost ÷ net menu price → 5.70 ÷ 16.00 = 35.6 %.
• Price for a target = plate cost ÷ target % → 5.70 ÷ 0.30 = 19.00. At 16.00 this dish sits almost 6 points above a 30 % target: re-price it, re-portion it, or accept it as a traffic driver on purpose.

Step 5 — the monthly check

Update pack prices from the month's invoices; the menu re-costs itself. Compare with actual food cost (opening stock + purchases − closing stock, ÷ food sales) to see whether the kitchen matches the recipes.

Common mistakes

Menu price including VAT/sales tax; costing the bought weight instead of the usable weight; grams against a per-kg price; forgetting extras; never re-costing after a supplier price rise.

Free calculator for one dish, no sign-up: food cost and menu price calculator.

Disclosure: I built the calculator linked above and make Larderly, a ready-made menu costing sheet.