DEV Community: FreeTier

Writing Freelance Client Proposals That Get Signed

FreeTier — Sat, 17 Oct 2026 04:09:28 +0000

Disclosure: this post was written with AI assistance and reviewed before publishing.

A proposal is not a CV and not a brochure. It's a short document that answers one question for the client: "If I say yes, what exactly happens, and why is it worth the money?" Freelancers who win consistently tend to use the same structure every time and adapt only the details. Here's a structure that works for most service work, from design and development to writing and consulting.

Before you write: qualify and listen

The proposal is mostly decided before you open a document. On the first call, try to learn:

The problem in the client's words. Write down their exact phrases; you'll reuse them.
Why now. What triggered the project? A launch, a deadline, a failed previous attempt?
What success looks like. A number, a date, a feeling ("we stop losing leads").
Budget range. Ask directly: "Do you have a range in mind?" Many clients will answer.
Who decides. If someone else signs off, your proposal must make sense to them without you in the room.

If the fit is poor, it's fine to decline before writing anything. Proposals take time.

The seven sections

Summary of the situation. Two or three sentences restating the problem using the client's language. This shows you listened, which is often the main thing clients are judging.
Goals. What the project should achieve, ideally measurable.
Approach. How you'll do it, in phases. Keep it understandable to a non-expert.
Scope and deliverables. A clear list of what is included — and a short list of what is not. The exclusions prevent most later disputes.
Timeline. Milestones with dates or week numbers, including what you need from the client and when.
Investment. Price and payment terms.
Next step. Exactly how to say yes: sign, reply, pay a deposit.

Two pages is enough for most projects. Long proposals are rarely read more carefully; they're just skimmed for the price.

Pricing: offer options

Presenting two or three options often works better than a single number, because the conversation shifts from "yes or no" to "which one". A common pattern:

Essential — solves the core problem.
Recommended — the core plus the things that usually make the biggest difference.
Complete — everything, including ongoing support.

Make sure each option has a clear difference in outcome, not just in hours. Use fixed prices per option where you can estimate reliably; it's easier for clients to approve.

Payment terms and protection

State terms plainly:

Deposit before work starts (25–50% is common for new clients)
Remaining payments tied to milestones, not dates
Number of revision rounds included
What happens if the client delays feedback
How long the proposal is valid

A proposal isn't always a contract. For larger projects, use a proper written agreement as well, and get local legal advice if the stakes are high.

Writing style

Use "you" more than "I". The proposal is about the client's result.
Replace jargon with plain outcomes: "Pages load in under two seconds" instead of "performance optimisation".
Include one or two short, relevant examples of past work rather than a full portfolio.
Keep formatting simple: headings, short paragraphs, a table for options.

A reusable template skeleton

Project: [Name]  |  Prepared for: [Client]  |  Valid until: [Date]

1. Where you are now
2. What we'll achieve
3. How we'll get there (Phase 1 / 2 / 3)
4. Included / Not included
5. Timeline and what I need from you
6. Investment (Option A / B / C) and payment terms
7. Next step: reply "yes" with your chosen option and I'll send the agreement and deposit invoice.

Follow up

Send the proposal, then follow up. A short note two or three working days later ("Any questions about the options?") is normal and expected. If there's no answer after a second follow-up, ask whether the project is still a priority — it gives the client an easy way to say no, which saves you time.

Summary

Listen first, restate the problem in the client's words, use a consistent seven-section structure, offer two or three priced options, be explicit about scope and terms, and make the next step obvious. Consistency is what lets you write good proposals quickly.

If you'd rather start from a ready-made structure, I put together a small, inexpensive, AI-assisted kit on this topic: Client proposal templates. There's a *free sample** (the intro plus one complete template), so you can check whether it's useful before paying anything. Everything above works without it. Other kits: all products.*

How to Write SOPs and Checklists People Actually Follow

FreeTier — Sat, 17 Oct 2026 04:09:07 +0000

Disclosure: this post was written with AI assistance and reviewed before publishing.

Most standard operating procedures die the same way: someone writes a long document, saves it in a shared drive, and nobody opens it again. The problem is rarely the idea of documenting a process. It's that the document is built for the writer, not for the person doing the task at 4 pm on a Friday. Here's a practical way to write SOPs and checklists that get used.

Decide what deserves an SOP

Not everything does. Good candidates share at least one of these traits:

Repeated at least monthly
Costly when wrong (payroll, client deliverables, publishing, backups)
Done by more than one person, or likely to be handed over
Easy to forget a step because it's done rarely (year-end tasks, onboarding)

Make a quick list of your recurring tasks and score each from 1–3 on frequency and risk. Document the highest scores first.

Checklist or SOP?

These are different tools:

A checklist is a short list of steps for someone who already knows how to do the task. It prevents skipped steps. Think pilot pre-flight lists.
An SOP explains how and why for someone learning the task. It includes context, screenshots and decisions.

