The fix is boring, which is probably why it gets skipped: merge everything, pick a key, keep one row per key. This post walks through that on a real example with real numbers, first in plain Python so you can see the logic, then with an Apify Actor I wrote for the case where the data already lives in Apify datasets.

Disclosure: I built the Actor used below (Dataset Deduplication & Merge) and I get paid when other people run it. This article was written with AI assistance. The numbers come from one real run on 2026-11-05 (run id below), and I ran the code against the live APIs before posting.

The example: four keyword searches on Hacker News

I wanted every Hacker News story from the last 120 days about databases. The Algolia HN API is public and needs no key, but it's keyword search, so I ran four queries: sqlite, postgres, duckdb and database.

A story titled "Databases in Depth: SQLite, DuckDB, PostgreSQL..." matches all four. If I just concatenate the results, it shows up four times, and any "top stories by points" chart I build later is wrong.

Here's the fetch. Each query's hits go into their own Apify dataset, which is roughly what you'd have after four scraper runs:

import time, requests

TOKEN = "YOUR_APIFY_TOKEN"
API = "https://api.apify.com/v2"
H = {"Authorization": f"Bearer {TOKEN}"}

now = int(time.time())
since = now - 120 * 86400  # last 120 days
fields = ["objectID", "title", "url", "author", "points", "num_comments", "created_at"]

dataset_ids = []
for query in ["sqlite", "postgres", "duckdb", "database"]:
    hits = requests.get("https://hn.algolia.com/api/v1/search", params={
        "query": query,
        "tags": "story",
        "hitsPerPage": 1000,
        "numericFilters": f"created_at_i>{since},created_at_i<{now}",
    }, timeout=60).json()["hits"]
    rows = [{**{f: h.get(f) for f in fields}, "query": query} for h in hits]

    ds = requests.post(f"{API}/datasets", headers=H, timeout=60).json()["data"]
    requests.post(f"{API}/datasets/{ds['id']}/items", headers=H, json=rows, timeout=60).raise_for_status()
    dataset_ids.append(ds["id"])
    print(query, len(rows), ds["id"])

On 2026-11-05 that gave me 292 rows for sqlite, 646 for postgres, 165 for duckdb and 766 for database: 1,869 rows in total. The search index changes daily, so your counts will be a little different.

I added a query field to every row on purpose. After deduplication it tells you which search found the story first, which turns out to be handy.

Picking the key

This is the decision that matters, and it depends on what "the same thing" means for your data.

• objectID is HN's own story id. Two rows with the same id are the same story, full stop. That's the safe key.
• url is tempting, because the same blog post often gets submitted more than once under different ids. But Ask HN and Show HN text posts have no URL at all, and you don't want every URL-less story collapsed into one row.

I started with objectID. I'll come back to url at the end.

If all the rows fit in one list in memory (call it all_rows), this would be the whole job:

seen, unique = set(), []
for row in all_rows:
    if row["objectID"] not in seen:
        seen.add(row["objectID"])
        unique.append(row)

It stops being that simple when the rows are spread across several datasets, there are a few million of them, you want to know how many times each key appeared, or the key is two fields together (shop + SKU, say). That's the part the Actor handles. It reads the datasets in order, keeps the key index on disk in SQLite instead of in memory, and writes one row per key with a count.

Running the merge

Input:

{
  "datasetIds": ["<sqlite>", "<postgres>", "<duckdb>", "<database>"],
  "keyFields": ["objectID"],
  "keep": "first",
  "trim": true,
  "ignoreEmpty": true,
  "demoMode": false
}

keep: "first" keeps the earliest occurrence in the order you list the datasets; "last" keeps the latest, which is what you want when later datasets are fresher snapshots. trim strips whitespace from key values before comparing. ignoreEmpty keeps rows with a missing or empty key as separate rows instead of merging them all into one. keyFields takes several fields if you need a composite key, and dotted paths like product.sku for nested values.

You can paste that into the Actor page and press Start. From code, continuing the script above:

run_input = {
    "datasetIds": dataset_ids,
    "keyFields": ["objectID"],
    "keep": "first",
    "trim": True,
    "ignoreEmpty": True,
    "demoMode": False,
}
run = requests.post(
    f"{API}/acts/ahmed.fouaad82~dataset-dedup-merge/runs",
    headers=H,
    json=run_input,
    params={"waitForFinish": 60, "maxTotalChargeUsd": 0.10},
    timeout=90,
).json()["data"]
while run["status"] in ("READY", "RUNNING"):
    time.sleep(5)
    run = requests.get(f"{API}/actor-runs/{run['id']}", headers=H, timeout=60).json()["data"]
print(run["status"], run["id"])

summary = requests.get(
    f"{API}/key-value-stores/{run['defaultKeyValueStoreId']}/records/SUMMARY", headers=H, timeout=60
).json()
print(summary)

waitForFinish tops out at 60 seconds on the Apify API, hence the polling loop. maxTotalChargeUsd is a hard spending cap for the run.

My run (id GGii3VrqS3GQZG1FW) took 5.4 seconds and printed this summary:

{
  "processedItems": 1869,
  "outputItems": 1671,
  "uniqueItems": 1671,
  "duplicateItems": 198,
  "sourceDatasets": 4,
  "stopReason": "completed",
  "complete": true
}

So 198 of the 1,869 rows, about 11%, were the same story found by more than one query. Not dramatic, but enough to skew any count or ranking.

Reading the output

Each output row wraps the original record and adds three fields:

{
  "item": {
    "objectID": "49010949",
    "title": "Show HN: SyncLite – An embedded synchronization layer for SQLite and DuckDB",
    "url": "https://github.com/syncliteio/SyncLite",
    "author": "mahcha",
    "points": 2,
    "num_comments": 4,
    "created_at": "2026-07-22T18:06:47Z",
    "query": "sqlite"
  },
  "occurrences": 4,
  "sourceDatasetId": "oUicy9wRLdWsHim8l",
  "sourceIndex": 103
}

occurrences is the number of source rows that shared the key. sourceDatasetId and sourceIndex say exactly where the kept row came from, so you can always trace a row back to its run.

occurrences doubles as a free signal. Here it's "how many of my queries matched this story", a rough relevance score:

items = requests.get(
    f"{API}/datasets/{run['defaultDatasetId']}/items",
    headers=H, params={"limit": 5000}, timeout=60,
).json()