Often you need both: an SOP for training, and a one-screen checklist extracted from it for daily use.

A structure that works

Keep every SOP in the same format so people know where to look:

Title and purpose — one sentence: what this achieves.
Owner and last reviewed date — so people know if it's current.
When to use it — the trigger ("When a new client signs").
What you need — tools, access, files.
Steps — numbered, one action per step, starting with a verb.
Definition of done — how you know it's finished correctly.
Common problems — the two or three things that usually go wrong.

Writing the steps

The steps are where most SOPs fail. A few rules:

One action per step. "Export the report and send it to finance" is two steps.
Start with a verb. "Open", "Copy", "Check", "Send".
Be specific about where. "In Settings → Billing, click Export" beats "export the billing data".
Mark decision points clearly. "If the invoice is over €1,000, go to step 9; otherwise continue."
Add a screenshot only where the interface is confusing. Screenshots go out of date fast.

Test it on someone else

The best quality check is to hand the SOP to someone who has never done the task and watch, without helping. Every time they hesitate or ask a question, the document has a gap. Fix it, then repeat with another person if you can. Two rounds usually catch the major problems.

Example: a short publishing checklist

Before publishing a blog post
[ ] Title under 60 characters
[ ] One clear primary keyword in title and first paragraph
[ ] All links tested
[ ] Images have alt text and are compressed
[ ] Meta description written
[ ] Spelling check run
[ ] Author and category set
[ ] Preview checked on mobile

Eight items, one screen, no explanation needed — because the explanation lives in the full SOP.

Keeping SOPs alive

Documentation decays. Build in maintenance:

Review date on every document; review high-risk ones quarterly.
Change on contact. Whoever notices a step is wrong updates it immediately (or flags it).
Single source of truth. Link to the SOP rather than pasting copies into chats.
Put it where the work happens. Link the checklist from the project template, ticket type or calendar event that triggers the task.

Common mistakes

Writing an SOP for a process that hasn't stabilised yet. Run it a few times first.
Documenting the ideal process instead of the real one.
Burying critical warnings in paragraphs. Put them right before the step they apply to.
Making it too long. If an SOP passes two pages, split it.

Summary

Pick the processes that are frequent or risky, separate checklists from SOPs, use a consistent seven-part structure, write one verb-led action per step, test with a newcomer and schedule reviews. Short, current and easy to find beats complete and forgotten.

If you'd rather start from a ready-made structure, I put together a small, inexpensive, AI-assisted kit on this topic: Checklist and SOP packs. There's a *free sample** (the intro plus one complete template), so you can check whether it's useful before paying anything. Everything above works without it. Other kits: all products.*

Building a Social Media Content Calendar Around Hooks (Not Just Dates)

FreeTier — Sat, 17 Oct 2026 00:08:24 +0000

Disclosure: this post was written with AI assistance and reviewed before publishing.

A typical content calendar answers "when do we post?". A more useful one also answers "why will anyone stop scrolling?". The first line or first second of a post — the hook — does most of the work in a crowded feed. Here's how to build a calendar that plans hooks, topics and formats together, so you're never staring at a blank box at 9 am.

The building blocks

A workable calendar needs four things per post:

Pillar — the broad theme the post belongs to
Topic — the specific idea
Hook — the opening line or visual
Format — text, carousel, short video, thread, image

Everything else (captions, hashtags, assets) is detail you can add later.

Step 1: Choose three to five content pillars

Pillars are the recurring themes your audience follows you for. For a freelance designer, for example:

Design process (how work gets made)
Client lessons (stories and mistakes)
Tools and resources
Behind the scenes
Offers (what you sell)

Rotating pillars keeps content varied without needing new ideas every day. Keep promotional posts a minority; a common guideline is no more than one in five.

Step 2: Build a hook bank

Instead of inventing hooks per post, collect patterns. Some that reliably work across platforms:

Specific result: "How I cut client revisions from five rounds to two."
Mistake: "The pricing mistake I made for three years."
Contrarian: "You don't need a content calendar. You need a hook bank."
List: "7 free tools I use every week."
Question: "Why do most portfolios get ignored?"
Before/after: "Our onboarding email, before and after."
Story opener: "A client emailed me at 11 pm with one sentence."

Write 30–50 hooks in a document, tagged by pillar. When planning, pick hooks first and fit topics to them. It sounds backwards, but it produces more engaging posts.

Keep hooks honest. A hook that promises something the post doesn't deliver may get clicks once and cost trust permanently.

Step 3: Set a realistic cadence

Consistency beats volume. Three good posts a week on one platform is more sustainable than daily posting across four. Choose:

One primary platform where your audience is
A cadence you can keep for three months even when busy
Fixed slots, e.g. Tuesday educational, Thursday story, Saturday resource

Step 4: Lay out the calendar

A spreadsheet or Notion database works well. Suggested columns:

Date	Platform	Pillar	Hook	Topic/notes	Format	Status	Link	Result

Statuses: Idea → Drafted → Ready → Scheduled → Posted. Filter by status to see what needs work.

Plan two to four weeks ahead, and leave around 20% of slots open for timely topics.

Step 5: Batch the work

Batching reduces the cost of context-switching:

Planning (monthly, 1 hour): choose topics and hooks for the next month.
Writing (weekly, 1–2 hours): draft all posts for the week.
Creating assets (weekly): images, carousels, short videos.
Scheduling: use the platform's native scheduler or a scheduling tool.

Step 6: Review what worked

Once a month, look at results per pillar and per hook type. Platform analytics show reach, saves, shares and comments. Questions to ask:

Which hook patterns consistently performed above your average?
Which pillar gets saves (useful) versus likes (entertaining)?
Which posts led to profile visits, sign-ups or messages?

Do more of what works, and retire hook patterns that keep underperforming.

Repurposing

One strong idea can become several posts: a thread, a carousel, a short video and a newsletter section. Add a "repurpose" column in the calendar to track which ideas have already been adapted.

Summary

Define three to five pillars, build a bank of honest, reusable hooks, set a cadence you can sustain, track every post with pillar, hook, format and status, batch the work and review monthly. Planning hooks, not just dates, is what turns a calendar into a content system.

If you'd rather start from a ready-made structure, I put together a small, inexpensive, AI-assisted kit on this topic: Social media content calendars with hooks. There's a *free sample** (the intro plus one complete template), so you can check whether it's useful before paying anything. Everything above works without it. Other kits: all products.*

Spreadsheet Automation Without Code: Five Patterns That Save Hours Every Week

FreeTier — Sat, 17 Oct 2026 00:08:19 +0000

Disclosure: this post was written with AI assistance and reviewed before publishing.

Most people use spreadsheets as digital paper: type numbers in, eyeball them, copy them somewhere else. Both Google Sheets and Excel can do far more of that work for you, and you don't need to write a script to get most of the benefit. Below are five patterns that cover the bulk of repetitive spreadsheet work, with the exact functions to use.

1. Keep raw data and reports on separate tabs

The single most useful habit is structural, not technical. Put every raw record on one tab (call it Data) with one row per event: one sale, one expense, one task. Never add totals or colours there. Build every summary on another tab that reads from Data.

Why it matters: once raw data is clean and append-only, every report can be generated by formulas, and adding a new month means pasting rows, not rebuilding sheets.

A good Data tab has:

One header row, no merged cells
One column per field (Date, Category, Amount, Client, Status)
Consistent types: real dates, real numbers, no "approx 40"

2. Use FILTER and QUERY instead of copy-paste

If you find yourself copying rows that match a condition into another tab, stop. In Google Sheets:

=FILTER(Data!A2:E, Data!D2:D="Acme")

returns every row for one client and updates automatically. Excel 365 has the same FILTER function.

Google Sheets also has QUERY, which lets you write something close to SQL:

=QUERY(Data!A1:E, "select C, sum(D) where A >= date '2026-01-01' group by C label sum(D) 'Total'", 1)

That one formula produces a category-by-total summary that never needs manual updating. In Excel, a PivotTable or GROUPBY (in recent Microsoft 365 builds) does the same job.

3. Validate inputs so errors never get in

Automation breaks on dirty data. Data validation is the cheapest fix:

Dropdowns for categories and statuses (Data → Data validation → Dropdown). This stops "Marketing", "marketing" and "Mktg" from becoming three categories.
Date-only rules on date columns.
Number ranges on amounts (e.g. greater than 0).

Pair it with conditional formatting that highlights blanks in required columns, and you'll spot gaps before they reach a report.

4. Let lookups do the joining

When two tables share a key (a client ID, a product SKU), use a lookup instead of retyping. XLOOKUP works in both Excel 365 and Google Sheets:

=XLOOKUP(B2, Clients!A:A, Clients!C:C, "not found")

This pulls the client's rate into your time log. Change the rate once in Clients and every dependent cell updates. If you're on older Excel, INDEX/MATCH does the same thing.

For whole columns at once in Google Sheets, wrap formulas in ARRAYFORMULA so new rows are calculated automatically without dragging formulas down.

5. Automate the triggers, not just the maths

Formulas handle calculation. For actions — "email me when a status changes", "copy form responses into my tracker" — you have no-code options:

Google Forms → Sheets writes each response as a new row with zero setup. Use a form as the input screen for your Data tab.
Notifications: Google Sheets can email you when changes are made (Tools → Notification settings).
Integration tools such as Zapier, Make or Power Automate can watch for new rows and trigger emails, Slack messages or invoices. Free tiers are limited, so automate the one workflow that hurts most first.

When you do outgrow no-code, Google Apps Script and Excel's Office Scripts let you add small scripts, but many people never need to.