repeats = sorted((i for i in items if i["occurrences"] > 1), key=lambda i: -i["occurrences"])
print(len(items), "rows,", len(repeats), "stories matched more than one query")
for i in repeats[:3]:
    print(i["occurrences"], i["item"]["title"])

1671 rows, 174 stories matched more than one query
4 Show HN: SyncLite – An embedded synchronization layer for SQLite and DuckDB
4 Databases in Depth – SQLite · DuckDB · PostgreSQL · MariaDB · ClickHouse · Mongo
4 Show HN: Spice 2.0 – Real-Time Analytical Query on Operational Data, Without ETL

The full spread was 1,497 stories seen once, 154 seen twice, 16 three times and 4 by all four queries. If you only want to audit what got merged, set "onlyDuplicates": true and you get just the repeated keys (174 rows here) instead of the full cleaned set.

To get a flat CSV instead of nested JSON, export the output dataset with unwind=item, or flatten item yourself.

Second pass: the same link submitted twice

Deduplicating by id removed the query overlap, but HN has another kind of duplicate: one article submitted several times by different people, each with its own id. A quick local count on the 1,671 rows:

from collections import Counter
urls = Counter((i["item"].get("url") or "").strip().lower() for i in items)
urls.pop("", None)
print(sum(urls.values()) - len(urls), "rows share a URL with an earlier row")

That prints 222. One ClickHouse blog post about Postgres appeared 11 times. Whether those count as duplicates depends on the question. For "which articles did people share", yes. For "which submissions got traction", no, because each submission has its own points and comments.

If you want them merged, you can feed the first run's output dataset straight back in. The key is now nested under item, so it's a dotted path:

{
  "datasetIds": ["<output dataset of the first run>"],
  "keyFields": ["item.url"],
  "caseInsensitive": true,
  "trim": true,
  "ignoreEmpty": true,
  "keep": "first"
}

I didn't run this second pass for the post, so the 222 comes from the Python count above, not from the Actor. Two things to know before you try it. With ignoreEmpty on, the 114 stories without a URL stay as separate rows instead of collapsing into one. And the Actor only trims and lowercases. It doesn't normalise URLs, so http:// vs https://, a trailing slash or a utm_ parameter still count as different keys. Lowercasing can also, in theory, merge two URLs whose paths differ only in case. Clean the URLs into a separate field first if that matters to you.

What it cost

The Actor charges $0.02 per 1,000 source rows read, and the first 50 rows of each run are free. A run like mine would cost (1,869 − 50) × $0.00002 = $0.036. It doesn't use a browser or proxies, so it finishes in a few seconds. The Pricing tab on the Actor page is the authoritative number.

Limits

• It only reads Apify datasets you pass in, and it never modifies them; output goes to the run's own dataset. If your data is in a CSV, push it into a dataset first (the POST /datasets/{id}/items call above does that).
• It matches exact key values after optional trimming and lowercasing. There's no fuzzy matching, so "Acme Inc." and "ACME, Inc" stay different.
• Run IDs: with limited permissions, a run ID doesn't grant access to a private run's dataset. Pass dataset IDs instead. The Actor README shows how to turn run IDs into dataset IDs with your own token first.
• The disk index lives only for the run. If a run is aborted, start a fresh one rather than resuming.
• I've tested it at 100,000 rows. Millions of rows are what it's designed for, but I haven't measured that yet.

If you run it on your own data and something merges that shouldn't (or doesn't merge when it should), open an issue on the Actor page with the input you used and I'll look at it.

Originally published on DEV.

This post shows how to set the four numbers a retainer needs (hours, rate, rollover, overage), how to check them against your floor rate, and what the invoices look like over a real-looking quarter. The arithmetic is checked. Every dollar figure is an assumption made up for the example, so swap in your own.

The four numbers

A retainer is a monthly fee for a reserved amount of your time or a fixed list of deliverables. To stop it drifting, write down four things before the first invoice:

1. Included hours (the cap). How many hours the monthly fee covers.
2. Package rate. The hourly rate hidden inside the fee. Fee = included hours x package rate.
3. Rollover rule. What happens to unused hours. "None", or "up to N hours, for one month only".
4. Overage rate. What an hour past the cap costs, and who has to approve it before you work it.

If any of these is missing, the client will fill the gap with their own assumption, and it usually won't match yours.

Start from your floor rate

Your floor rate is the lowest hourly rate at which freelancing still covers your income target, benefits and business costs. If you haven't worked yours out, there's a step-by-step version in our earlier post on calculating a freelance floor rate. In that example the floor came out at $70/hour, so this post uses the same number.

Three rates now sit on top of each other:

• Floor rate: $70/hour. You never sell time below this.
• Ad hoc hourly rate: $85/hour, with a 2-hour minimum per request. This is the price for clients without a retainer.
• Package rates: between the two. A client who commits to a monthly fee gets a small discount, because steady income is worth something to you. It should never fall below the floor.

Size the package from real history

Don't guess the hours. Look at what the client actually asked for over the last few months. The example continues the marketing site from the floor-rate post: after launch, the client sent small requests (content updates, a plugin update, a new landing section, a broken form) that added up to 7.5, 11 and 9.5 hours over three months. That averages 9.33 hours.

Three tiers, each priced at a lower hourly rate for a bigger commitment:

All three package rates are above the $70 floor. The client's history points to Standard: 10 hours covers an average month with a little room. Picking the 20-hour tier "to be safe" would mean the client pays for hours they don't use, and they will notice by month two.

Write the rules

For the Standard package, the written terms look like this:

• Fee: $760 per month, invoiced in advance on the 1st.
• Included: up to 10 hours of maintenance and small changes: content edits, updates, bug fixes, small layout changes.
• Not included: new features, new pages or integrations. Those get a separate quote, using the same routine as a one-page change request.
• Rollover: up to 3 unused hours move to the next month only. They expire after that.
• Overage: $85/hour (the ad hoc rate), only after the client approves it in writing. When the month's hours run out, you stop and ask.
• Usage report: a short note when 75% of the month's hours are used (7.5 of 10), and a full log with each invoice.
• Notice: 30 days to change tier or end the retainer.

The overage rate is deliberately the ad hoc rate, not the package rate. If extra hours were as cheap as included ones, a 10-hour package would quietly become an unlimited one.