A starter setup in 30 minutes

Create a Data tab with clean headers and validation.
Create a Lists tab holding your dropdown values.
Create a Summary tab with one QUERY or PivotTable per question you actually ask ("How much did I spend per category this month?").
Add conditional formatting for missing values.
Connect a form if anyone else enters data.

Common mistakes

Merged cells and multi-row headers — they break filters, pivots and queries.
Hard-coding numbers inside formulas (=B2*0.25). Put the tax rate in its own cell and reference it.
Building one giant formula. Use helper columns; they're easier to debug.
No backup before big changes. Use version history (File → Version history) before restructuring.

Summary

Separate raw data from reports, replace copy-paste with FILTER/QUERY, validate inputs, use XLOOKUP for joins, and hand triggers to forms or an integration tool. Those five patterns remove most of the manual work from a typical spreadsheet without a single line of code.

If you'd rather start from a ready-made structure, I put together a small, inexpensive, AI-assisted kit on this topic: Spreadsheet automation kits. There's a *free sample** (the intro plus one complete template), so you can check whether it's useful before paying anything. Everything above works without it. Other kits: all products.*

A Simple SEO Audit You Can Run on Your Own Site in an Afternoon

FreeTier — Fri, 16 Oct 2026 20:04:39 +0000

Disclosure: this post was written with AI assistance.

You don't need an expensive tool to find the problems that hold back most small sites. A focused audit with free tools covers the issues that matter: can search engines reach your pages, do they understand them, and do they work well for visitors? Set aside three to four hours, open a spreadsheet, and work through these steps in order.

What you need

Google Search Console (free) verified for your domain. Bing Webmaster Tools is also worth adding.
PageSpeed Insights (free, web-based).
A crawler such as Screaming Frog SEO Spider (free up to 500 URLs) or a similar tool.
A spreadsheet with columns: Issue, URL(s), Severity (high/medium/low), Fix, Done.

Log everything in the spreadsheet as you go. The audit is only useful if it turns into a fix list.

1. Indexing: can Google see your pages?

In Search Console, open Pages under Indexing. Look at:

Not indexed reasons. "Crawled – currently not indexed" on important pages often signals thin or duplicate content. "Excluded by noindex tag" on pages you want found is a mistake to fix immediately.
Your sitemap under Sitemaps. Is it submitted, and does the number of discovered URLs roughly match the number of pages you care about?

Then visit yoursite.com/robots.txt. Make sure it doesn't block important sections. A stray Disallow: / left over from a staging site is a surprisingly common disaster.

Finally, search site:yoursite.com in Google for a rough sense of what's indexed. It's not exact, but big gaps are a warning.

2. Crawl the site

Run your crawler on the homepage and let it finish. Then filter for:

Broken internal links (4xx): fix the link or redirect the old URL.
Redirect chains: A → B → C should become A → C.
Server errors (5xx): take these to your host or developer.
Orphan pages: important pages with no internal links pointing to them. Link them from relevant pages.

3. Titles and meta descriptions

Export page titles and meta descriptions from the crawl. Check for:

Missing or duplicate titles. Every page needs a unique title describing its content, with the main topic near the start. Roughly 50–60 characters avoids most truncation.
Missing or duplicate meta descriptions. They don't directly affect rankings, but they influence whether people click. Write a plain one- or two-sentence summary for key pages.
One clear H1 per page that matches the page's purpose.

Forget about "keyword density". Write naturally for a reader, and make sure the page clearly covers the topic someone searching would expect.

4. Duplicate and thin content

Look for pages with near-identical content: tag archives, printer versions, URL parameters, or http/https and www/non-www versions that all load. Each page should have one main version. Use redirects or a canonical tag pointing to the preferred URL.

Thin pages with a few sentences and no real purpose are better merged into a stronger page or improved. Quality matters more than quantity.

5. Speed and Core Web Vitals

In Search Console, open Core Web Vitals to see field data from real users, grouped by page type. Then test a few key templates (homepage, a typical article, a product page) in PageSpeed Insights. Focus on the three metrics:

LCP (Largest Contentful Paint): main content should appear within about 2.5 seconds.
INP (Interaction to Next Paint): the page should respond to taps and clicks quickly, under about 200 ms.
CLS (Cumulative Layout Shift): content shouldn't jump around while loading.

Don't chase a perfect lab score. Common, high-impact fixes are compressing and correctly sizing images, lazy-loading images below the fold, reducing third-party scripts, and using caching.

6. Mobile and HTTPS

Open your key pages on an actual phone. Is text readable without zooming? Are buttons easy to tap? Do menus work? Google primarily uses the mobile version of pages for indexing.

Check that every page loads over HTTPS, that http:// redirects to https://, and that there are no mixed-content warnings in the browser console.

7. Structured data (optional but useful)

If you have articles, products, recipes, events or FAQs, check whether your pages include structured data. Test a few URLs with Google's Rich Results Test. Fix errors, but don't add markup for content that isn't actually on the page.

8. Look at performance data

In Search Console's Performance report, sort queries by impressions over the last three months. Look for:

Queries with many impressions but a low click-through rate: improve the title and description.
Pages ranking in positions 8–20: often the best candidates to improve with better content and internal links.

Prioritise the fix list

Sort your spreadsheet by severity:

High: indexing blocks, noindex mistakes, broken key pages, site-wide HTTPS problems.
Medium: duplicate titles, redirect chains, slow templates, orphan pages.
Low: missing descriptions on minor pages, small structured-data warnings.

Fix the highs this week. Schedule the rest.

Common mistakes

Auditing without making a fix list.
Obsessing over tool scores instead of real user data.
Making many changes at once, so you can't tell what helped.
Expecting instant results: changes can take weeks to show in search.

Summary

Check indexing, crawl for broken links and duplicates, clean up titles, test speed with real-user data, verify mobile and HTTPS, and use your performance report to find quick wins. Repeat the audit every three to six months.

If you want a starting structure instead of a blank page, I put together a small, inexpensive, AI-assisted kit on this topic: SEO audit templates. Everything above works without it. Other kits: all products.

Growing a Newsletter From Zero: What Actually Works in the First 1,000 Subscribers

FreeTier — Fri, 16 Oct 2026 19:59:44 +0000

Disclosure: this post was written with AI assistance.

The first thousand subscribers are the hardest, and most growth advice is written by people who are well past them. Tactics that work at 50,000 subscribers, such as paid acquisition, referral programmes and sponsorship swaps, rarely make sense at 40. Here's what tends to work early, and what to skip.

Decide who it's for in one sentence

"A weekly newsletter about productivity" competes with thousands of others. "A weekly email for solo accountants about tools and workflows that save time at month-end" has an obvious reader. Write a sentence in this form:

Every [frequency], [type of reader] gets [specific thing] so they can [outcome].

If you can't name where these readers already hang out online, narrow it again.

Pick a platform and stop thinking about it

Substack, Beehiiv, Buttondown, Kit (formerly ConvertKit), Ghost and MailerLite all handle the basics: signup forms, archives and sending. Pick one with a free tier that lets you export your list. Your subscribers are the asset; the platform isn't. Spend no more than an evening on this decision.

Publish a consistent schedule you can actually keep

Consistency matters more than frequency. A useful fortnightly issue beats a rushed weekly one that skips weeks. Before launching, write three issues in advance. They give you a buffer and prove the format works.

A simple, repeatable format helps:

One main piece (a lesson, analysis or how-to)
Three to five curated links with one sentence on why each matters
One question for readers

Your first 100: people you already know

Early subscribers almost always come from existing relationships:

Tell colleagues, former clients and peers individually, not with a mass email. A personal message with one sentence on why it might help them works far better.
Add the link to your email signature, social profiles and personal website.
Post the first issue in communities where you're already a participant, if the rules allow it.

Don't add people to your list without asking. Besides being bad practice, in many countries it's illegal.

100 to 1,000: make issues worth sharing

Growth after the first hundred mostly comes from the content itself being found or forwarded.

Publish the archive publicly. Every issue becomes a web page that can be found by search and linked. Give each one a descriptive title, not "Issue #7".

Repurpose the best issue each month. Turn it into a post on a platform where your readers already are, such as LinkedIn, Dev.to, Medium or a niche forum, with a short line at the end inviting people to subscribe. Write it natively for that platform; don't paste a link and leave.

Make something referable. A checklist, a tool comparison, a salary survey for your niche, a curated directory. Reference material gets bookmarked and linked months later. This is the closest thing to compounding growth for small newsletters.

Ask readers directly. Once every few issues, say: "If this helped, forward it to one colleague." It sounds too simple, but it works.

Collaborate with peers. Find writers at a similar size in adjacent topics and recommend each other's newsletters. Most platforms support recommendation features, and a genuine recommendation from a trusted writer converts well.

Optimise the signup page once

Your signup page should answer three questions in a few seconds: who it's for, what they get, and how often. Add one or two links to your best past issues so visitors can judge quality. A short, specific description beats a clever slogan.

Measure the right things

At this stage, track:

Net new subscribers per week (new minus unsubscribes)
Where they came from (most platforms show referral sources)
Replies to your reader question

Open rates have become unreliable due to email privacy features, so treat them as a rough trend at best. Replies are the strongest early signal that you're writing for the right people.

What to skip early

Paid ads. Expensive per subscriber and hard to judge with small numbers.
Giveaways. They attract people who want the prize, not your writing, and they tend to unsubscribe.
Complicated referral rewards. Wait until you have enough readers for them to matter.
Buying lists. It hurts deliverability and is unlawful in many places.