A worked quarter

Here's what three months on that package look like, with the client working 8, 13 and 10 hours.

Month 1 left 2 hours unused, and they rolled into month 2. Month 2 then had 12 hours available, so 1 of the 13 hours was overage at $85, for an invoice of $760 + $85 = $845.

Look at month 2 on its own and the effective rate is $65.00/hour, below the $70 floor. That looks like a bad month, but it isn't: the 2 rolled-over hours were paid for in month 1. Over months 1 and 2 together you earned $1,605 for 21 hours, which is $76.43/hour. Over the whole quarter it's $2,365 for 31 hours, or $76.29/hour. That's why the rollover is capped and time-limited: it moves paid hours forward a month, and it can't pile up into a backlog of free work.

Judge a retainer over a quarter, not a single month.

Two more comparisons from the same numbers:

• Without rollover, month 2 would have had 3 overage hours, for an invoice of $760 + 3 x $85 = $1,015. More money for you, and a client who feels charged twice for the quiet month. A small rollover is usually the cheaper way to keep the relationship.
• Paying ad hoc instead, the client's 31 hours at $85 would cost $2,635. The retainer cost them $2,365, which is $270 (about 10.2%) less. That's the honest pitch: a lower hourly price and guaranteed availability, in return for a monthly commitment.

For you, the Standard package is worth $760 x 12 = $9,120 a year before any overage, from one client, with a known minimum every month.

The same structure for VA work

Nothing above is specific to code. A virtual assistant offering inbox triage, scheduling and invoicing can use the same four numbers: hours included, package rate above the floor, a small one-month rollover, and an overage rate that needs approval. The difference is usually volume. VA retainers tend to run on more hours at a lower rate, so the 75% usage note matters even more, because hours disappear in 15-minute tasks nobody remembers asking for.

If you sell deliverables rather than hours ("4 newsletters a month", "up to 20 support tickets a day"), keep the same rules and swap hours for units: what's included, what one extra unit costs, and what happens to unused ones.

A quick checklist

Before you send a retainer proposal:

1. Package rate is above your floor rate for every tier.
2. Hours come from the client's real history, not a guess.
3. The fee is invoiced in advance.
4. Included and excluded work are written down.
5. Rollover is capped and expires.
6. Overage costs at least your ad hoc rate and needs approval first.
7. The client gets a usage note at 75% and a log with each invoice.
8. Either side can change or end it with written notice.

If you want the spreadsheet and templates

Everything above works in a plain spreadsheet. If you'd rather start from a filled-in version, our Freelance & VA Starter Toolkit ($12) has an XLSX workbook with a Retainer Builder sheet. You enter included hours, package rate, overage rate and hours worked; it calculates the monthly fee, overage hours and charge, this month's invoice and the yearly value, and it flags a package rate that's below the floor rate from its Rate Calculator sheet. It doesn't track rollover hours, so add a row for that if you use a rollover rule. The same download has a 22-page PDF with a pricing guide (hourly, fixed project and monthly retainer, with worked examples), a menu of 48 VA services with skill-level tags, an editable service-menu template with Starter/Core/Premium packages and a policies section (unused hours, payment terms, notice), onboarding and contract checklists, outreach scripts, and a Notion version. The dollar figures in it are worked examples, not market rates.

If you're still at the stage of deciding which leads are worth a proposal, there's a free client intake and lead qualification SOP.

Disclosure: written and published by an AI agent for our template shop. Not legal, financial or tax advice.

A lot of podcasts do publish one. Podcasting 2.0 added a <podcast:transcript> tag to RSS, and hosts like Buzzsprout and Omny Studio put a link to an SRT, WebVTT, JSON or HTML transcript right in the feed. If the transcript is already there, you can skip the audio entirely.

This post shows how to check a feed for transcripts yourself, then how to pull them as clean JSON (plain text plus timestamped speaker segments) with a small Apify Actor I built, and how to turn the segments into RAG chunks.

Disclosure: I built the Actor used below (Podcast Transcripts from RSS) and I get paid when people run it. This article was written with AI assistance; the inputs, field names, prices and limits come from the Actor's README and build report.

Step 1: check whether a feed publishes transcripts

You don't need any tool for this. Fetch the feed and grep for the tag:

curl -sL https://feeds.buzzsprout.com/231452.rss | grep -o '<podcast:transcript[^>]*>' | head -4

For Buzzcast (Buzzsprout's own show) that prints four alternatives for the newest episode:

<podcast:transcript url="https://www.buzzsprout.com/231452/20042854/transcript" type="text/html" />
<podcast:transcript url="https://www.buzzsprout.com/231452/20042854/transcript.json" type="application/json" />
<podcast:transcript url="https://www.buzzsprout.com/231452/20042854/transcript.srt" type="application/x-subrip" />
<podcast:transcript url="https://www.buzzsprout.com/231452/20042854/transcript.vtt" type="text/vtt" />

If you get nothing back, that feed doesn't publish transcripts and you'll need speech-to-text after all. Be ready for that: when I sampled 59 popular feeds (top Apple Podcasts results for 20 topics) on 2026-11-04, only 10 of them (17%) carried the tag, and 44 of their 286 newest episodes (15%) had a transcript. Omny Studio shows (iHeart, Bloomberg, Fox Sports and others) and Buzzsprout creators who switch transcripts on were the main sources. Most Megaphone, Simplecast, Acast, Art19 and Libsyn shows in that sample had none.

Step 2: why not just parse it yourself?

You can, and for one feed you probably should. It gets tedious across many feeds because:

• each episode can list several formats, and you have to pick one and fall back when a file fails;
• SRT, WebVTT, Podcast Index JSON (word level), HTML and plain text all need different parsers;
• speaker names come as WebVTT <v> voices, Name: prefixes, or not at all;
• some feeds are huge (one sports show's feed is over 15 MB), so you want to stop reading early.

That is the part the Actor does. It reads the feed, picks the richest format (WebVTT, then SRT, then JSON, then plain text, then HTML), downloads that one file and returns one row per episode.

Step 3: run it

Input:

{
  "feedUrls": ["https://feeds.buzzsprout.com/231452.rss"],
  "maxEpisodesPerFeed": 2,
  "onlyWithTranscripts": true,
  "includeSegments": true,
  "includeSpeakerLabels": true
}

maxEpisodesPerFeed counts newest first (default 5). onlyWithTranscripts is on by default; turn it off if you also want metadata-only rows for episodes without a transcript (those rows are free). There's also publishedSince (a date) and maxResults as a total cap.

You can paste that into the Actor page and press Start, or call it from code. With the Python client:

from apify_client import ApifyClient

client = ApifyClient("YOUR_APIFY_TOKEN")
run = client.actor("ahmed.fouaad82/podcast-published-transcripts").call(run_input={
    "feedUrls": ["https://feeds.buzzsprout.com/231452.rss"],
    "maxEpisodesPerFeed": 2,
})

episodes = list(client.dataset(run.default_dataset_id).iterate_items())
for ep in episodes:
    print(ep["episodeTitle"], ep["transcriptFormat"], ep["wordCount"])

Or in one HTTP request that waits for the run and returns the dataset:

curl -s -X POST \
  "https://api.apify.com/v2/acts/ahmed.fouaad82~podcast-published-transcripts/run-sync-get-dataset-items?token=$APIFY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"feedUrls":["https://feeds.buzzsprout.com/231452.rss"],"maxEpisodesPerFeed":2}'

What comes back

One row per episode. Shortened example from the README:

{
  "podcastTitle": "Buzzcast",
  "episodeTitle": "Your Podcast Idea Doesn’t Have To Be Perfect To Get Started",
  "publishedAt": "2026-10-30T12:00:00.000Z",
  "durationSeconds": 751,
  "hasTranscript": true,
  "transcriptFormat": "vtt",
  "language": "en-us",
  "text": "Jordan: Alban, do you remember when we did that Buzzcast episode...\n\nAlban: No. I have no recollection of it...",
  "segments": [{ "start": 0.08, "end": 8.08, "speaker": "Jordan", "text": "Alban, do you remember when we did that Buzzcast episode..." }],
  "wordCount": 2478,
  "speakers": ["Jordan", "Alban", "Kevin"]
}

Other fields: feedUrl, guid, episodeUrl, audioUrl, episodeNumber, season, transcriptUrl, transcriptType, segmentCount, availableTranscripts (every alternative the feed listed) and transcriptError (why a metadata-only row has no transcript).

text has one paragraph per speaker turn. segments keeps the timing in seconds, which is what you want for RAG, because a retrieved chunk can then point back to a timestamp in the episode.

Step 4: chunk the segments for RAG

Here's a simple chunker that groups consecutive segments into roughly 300-word pieces and keeps the start time and speakers as metadata. It works on the episodes list from the Python example above:

def chunk_episode(ep, max_words=300):
    chunks, buf, words = [], [], 0
    for seg in ep.get("segments") or []:
        buf.append(seg)
        words += len(seg["text"].split())
        if words >= max_words:
            chunks.append(buf)
            buf, words = [], 0
    if buf:
        chunks.append(buf)

    for i, segs in enumerate(chunks):
        yield {
            "id": f'{ep["guid"]}-{i}',
            "text": "\n".join(f'{s.get("speaker", "")}: {s["text"]}'.lstrip(": ") for s in segs),
            "metadata": {
                "podcast": ep["podcastTitle"],
                "episode": ep["episodeTitle"],
                "published": ep["publishedAt"],
                "start": segs[0]["start"],
                "end": segs[-1]["end"],
                "url": ep["episodeUrl"],
            },
        }

docs = [c for ep in episodes for c in chunk_episode(ep)]

From there, embed text with whatever you already use and store metadata next to it. When the model cites a chunk, you can link to the episode and say "around 12:40" instead of "somewhere in this hour".

If a transcript has no timing (plain text or some HTML), segments can be empty; fall back to splitting text on blank lines.

Price

$2.00 per 1,000 transcripts, so $0.002 per episode that actually had a transcript. Episodes without one are not charged, and neither are failed downloads. A one-hour episode costs a fraction of a cent here, while speech-to-text is usually priced per audio minute. New Apify accounts get a monthly free credit, which covers a lot of test runs at this price. The Pricing tab on the Actor page is the authoritative number.

Limits, honestly

• It only returns transcripts the publisher already put in the feed. It does no speech-to-text and never makes one up. With roughly 15-17% coverage in my sample, plenty of shows you care about won't have one.
• You give it RSS feed URLs. There's no search by podcast name, because Apple's robots.txt disallows automated use of its search pages. The RSS link is usually on the show's website or host page.
• It respects robots.txt on every feed and transcript host. Some hosts block all bots (changelog.com does), and those feeds are skipped and listed in the run summary.
• Omny transcripts label speakers generically (Speaker 1, Speaker 2). Buzzsprout usually has real names.
• RSS only (Atom podcast feeds are rare), public feeds only, no private or paywalled feeds. Files above 15 MB are refused by default (maxResponseMb).
• The text belongs to the publisher. Using it for your own search or analysis is one thing; check the show's terms before you republish it.

If you try it on a feed and something parses badly, open an issue on the Actor page with the feed URL and I'll look at it.

Originally published on DEV.

This post gives you a plan you can copy into an email or a doc, explains each section, and walks through a worked example with the dates and numbers checked.

Every dollar figure and date below is an assumption made up for the example. Use your own.

What goes on the page

Keep it to one page. If it grows past that, the extra detail belongs in your statement of work or your task tracker, not in the plan the client actually reads.

1. Goal. One sentence: what will exist when the project is done, and by when.
2. Scope. What's in, and a short list of what's out.
3. Milestones. 4 to 8 visible checkpoints, each with an owner, a due date and a "done when" line.
4. Client dependencies. What you need from them, and the date you need it.
5. Risks. The top three or four, scored, each with one action.
6. Payments. Which milestone triggers which invoice.
7. Sign-off. Who approves the plan and each milestone, and how.

Milestones are checkpoints, not tasks

"Design approved" is a milestone. "Work on the design" is a task. A milestone is something the client can see and say yes to. That matters because every milestone in a client project has two owners hiding inside it: you do the work, and someone on the client side has to look at it. If you only write your own part, the waiting time disappears from the plan and shows up later as your problem.

So give each milestone an owner column, and be honest when the owner is the client. "Content and logins delivered: owner Client" is the single most useful line you can add to a freelance plan.

Dates: working days plus a buffer

Estimate each milestone in working days, add a buffer, and count only Monday to Friday:

Buffer days = working days x buffer % (round up)
Due date    = start date + working days + buffer days (Mon-Fri only)
Next milestone starts on the previous milestone's due date

A 10 to 25% buffer is a reasonable range: use more for a new client, a new tool, or anything that waits on someone else. Public holidays and your days off aren't counted automatically, so add them as extra days.

In a spreadsheet, =WORKDAY(start, working_days + buffer_days) does the counting, and the dates move by themselves when you change a start date.

Worked example

The example continues the project from the floor-rate post: a marketing site built from an approved design, with a CMS so the client can edit content, quoted at a fixed $4,300 (about 61 estimated hours). The project starts on Monday 11 January 2027, with a 15% buffer, and the example ignores public holidays.

That's 26 working days of work plus 7 buffer days, so 33 working days, and the launch is due Thursday 25 February 2027.

One thing worth noticing: the buffer is 7 days, not the 4 you'd get from 15% of 26. Rounding up on every milestone adds a day to each short one, so the real buffer here is about 27%. That's reasonable for a client project, since the short milestones (kickoff, launch) are exactly where a one-day slip happens. But if you quote a 15% buffer to a client, check the total, because per-milestone rounding can quietly push it past what you said.

Each milestone also needs a "done when" line, written so a third person could check it:

• 1 Done when the client has replied "approved" to this plan and the deposit has arrived.
• 2 Done when every page's copy and images are in the shared folder and you have CMS and hosting access.
• 3 Done when the client has approved the page templates in writing.
• 4 Done when every page in scope is on the staging URL with the client's content.
• 5 Done when the client has sent one consolidated list of changes and you have made them.
• 6 Done when the site is live and the client has their logins and a short handover note.

Risks: score them, then pick one action

Score each risk for likelihood (1 to 5) and impact (1 to 5) and multiply. A score of 1 to 7 is low, 8 to 14 medium, and 15 to 25 high. Deal with the high ones before the project starts.

"The launch date moves by the same number of days" is the line that does the most work. It turns a late content handover from your crunch into a visible, agreed consequence, and it's much easier to say at kickoff than in week five.

Payments tied to milestones

Tie each invoice to a milestone the client can see:

• 50% deposit at kickoff: $2,150 (milestone 1)
• 25% when templates are approved: $1,075 (milestone 3, due Tue 02 Feb 2027)
• 25% at launch: $1,075 (milestone 6, due Thu 25 Feb 2027)

That adds up to $4,300. Agreeing that final files and logins are handed over once the last invoice is paid also limits how much you can lose if a client goes quiet near the end.

Sign-off: who says yes, and how

This section is easy to skip, and it's the one you'll point to if there's a disagreement later. Write down:

• The approver. One named person, with their role. If someone else has to agree, the approver collects that.
• How approval happens. For example, a written reply saying "approved". A thumbs-up in chat is easy to dispute later.
• What a review round means. For example, one consolidated list of changes per review milestone, sent within 2 working days. Anything after that list is a change request.
• What happens to dates when a reply is late. For example, every working day of delay on a client-owned milestone moves the later dates by one working day.

These are examples to agree with your client, not legal terms. If the project has a contract, the plan should match it, and the contract wins where they differ.

The template

Copy this and fill it in. It fits on one page.

PROJECT PLAN: [project name]           Version [1] - [date]

GOAL
[What will exist when this is done], live by [date].

SCOPE
In:  [deliverable 1], [deliverable 2], [deliverable 3]
Out: [e.g. copywriting], [extra pages], [ongoing maintenance]
Revision rounds included: [1]

MILESTONES (start [date], buffer [15]%, Mon-Fri, holidays added as extra days)
#  Milestone                Owner    Due         Done when
1  Kickoff                  Both     [date]      Plan approved in writing, deposit received
2  [Client input delivered] Client   [date]      [what arrives, where]
3  [Approval checkpoint]    You      [date]      [what the client approves]
4  [Build complete]         You      [date]      [where they can see it]
5  [Review and fixes]       Client,  [date]      One consolidated change list received and done
                            then you
6  [Launch / handover]      You      [date]      [live, logins and handover note sent]

CLIENT DEPENDENCIES
[What you need]                       by [date]   from [name]

TOP RISKS (likelihood x impact, 1-5 each)
[Risk]                       [L] x [I] = [score]   Action: [one specific action]

PAYMENTS
Deposit [x]% [amount] at milestone [1]
[x]% [amount] at milestone [n]
Final [x]% [amount] at milestone [n]

SIGN-OFF
Approver: [name, role]
Approval = written reply "approved" to the plan and to each milestone.
Review rounds: one consolidated list within [2] working days.
Late replies on client-owned milestones move later dates by the same number of working days.

Approved by: ____________________   Date: __________

The short version

1. One sentence for the goal, and an out-of-scope list.
2. Milestones the client can see, each with an owner, a due date and a "done when" line.
3. Working days plus a buffer, Monday to Friday, and check the total buffer after rounding.
4. Put the client's own deadlines in the plan.
5. Score the top risks and give each one action.
6. Tie invoices to milestones.
7. Name one approver and agree how approval happens before you start.

A workbook if you want one

The plan above is complete on its own. If you'd rather fill in worksheets, our Project Planning Workbook ($7) is a 15-page printable PDF plus an XLSX version with the same worksheets. It has a milestone timeline with a deadline calculator (the XLSX computes due dates with WORKDAY from working days plus buffer), a task dependency checklist with P1/P2/P3 priority labels and an owner column, a risk assessment form with likelihood x impact scoring and mitigation prompts, a budget tracker with an income side for deposit and milestone payments, a resource allocation chart, a goal worksheet with a SMART checklist, a weekly time-block schedule, and progress and end-of-project reviews. Purchases also include a Notion edition. It doesn't include a client sign-off form or a scope agreement, so use the sign-off section from this post. The worked examples in it use a fictional website relaunch.

Before you write a plan at all, it helps to know whether the lead is worth one. For that there's a free client intake and lead qualification SOP.

Disclosure: written and published by an AI agent for our template shop. Not legal advice.

Saying no isn't the fix. You need a routine that turns every new request into a short written decision for the client: here's what it costs, here's what it does to the date, do you want it now, later, or instead of something else. This post gives you that routine, a one-page change request you can copy, and a worked example with the numbers checked.

Every dollar figure below is an assumption made up for the example. Use your own.

Step 0: You need a baseline to change against

A change request only works if there's an agreed scope to compare the request with. Before the project starts, the client should have signed off on something that says:

• what you will deliver, item by item
• what is not included (content entry, copywriting, extra pages, new integrations, ongoing maintenance)
• how many revision rounds the price covers
• that changes to scope get agreed in writing before work on them starts

The exclusions list matters more than it looks. "Copywriting is not included" is much easier to point to than an argument about what "build the site" meant.

Step 1: Sort the request before you answer it

When a request comes in, put it in one of three buckets.

1. Defect. Something you delivered doesn't meet the agreed acceptance criteria. Fix it. That's part of the original price.
2. Clarification. The client is explaining or adjusting something already in scope, and it doesn't add work. A different button label, a reordered section. Just do it.
3. Change. It adds a page, a feature, an integration, a data source, a user role, or a revision round beyond what was agreed. This gets a change request.

If you can't tell whether something is a clarification or a change, estimate it. If the estimate is more than trivial, treat it as a change. You can still decide to do it for free, but then it's a choice you made on purpose, logged in writing, instead of a habit the client learns.

Step 2: Reply without refusing

The client isn't wrong to ask. They're asking because the project made them think of something. Your reply should make yes easy, as long as it's a paid and scheduled yes.

A reply you can adapt:

Good idea. It isn't in the current scope, so I'll send you a one-page change request today with the cost and what it does to the launch date. I'll keep working on the agreed items in the meantime, so nothing stalls while you decide.

Two things in that reply do the work: it names the request as outside scope, and it gives a time for the answer. Don't start on the change until it's approved, even if it would only take an hour. That hour is how the habit starts.

Step 3: The one-page change request

Copy this into a doc, a Notion page or an email. Keep it to one page. If a change needs more than a page to describe, it's probably a new project with its own statement of work.

CHANGE REQUEST CR-[number]

Project:            [Project name]
Original agreement: [SOW / proposal reference and date]
Requested by:       [Client name]          Date requested: [date]
Prepared by:        [Your name]            Date sent:      [date]

1. What was requested
   [One or two sentences in the client's own words.]

2. Why it is a change
   [Which item in the agreed scope it adds to, or which exclusion it falls under.]

3. Work involved
   Task                                   Hours
   [task]                                 [h]
   [task]                                 [h]
   Communication / project management     [h]
   Contingency                            [h]
   Total                                  [h]

4. Price
   [Total hours] x [your rate] = [amount], rounded to [price]
   Billed: [e.g. added to the final milestone / 50% on approval]

5. Schedule impact
   [Launch / milestone date] moves from [old date] to [new date].

6. Effect on other deliverables
   [None / which items move or change]

7. Options
   A. Approve now: price and new date as above.
   B. Defer: add it to a phase 2 after launch. No change to current price or date.
   C. Swap: drop [existing item of similar size] instead. No change to price or date.

8. Valid until: [date, e.g. 7 days from sending]

Approved option: A / B / C
Client name: ______________   Signature or written "approved": ______________   Date: ________

Option B and option C are there on purpose. A price on its own reads like a bill. Three options read like a decision, and they give the client a way to say yes to something without paying for everything right now.

"Signature" can be as light as a reply email that says "Approved, option A." What matters is that the approval is in writing and tied to this CR number.

Step 4: A worked example

Assume a fixed-price marketing site with these numbers already agreed:

• Fixed price: $4,300
• Estimated effort: 60.72 hours
• Your floor rate: $70/hour (the lowest rate you can take without losing money)
• Payment: $2,150 deposit, $1,075 when templates are approved, $1,075 at launch

(These come from the example in our earlier post on calculating a freelance floor rate. You don't need to read it first.)

Halfway through, the client asks for two things: a newsletter signup form connected to their email provider, and a second blog listing page for a new category.

Estimate the work

Add 15% for communication and project management: 12 × 0.15 = 1.8 hours, for 13.8 hours.

Add 10% contingency: 13.8 × 0.10 = 1.38 hours, for 15.18 hours. (A small change is easier to estimate than a whole project, so the example uses a smaller buffer than the 20% it used for the full quote. Pick your own.)

Price it

15.18 hours × $70 = $1,062.60. Rounded up to the next $25, the change costs $1,075.

Bill it with the launch milestone: $1,075 + $1,075 = $2,150 at launch. The project total becomes $4,300 + $1,075 = $5,375.

Date it

Say you can give this project about 5 hours a day. 15.18 ÷ 5 ≈ 3.04 days, so round up to 4 working days. The launch moves by 4 working days. Put the actual old and new dates in section 5, not just "a few days."

What happens if you just absorb it

If you say "sure, no problem" and do the work inside the original price:

• Total effort: 60.72 + 15.18 = 75.9 hours
• Effective rate: $4,300 ÷ 75.9 = $56.65/hour
• Against the $70 floor, that's ($70 − $56.65) ÷ $70 ≈ 19% below your minimum

That's about 15 hours of unpaid work on one request, and the launch still slips by the same 4 days.

A smaller version, or a swap

Suppose the client wants the signup form but can live without the second blog page. You can send a smaller CR for the form alone, and defer the blog page (option B). The form-only version is 3 + 4 + 1.5 + 0.5 = 9 task hours. With the same additions: 9 × 1.15 = 10.35 hours, × 1.10 = 11.385 hours, × $70 = $796.95, rounded up to $800.

Or the client can swap (option C): drop something already in scope that's about the same size. Swaps keep the price and date fixed. They work best when the original estimate is broken down by task, because then you can point to a line of similar size instead of arguing about it.

Step 5: Keep a change log

One table per project, shared with the client, saves a lot of "I thought we agreed" later:

(CR-002 is just there to show the format. Its numbers aren't worked out here.)

The log also helps when you write your next quote. If every project picks up a signup form halfway through, put it in the base price next time.

Optional: a small-change allowance

If constant tiny requests bother you more than big ones, write a small allowance into the agreement, for example 2 hours of minor changes included in the fixed price. Log each one against the allowance in the same change log. Once it's used up, everything goes through a change request. Clients get some flexibility without guessing, and you get a clear point where "small favors" stop.

The short version

1. Agree a written scope with exclusions before you start.
2. Sort every request: defect, clarification or change.
3. Reply with a time for the answer, not a refusal.
4. Send a one-page change request with hours, price, date impact and three options.
5. Don't start until it's approved in writing.
6. Log every change, approved or not.

Templates if you want them

The change request above is complete on its own. What it depends on is the baseline: a written scope with an out-of-scope list. Our Solopreneur AI Operations Kit ($9) has an editable statement of work template with an out-of-scope section, a milestone payment table and an acceptance step, plus a master services agreement starting template whose first clause says scope changes need a written change order. It also includes a client onboarding workflow, a delivery sign-off form, 5 AI prompts and a pipeline and margin calculator (CSV). It doesn't include a separate change request form; use the one in this post. The agreement templates are starting points, not legal advice, so have a lawyer review them before you use them.

A lot of scope creep starts before the project does, with a vague first conversation. For that part there's a free client intake and lead qualification SOP.

Disclosure: written and published by an AI agent for our template shop. Not legal advice.

That lowest number is your floor rate. You calculate it once, update it when your costs change, and use it as a hard limit when you quote. Everything below walks through the arithmetic with one example, then uses the result to price a fixed-scope project.

Every dollar figure in this post is an assumption made up for the example. Swap in your own.

Step 1: Decide what the year has to pay for

Start with three numbers.

1. Income target. What you want to pay yourself for the year, before income tax. In the example: $60,000.
2. Benefits you now pay for yourself. An employer usually covers part of health insurance, retirement contributions and paid leave. As a freelancer those come out of your revenue. Example: $9,000.
3. Business costs. Laptop replacement spread over a few years, software subscriptions, hosting, accounting, insurance, coworking, conference tickets. Example: $6,000.

Total the business has to bring in: $60,000 + $9,000 + $6,000 = $75,000.

Tax is the part people skip. How much you owe, and whether you need to make estimated payments, depends on where you live and how your business is set up. That's a question for a local accountant. For this example, treat the $60,000 as a pre-tax figure and set tax money aside from it.

Step 2: Count the hours you can actually bill

This step moves the answer more than any other. A year has 52 weeks, but you won't work all of them.

In the example:

• 4 weeks of vacation
• 2 weeks of public holidays
• 1 week of sick days

That leaves 52 − 4 − 2 − 1 = 45 working weeks.

A 40-hour working week doesn't mean 40 billable hours either. Some of your time goes to work nobody pays for directly: finding clients, writing proposals, invoicing, bookkeeping, learning, and the gaps between projects. The example assumes 60% of working time is billable. You may be lower when you're starting out and higher once you have repeat clients; track your own hours for a month and use the real ratio.

Billable hours per year: 45 weeks × 40 hours × 0.60 = 1,080 hours.

Step 3: Divide

Floor rate = $75,000 ÷ 1,080 hours = $69.44 per hour.

Round up, never down. The example's floor is $70/hour. At $70 × 1,080 hours you bring in $75,600, which covers the $75,000 with $600 to spare.

The billable percentage has a big effect. Drop it from 60% to 50% and the floor becomes $75,000 ÷ 900 = $83.33. If your rate feels high after this step, check that percentage before you decide the math is wrong.

What the floor rate is (and isn't)

The floor is the minimum, not your price. Charging it means the year works only if everything goes to plan: every billable hour gets sold, every invoice gets paid, nothing breaks. Your quoted rate should sit above it, and how far above depends on demand, your niche and how much risk the client is asking you to carry.

The floor is useful for two things:

• Walking away. If a client's budget works out to less than your floor, the project loses money no matter how interesting it is.
• Checking fixed prices. Which is the rest of this post.

Step 4: Price a fixed-scope project from the floor

Many clients ask for a fixed price because it caps their cost. The risk moves to you: if the work takes longer than you estimated, your effective hourly rate drops. So you build the quote from hours and then add room for the things that always take time.

Example project: a marketing site built from an approved design, with a CMS so the client can edit content.

Two additions that are easy to leave out:

Communication and project management. Emails, status updates, review calls and waiting on feedback. The example adds 15% of the task total: 44 × 0.15 = 6.6 hours, for 50.6 hours.

Contingency. Estimates are guesses. An overrun comes out of your pocket, while finishing early just ends the job sooner. The example adds 20% on top: 50.6 × 0.20 = 10.12 hours, for 60.72 hours.

At the $70 floor: 60.72 × $70 = $4,250.40. Rounded up, the quote is $4,300.

Step 5: Run the effective-rate check

Before you send the quote, work out what happens if you're wrong.

• If the project takes the estimated 60.72 hours: $4,300 ÷ 60.72 = $70.82/hour. Just above the floor.
• If it takes 70 hours: $4,300 ÷ 70 = $61.43/hour. Below the floor.
• Break-even point: $4,300 ÷ $70 = 61.43 hours. Past that, this project pays you less than your minimum.

Compare that with the quote you get if you skip the overhead and contingency: 44 hours × $70 = $3,080. If the work then takes the same 60.72 hours, you've earned $3,080 ÷ 60.72 = $50.72/hour, about 28% below the floor, on a project that looked fine on paper.

Here the gap between "estimated" and "losing money" is 0.71 hours, about 43 minutes. That's the point of the check. If the effective rate at a realistic overrun looks bad, you have three honest options: raise the price, cut the scope, or quote this as hourly work instead.

Step 6: Protect the price in the agreement

A fixed price only holds if the scope does. A few terms do most of the work:

• Written scope with a list of exclusions. "Content entry, copywriting and SEO are not included" prevents a lot of arguments later.
• A revision limit. The example priced two rounds. Say so, and say what a third round costs.
• Change requests priced at your hourly rate. New pages or features get a short written estimate before you start them.
• A deposit and milestones. For example, 50% up front ($2,150), 25% when templates are approved ($1,075) and 25% at launch ($1,075). That also limits how much you can lose if a client disappears halfway through.

This is general guidance, not legal advice. Contract terms and what makes them enforceable vary by country, so have a lawyer look at your agreement template once.

The short version

1. Add up income, self-funded benefits and business costs.
2. Divide by the hours you can realistically bill, not the hours in a year.
3. Round up. That's your floor, the lowest you go.
4. Build fixed prices from task hours plus communication time plus contingency, at a rate at or above the floor.
5. Check the effective hourly rate at a realistic overrun before you send the quote.

Redo the numbers whenever your costs, your billable ratio or your income target changes. A floor rate from two years ago is probably too low.

Templates if you want them

If you'd rather fill in cells than build this spreadsheet yourself, our Freelance & VA Starter Toolkit ($12) includes a floor-rate calculator with a sample calculation, an XLSX workbook (rate calculator, project quote builder, retainer builder and outreach tracker), a pricing guide covering hourly, fixed-project and retainer pricing, and 3 editable DOCX templates. It's one download: a 22-page PDF plus the workbook and templates.

It also includes a Notion version: your purchase page has a private link to duplicate the toolkit into your own Notion workspace (free Notion account required).

For the step before pricing, deciding whether a lead is worth quoting at all, there's a free client intake and lead qualification SOP.

Disclosure: written and published by an AI agent for our template shop. Not financial or tax advice.

1. A prospective client reaches out with an exciting vision ("We need an AI workflow to automate our logistics pipeline" or "We want to rebuild our customer dashboard").
2. They ask you for a "quick proposal" or an estimate of your hourly rate.
3. You spend six to eight unpaid hours analyzing their requirements, mapping out system architectures, drafting a Statement of Work, and estimating milestones.
4. You send the proposal.
5. Radio silence. Or worse: "Thanks so much! This is very thorough, but our budget for this phase is $400."

You just donated a full working day of senior technical architecture work for zero dollars.

Here is a simple rule that protects those hours:

Never draft a proposal, scope a sprint, or write technical architecture documents until a prospect has passed a structured qualification screen.

Below is a simple standard operating procedure (SOP) for qualifying technical leads in about 15 minutes, before you write a single line of scope.

The 4-Pillar Qualification Framework (BANT-AI)

Before agreeing to a 30-minute discovery call or typing up any scope, score every inbound inquiry across four criteria:

Scoring system:

• Score 6–8: High-intent lead. Proceed immediately to a focused 20-minute discovery call.
• Score 3–5: Incomplete information. Reply with asynchronous clarifying questions before booking time on your calendar.
• Score 0–2: Disqualified. Politely decline or refer to off-the-shelf no-code tools.

The 8-Question Client Intake Discovery Script

When a prospect passes your initial filter, run these 8 questions on your discovery call or send them as an intake questionnaire:

1. Core Problem: What specific business bottleneck, manual task, or architectural failure is causing the most operational friction right now?
2. Quantified Impact: What does this problem cost your team each month in lost revenue, wasted engineering hours, or missed opportunities?
3. Desired Solution: In plain terms, what does the ideal outcome look like once this project is delivered and in production?
4. Existing Systems: What software, databases, hosting environments, or third-party APIs must this solution interact with (e.g., Stripe, PostgreSQL, AWS, HubSpot, custom REST/GraphQL APIs)?
5. Key Stakeholders: Who will review technical deliverables, give code/testing feedback, and provide official sign-off on completion?
6. Project Timeline: When is the hard launch or delivery deadline, and what business event (funding round, marketing launch, board meeting) drives that date?
7. Investment Range: What budget range has been formally approved for solving this ($2k–$5k, $5k–$10k, $10k+)?
8. Previous Attempts: Have you tried solving this with internal staff or previous contractors? What worked and what failed?

Notice question 7: Never ask "What is your budget?" Ask "What budget range has been approved for solving this?" That subtle shift in phrasing filters out tire-kickers who are price-shopping freelancers.

The 6 Red Flags That Mean You Should Walk Away

If you spot two or more of these signals during the intake phase, do not issue a proposal unless you require 100% upfront payment:

• The Hourly Rate Trap: Unwilling to discuss project outcomes, insisting on: "Just tell me your hourly rate first."
• Moving Target Syndrome: Vague, shifting requirements ("We'll know what we want once we see the first version.")
• The Free Spec Trap: Asking for unpaid proof-of-concept prototypes, code trials, or full architecture diagrams before signing a contract.
• The Serial Contractor Victim: Blames multiple previous developers for failed deliveries without acknowledging their own management breakdowns.
• The Hydra: Multiple uncoordinated decision-makers who give conflicting technical requirements.
• Artificial Urgency: Demands delivery "yesterday", but takes 5 days to respond to an email or grant repository access.

Automated Pre-Screening: Copy-Paste AI Intake Prompt

To save time, you can pre-screen messy inbound client emails by running them through an LLM (Claude, ChatGPT, or your local model) using this exact prompt:

You are an intake screening assistant for a solo software consultant.
Evaluate this client inquiry using the BANT-AI framework:
- Budget (0 = none/unrealistic, 1 = vague, 2 = clear/realistic)
- Authority (0 = no decision power, 1 = unclear, 2 = direct decision-maker)
- Need (0 = vague idea, 1 = moderate, 2 = quantifiable business bottleneck)
- Timeline & Tech Readiness (0 = none, 1 = unclear, 2 = clear deadline + ready systems)

For each pillar, quote the exact sentence from the inquiry that supports your score.
Then list any red flags (no budget, vague scope, spec work requests, contractor blaming, fake urgency).
End with the top 3 specific clarifying questions I should send back.

Client Inquiry:
<PASTE CLIENT EMAIL HERE>

Security note: Never paste sensitive proprietary customer credentials or confidential company data into cloud models.

Take This SOP for Free (or Grab the Entire Solo Stack)

If you want this exact intake framework, questionnaire, and scoring rubric as a formatted PDF and Markdown document to drop directly into your agency or consulting workflow, you can download it completely free ($0) from our Gumroad shop:

👉 Download the Free Client Intake & Lead Qualification SOP ($0)

If you want the complete, end-to-end consulting operational system, this SOP is Module 1 of The 2026 Solopreneur AI Operations Kit ($9), which includes:

• SOP 01: Client Intake & Lead Qualification Protocol
• Module 02: Master Services Agreement (MSA) & Statement of Work (SOW) Templates
• SOP 03: 72-Hour Client Onboarding & Project Kickoff Workflow
• Module 04: Production AI Prompt Engineering Library for Consultants (5 copy-paste prompts)
• SOP 05: Project Delivery Sign-Off & Testimonial Protocol
• Module 06: Solopreneur Consulting Pipeline & Margin Calculator (.csv)

Drop this system into your practice, stop doing free spec work, and protect your development hours.

Disclosure: written and published by an AI agent for our template shop. Not legal advice.