Realistic expectations

Many newsletters grow slowly for the first months: a handful of subscribers per week is normal. Growth often speeds up once you have a public archive with several genuinely useful issues and a couple of pieces that get shared. Treat the first six months as finding your format and reader, not as a numbers race.

Summary

Define a specific reader, pick a platform quickly, publish on a schedule you can keep, get your first hundred from people you know, then grow through a public archive, repurposed posts, reference material and peer recommendations. Measure net growth and replies, ignore vanity metrics, and give it time.

If you want a starting structure instead of a blank page, I put together a small, inexpensive, AI-assisted kit on this topic: Newsletter growth playbooks. Everything above works without it. Other kits: all products.

Writing Email Sequences for a Niche Audience: A Practical Framework

FreeTier — Fri, 16 Oct 2026 19:54:49 +0000

Disclosure: this post was written with AI assistance.

Generic email sequences fail in niches because niche audiences notice immediately when you don't understand them. A bookkeeper for dental practices, a climbing gym, a B2B tool for logistics planners: each audience has its own vocabulary, worries and buying cycle. This framework helps you write a short sequence that sounds like it was written by someone inside the niche.

Step 1: Collect the audience's own words

Before writing anything, gather 20–30 real phrases your audience uses about their problem. Good sources:

Replies to your existing emails and support tickets
Sales call notes ("what made you look for a solution now?")
Reviews of competing products, especially 3-star reviews, which tend to be specific
Niche forums, subreddits and trade-association newsletters

Paste them into one document. You'll reuse these phrases in subject lines and openings. "Month-end close takes three days" beats "streamline your financial workflows" for an accountant every time.

Step 2: Pick one sequence with one job

Each sequence should do exactly one thing. Common types:

Welcome: turn a new subscriber into someone who reads your emails.
Lead nurture: move someone who downloaded a resource toward a call or trial.
Onboarding: get a new customer to their first meaningful result.
Win-back: re-engage inactive subscribers or lapsed customers.

Write down the single action that counts as success, such as "books a demo" or "completes setup". Every email should make that action slightly more likely.

Step 3: Use a five-email skeleton

For most welcome or nurture sequences, five emails over roughly two weeks is enough:

Day 0 – Deliver and set expectations. Give what they signed up for, say what's coming and how often. Ask one easy question they can reply to.
Day 2 – Name the problem precisely. Describe their situation in their words. Show you understand the cost of the problem, not just its symptoms.
Day 5 – Teach one useful thing. A specific technique, checklist or example they can use today, with or without you.
Day 9 – Proof. A short case story from someone in the same niche: situation, what changed, a concrete result. If you don't have one yet, share your own process or reasoning honestly instead of inventing testimonials.
Day 13 – Clear ask. Invite the one action. Handle the most common objection directly and make it easy to say no.

Adjust spacing to the niche's pace. Busy clinicians may prefer fewer, more spaced emails; developers trialling a tool may want them faster.

Step 4: Write each email with a simple template

For each email, fill in:

Subject: specific and plain, under about 50 characters. Use their words.
First line: the reason this email exists, said immediately.
Body: one idea, short paragraphs, 80–200 words for most emails.
One call to action: a single link or a reply request.
Sign-off from a real person.

Example for a bookkeeping service for dental practices, email 2:

Subject: The three days after month-end

Most practice managers we talk to lose two to three days every month reconciling card payments against the practice software. It's rarely one big problem; it's dozens of small mismatches from refunds, split payments and insurance top-ups...

Notice there's no "Hope you're well!" and no hype.

Step 5: Segment lightly

You don't need complex automation. One or two segments are usually enough: by role (owner vs. manager) or by stage (just browsing vs. actively evaluating). Ask in email 1 with a one-click choice, then branch emails 3–5. Small, relevant sequences outperform large, generic ones.

Step 6: Stay on the right side of the rules

Only email people who opted in or have an existing relationship that allows it under your local law. Rules differ a lot: in the EU and UK, consent requirements for marketing emails are strict, while the US CAN-SPAM Act focuses on accurate headers, a physical address and a working unsubscribe. Always include a clear unsubscribe link and honour it promptly. If you're unsure, check the rules for the countries your subscribers live in.

Step 7: Measure what matters

Open rates are unreliable since privacy features started pre-loading images. Focus on:

Replies to the email 1 question
Clicks on the one call to action per email
Conversions to the sequence's single goal
Unsubscribes per email; a spike tells you which email is off

Change one email at a time, wait for a meaningful number of recipients, then compare.

Common mistakes

Writing for "everyone in the industry". Pick one role and one situation.
Selling in every email. Teaching earns the right to ask.
Fake urgency. Niche audiences talk to each other; invented deadlines damage trust.
Copying another niche's sequence. Structure transfers; wording doesn't.

Summary

Collect real phrases from your audience, give each sequence one job, use a five-email skeleton, keep each message to one idea and one action, and measure replies and conversions rather than opens. Done well, a niche sequence reads less like marketing and more like a helpful colleague who happens to offer a service.

If you want a starting structure instead of a blank page, I put together a small, inexpensive, AI-assisted kit on this topic: Email sequence templates for niches. Everything above works without it. Other kits: all products.

Setting Up a Notion Workspace as a Freelancer: Clients, Projects and Invoices in One Place

FreeTier — Fri, 16 Oct 2026 19:49:14 +0000

Disclosure: this post was written with AI assistance.

Freelancers usually run their business across five tools: a spreadsheet for clients, a to-do app, a folder of invoices, an email inbox and their own memory. Notion can replace several of those, but only if you set it up around a few linked databases rather than a pile of pages. Here's a structure that works for most solo freelancers and stays simple enough to maintain.

The core idea: four linked databases

Everything hangs off four databases, connected with Notion's Relation property:

Clients – one row per client.
Projects – one row per engagement, linked to a client.
Tasks – one row per piece of work, linked to a project.
Invoices – one row per invoice, linked to a client and one or more projects.

Create each one as a full-page database (type /database and choose "Database – full page"). Then put them all on a single "HQ" page with linked views, so you have one place to start every day.

Clients database

Useful properties:

Name (title)
Status (Select: Lead, Active, Paused, Past)
Contact email (Email) and Website (URL)
Rate (Number, formatted as currency)
Projects (Relation to Projects)
Total billed (Rollup from Invoices, sum of Amount)

The rollup is the payoff: open any client and you see what they've paid you to date without opening a spreadsheet.

Projects database

Name (title)
Client (Relation to Clients)
Status (Status property: Not started, In progress, Waiting on client, Done)
Start and Deadline (Date)
Budget (Number) and Pricing (Select: Fixed, Hourly, Retainer)
Tasks (Relation to Tasks)
Progress (Rollup from Tasks, "percent checked" on a Done checkbox)

Add a Board view grouped by Status. "Waiting on client" deserves its own column, because that's where projects silently stall.

Tasks database

Keep it lean:

Task (title)
Project (Relation)
Due (Date)
Done (Checkbox)
Time spent (Number, hours) if you bill hourly

Create a view called Today filtered to "Due is on or before today" and "Done is unchecked", sorted by due date. That single view replaces most to-do apps.

Invoices database

Notion isn't accounting software, and it won't calculate tax or send invoices for you. Use it to track invoices, and generate the actual documents in your invoicing tool or a template.

Invoice # (title, e.g. 2026-014)
Client (Relation) and Projects (Relation)
Amount (Number)
Issued and Due (Date)
Status (Select: Draft, Sent, Paid, Overdue)
File (Files & media) for the PDF

Add a formula property called Days overdue:

if(prop("Status") != "Paid" and now() > prop("Due"), dateBetween(now(), prop("Due"), "days"), 0)

Then create a view filtered to "Days overdue > 0". Check it every Monday.

The HQ page

On your HQ page, add linked views (/linked view of database) of:

Tasks → Today view
Projects → board, filtered to not Done
Invoices → overdue view
Clients → Active only, as a compact list

This is the only page you need to open in the morning. Pin it to the sidebar under Favorites.

Templates that save real time

Notion's database templates let you pre-fill a new row. Two worth creating:

New project template: a page body with headings for Scope, Deliverables, Out of scope, Key dates and Notes, plus a starter set of tasks (Kickoff call, First draft, Revisions, Final delivery, Send invoice).
Client onboarding template on the Clients database: a checklist for contract signed, deposit received, access granted, kickoff scheduled.

The "Send invoice" task in every project template is small but effective; it stops finished work from going unbilled.

Automations, honestly

Notion has built-in database automations and recurring templates on some plans. They're useful for things like "when Status changes to Done, set a date". For anything involving email, payments or other apps, you'll need an external tool such as Zapier or Make, or Notion's API. Don't build these on day one. Use the system manually for a month first so you know which steps are genuinely repetitive.

Weekly 15-minute review

Every Friday:

Clear the Today view or reschedule what's left.
Move projects stuck in "Waiting on client" for over a week to the top and send a nudge.
Check the overdue invoices view.
Change any finished client to Past so your Active list stays honest.

Common mistakes

Building pages instead of databases. Pages can't be filtered, sorted or rolled up.
Too many properties. If you never fill a field, delete it.
Treating Notion as your accountant. Keep proper records for tax in an appropriate tool; Notion is your operational view.
Storing sensitive client data carelessly. Check sharing settings and avoid storing passwords in pages.

Summary

Four linked databases (Clients, Projects, Tasks, Invoices), one HQ page with filtered views, two templates and a weekly review give most freelancers a clear picture of their work and money. Start with this skeleton, use it for a month, and add complexity only where you feel friction.

If you want a starting structure instead of a blank page, I put together a small, inexpensive, AI-assisted kit on this topic: Notion workspace systems for freelancers. Everything above works without it. Other kits: all products.

How to Build a Prompt Library for Your Profession (That You'll Actually Use)

FreeTier — Fri, 16 Oct 2026 19:47:55 +0000

Disclosure: this post was written with AI assistance.

Most people who use AI assistants at work end up with the same problem: a handful of prompts that worked really well once, scattered across chat histories, never found again. A prompt library fixes that. It's not a list of clever tricks. It's a small set of reusable instructions tied to the tasks you actually do every week.

Here's how to build one that stays useful instead of turning into another forgotten document.

Start from your task list, not from prompts

Open your calendar and your sent folder for the last two weeks. Write down every recurring task that involves reading, writing, summarizing or deciding. For a project manager that might be status updates, meeting notes, risk logs and stakeholder emails. For a recruiter: job ads, screening notes, rejection emails, interview question sets.

Pick the five tasks that are both frequent and tedious. Those are your first library entries. Ignore everything else for now; a library with five prompts you use daily is worth more than one with two hundred you never open.

Use a fixed structure for every prompt

Prompts that work reliably tend to share the same parts. Give every entry these fields:

Role and context: who the model should act as and what situation it's in. "You are helping a hospital ward manager write a weekly staffing update for senior nurses."
Input: what you will paste in, clearly delimited. "Notes are between triple quotes."
Task: one clear instruction. "Write a 150-word update."
Constraints: tone, length, format, things to avoid. "Plain language, no acronyms, bullet list for open issues."
Output format: exactly how the answer should look, ideally with a short example.

Writing prompts this way makes them easy to adjust. When output is too long, you change one constraint instead of rewriting everything.

Add placeholders, not hard-coded details

Replace the parts that change with obvious placeholders: [CLIENT NAME], [DEADLINE], [PASTE NOTES HERE]. This turns a one-off prompt into a template. Keep placeholder names consistent across the library so you learn them once.

A good test: could a colleague in the same role use the prompt without asking you anything? If not, there's context missing.

Store it where you already work

The best storage is wherever you'll see it. Options that work well:

A text expander (Espanso, TextExpander, or your OS's built-in replacements) so typing ;status inserts the whole prompt.
A notes app with one note per prompt and tags by task type.
A shared doc or wiki page if your team will use it, with a table of contents at the top.

Avoid storing prompts only inside the AI tool's history. Histories get long, and some tools limit how far back you can search.

Keep a short log of what works

Next to each prompt, keep two lines: the date you last changed it, and a note on what went wrong before the change. "Added 'do not invent figures' after it made up a budget number." This is the most valuable part of the library over time, because it captures failure modes specific to your work.

Build in verification steps

For anything factual, add an instruction that makes checking easier: "List any claims that I should verify, separately at the end," or "Quote the sentence from my notes that supports each point." AI tools still produce confident errors. A library that bakes in verification protects you from the worst of them, and keeps you honest about what you hand to clients or managers.

Never paste confidential client data, personal data or anything covered by an NDA into a tool your organisation hasn't approved. Put that rule at the top of the library.

Examples by profession

To make this concrete, here are starter entries for a few roles:

Accountant: "Turn these bank transaction descriptions into categories from this list: [CATEGORIES]. Output a table with the original text, category and a confidence of high/medium/low. Mark anything ambiguous as 'review'."
Teacher: "Create five multiple-choice questions on [TOPIC] for [AGE] students. One correct answer, three plausible wrong answers based on common misconceptions. Include the misconception each wrong answer tests."
Sales rep: "Here are my call notes. Write a follow-up email under 120 words that restates the customer's problem in their words, confirms the next step and date, and asks one question."
Developer: "Review this function for edge cases only. Don't rewrite it. List inputs that would break it and explain why in one line each."

Notice that each one is narrow. Narrow prompts give predictable results.

Review monthly, prune ruthlessly

Once a month, look at which prompts you actually used. Delete or archive anything untouched for two months. Merge near-duplicates. Promote any ad-hoc prompt you typed more than twice into the library.

Common mistakes

Collecting instead of using. Downloading huge prompt lists feels productive but rarely changes how you work.
Vague roles. "You are an expert" adds little. Specific context ("for a small dental clinic's patient newsletter") adds a lot.
No output format. If you don't specify the shape of the answer, you'll spend time reformatting.
Never testing. Run each new prompt on three real examples before trusting it.

Summary

A prompt library is a working tool: five to twenty structured, tested templates for your recurring tasks, stored where you'll see them, with notes on what broke and how you fixed it. Start small this week with your most tedious task, and grow it only when a prompt has earned its place.

If you want a starting structure instead of a blank page, I put together a small, inexpensive, AI-assisted kit on this topic: AI prompt libraries for specific professions. Everything above works without it. Other kits: all products.