Use a project fee for defined copy work, and switch to hourly only when discovery is still unresolved. Price copywriting project engagements after the core items are written: deliverables, revision rounds, approval owner, payment terms, and invoice dates. Then lock those terms in the proposal and Statement of Work so scope changes trigger a change order instead of unpaid rework. If scope is still moving, bill discovery first and set a written checkpoint to convert production to fixed pricing.
If you want fewer payment arguments later, set the project fee around decisions you can document: the scope of work, exact deliverables, clear payment terms, and a dated invoice schedule. That keeps pricing tied to what the client is buying, instead of quietly agreeing to extra work, open-ended revisions, or approval delays that eat margin.
For most defined copy jobs, start with project pricing, not a per-word or per-minute rate. A common rule in copywriting guidance is simple: charge by the project, and use hourly pricing when scope is still too fuzzy to fix. That fits the reality that copywriting value includes strategic thinking and concepts, not just word count.
Per-word pricing can create the wrong incentive. Strong copy often gets shorter as it gets better. If you charge only for volume, you can end up punishing yourself for doing the higher-skill version of the job. That does not make hourly pricing wrong. It means hourly can work as a fallback while scope is still being defined.
This is not about copying a rate card. It is a decision method. Before you quote, you should be able to answer four checks in writing:
If any one of those is missing, your quote is still a draft. A usable quote is not just a number; it is a commercial boundary.
Be careful with examples you see online. A writer may publish rates such as $.50 to $.80 per word for SEO blog posts up to 2,000 words, or $400 per email. They may also show package examples like $2,000 for five emails. Those are useful examples of how one writer structures offers, not market law. Your job is not to copy a posted rate. It is to connect your fee to the work being bought.
A lot of project friction starts with an accidental promise. "Website copy" can turn into ten pages instead of five. "Two revisions" can become six rounds of stakeholder comments. "Quick approval" can become two weeks of silence while your final invoice waits.
So your opening quote should include a short evidence pack: scoped deliverables, revision limit, approval contact, timeline assumptions, and invoice dates. If those items do not appear in the proposal or statement of work, you are relying on memory and goodwill.
For a freelance writer, the real win is not just booking the project. It is booking work you can deliver, get approved, and invoice without a cleanup project later. That starts with getting the right inputs before you put any number on the page.
If you want a deeper dive, read How to Price a 3D Animation Project.
Prepare enough project detail to defend your price, and treat any early number as a ballpark until scope is clear. Some writers share a ballpark on the first call; others gather more context first. Both approaches can work. The key is to reserve your formal quotation or proposal for when the core inputs are documented.
| Preparation item | What to capture | Quote status |
|---|---|---|
| Minimum evidence pack | Client goal, current assets, exact deliverables, and what "done" means | Use a formal quotation or proposal once the core inputs are documented |
| Commercial boundaries | Who is giving feedback and how timeline decisions will be handled | If approvals or timing are unclear, keep the number as a ballpark rather than a final quote |
| Value and scope | Value of the work, actual workload, and stated assumptions | State assumptions clearly so scope creep does not turn into unpaid work |
| Baseline economics | Your billable-rate method before setting the project fee | Use the baseline math to convert internal numbers into a project quote |
Capture the client goal, current assets, exact deliverables, and a clear definition of what "done" means in one place. A brief, call notes, or an email thread all work, as long as they define the job. If the client already specifies scope like 10-17 pages and 2-3 paragraphs per page, use that as a concrete pricing driver.
Confirm who is giving feedback and how timeline decisions will be handled. If approvals or timing are still unclear, label your number as a ballpark rather than a final quote. Then send a formal quotation or proposal after you have the full project details.
Your quote should reflect both the value of the work and the actual workload, with assumptions stated clearly. This helps prevent scope creep from turning into unpaid work later.
Work out your baseline economics first using your billable-rate method, then convert that into a project quote. If you have not done that math recently, use How to Calculate Your Billable Rate as a Freelancer before you price anything.
You might also find this useful: How to Price a Mobile App Development Project.
Use this default rule: choose a project fee when scope is stable and deliverables are clear; start hourly when either is still moving, with a written review checkpoint before you commit to fixed pricing.
Each model shifts risk differently. Project fees give clients more cost certainty and can reward your efficiency when scope is defined. Hourly pricing is practical when scope is uncertain or ongoing. Per-word pricing can misalign incentives for copy, because outcomes often come from sharper, shorter messaging rather than more words.
| Model | Best fit | Margin risk to you | Admin burden |
|---|---|---|---|
| Per-word rate | Volume-led writing where word count is the main output | Higher if research, revisions, or strategy drive the work | Moderate, because scope exceptions still need handling |
| Hourly rate | Unclear, evolving, or ongoing work | Lower early, since time is billed | Higher, because time tracking and reporting are continuous |
| Project fee | Clearly defined deliverables and acceptance criteria | Lower when scope is tight; higher when scope is vague | Lower after sign-off, because billing and expectations are simpler |
One benchmark from a freelancer community found that most freelancers charged per project, while 32% charged per word or hourly for writing work. That does not make project fees right for every engagement, but it does line up with a common shift toward pricing outcomes instead of volume.
Use a project fee when you can clearly state what is included and what "done" means. If deliverables, revision limits, approval path, and acceptance criteria are all written and specific, fixed pricing is usually the cleanest choice.
Use hourly when discovery is real work and core decisions are still open. Then set a written checkpoint tied to a concrete output, and decide there whether to keep hourly or convert to a project fee for execution.
Per-word pricing pays for length, while copy value often comes from compression and strategic choices. That is where value-based pricing can better match what the client is buying.
If discovery is uncertain but production becomes clear after discovery, use a hybrid: hourly for discovery, then a project fee for execution once the updated Statement of Work (SOW) and change order terms are locked. A freelancer writer in the grounding examples described this same progression from per-word pricing to per-project pricing as experience increased. If you want a quick next step on pricing, try the free invoice generator.
When you use fixed pricing, build the project fee from explicit scope inputs, not instinct. A defensible fee starts with a clear scope of work and assumptions someone else could follow.
Price the work from effort drivers you can name: assets, research depth, interviews, meetings, revision cycles, and final deliverables. Research and client coordination are part of the job, and they can materially change effort.
Use a simple check: can you point to each cost driver in the quote? If page count, interview load, review rounds, or deliverables are vague, you are still guessing.
A strong quote states scope, inclusions, exclusions, assumptions, timeline, and payment terms. This is what makes the fee defensible when the project shifts.
Write assumptions as conditions, not mental notes. If feedback timing changes, more approvers join, or unplanned rewrites appear, your scope and revision cap should already show how that is handled. If assumptions change before kickoff, reissue the project fee instead of absorbing scope drift.
Fixed pricing is safer when "done" is defined in writing before work begins. Tie acceptance criteria to the agreed deliverables, brief, and revision terms so review stays anchored to what was scoped.
Written criteria will not remove every disagreement, but they reduce subjective "not what we expected" disputes. If the brief, scope, assumptions, timeline, payment terms, revision limits, or acceptance criteria are still unclear, pause and tighten the document first.
For a step-by-step walkthrough, see How to De-Risk a Fixed-Price Project with a Phased Payment Schedule.
Treat your Statement of Work as a control document: if a request is not in the agreed deliverables, exclusions, timeline, or acceptance criteria, it is new scope and should go through a change order.
| SOW element | What to state | Role |
|---|---|---|
| Deliverables | Exact assets and format | In scope |
| Timeline | Key stages and review windows | Sets review timing |
| Acceptance criteria | How work is approved | Approval standard |
| Exclusions | What is not included in this fee | Out of scope |
A strong SOW should make it obvious what is in scope and what is out of scope without guessing. That clarity keeps stakeholders aligned and reduces the drift that comes from assumptions.
Use concrete, countable language:
If the document is vague, scope creep and deadline slippage become more likely.
Anything outside the original contract or proposal is out of scope. When that happens, stop, price the added work, and get signed approval before starting.
State the mechanics in plain language:
This keeps extra work from turning into unpaid work.
Set practical enforcement terms in writing so the project stays workable when conditions change:
Add a handoff clause that says final files are released after the invoice schedule conditions are met. Before signature, confirm your SOW clearly covers three cases: added requests, delayed approvals, and early project stop.
We covered this in detail in How to Price a Bookkeeping Service for Small Businesses.
Set payment terms at the start, and tie invoices to work progress instead of waiting until the end. A staged structure (kickoff, mid-project milestone, final approval) makes cashflow more predictable and reduces exposure if approvals stall.
Use clear invoice triggers tied to real events, such as kickoff, first draft delivery, and final approval against agreed criteria. Put the full invoice schedule in one place, then mirror the same wording in both the proposal and SOW so due dates and triggers cannot be interpreted two ways.
| Payment term | Meaning | Timing |
|---|---|---|
| Net 30 | Payment is due 30 days after receiving the invoice | 30-day due date |
| Net 60 | Extends the Net 30 timeline by another month | Longer payment timeline |
| 2/10 Net 30 | 2% discount for payment within 10 days; otherwise full payment due on day 30 | 10-day discount window and day-30 due date |
If a client requests Net 30, that means payment is due 30 days after receiving the invoice. If they request Net 60, you are extending that timeline by another month. If useful, you can also offer 2/10 Net 30: a 2% discount for payment within 10 days, otherwise full payment due on day 30.
Write the late-payment terms before you need to enforce them. Keep the language simple and explicit: what happens when payment is late, whether work pauses, and how the schedule shifts once payment clears.
This is especially important if the project could become end-loaded. When most payment sits behind final approval, delays can trap cashflow; staged invoices reduce that risk by aligning payment timing with delivery progress.
List accepted payment methods directly in your terms, and keep one complete record trail for the project: signed proposal, SOW, invoice IDs, delivery confirmations, and approval notes. The goal is operational clarity: what is due, when it is due, and what changes if payment is late.
For related reading, see How to Price a Cloud Infrastructure Audit.
Protect margin by treating revisions as limited polish against the original scope and acceptance criteria, not open-ended rework.
Step 1: Separate revision from new scope. A revision improves what you already agreed to deliver. If feedback changes strategy, target audience, or asset count, treat it as out-of-scope work, not a revision.
Step 2: Set the revision cap in writing before work starts. State in the written agreement whether revisions are included in the project fee or billed separately. Also state what happens after the included rounds are used, since extra revisions and ad hoc changes can quickly create scope creep.
Step 3: Convert extra work to a paid change order immediately. When a request is out of scope or beyond the cap, pause. Quote the added work, charge your standard rate or higher, get written approval on a change order, and only then begin.
Step 4: Batch feedback and log approvals. Require one consolidated client response per round so you are not reworking conflicting comments across multiple threads. After each round, confirm in writing what changed and whether the draft meets the agreed acceptance criteria to prevent later disputes about what was included.
Need the full breakdown? Read How to Price a Clinical Trial Data Analysis Project.
Use a fixed gate order so delivery, approval, and payment do not blur together: paid kickoff, documented draft delivery, revisions to written acceptance criteria, written approval, final invoice, then final release after payment confirmation.
Step 1 Receive kickoff payment before work starts. Start only when kickoff payment is confirmed and your invoice schedule reflects that status. Keep the active schedule attached to the signed contract and SOW, since schedules can be treated as an inseparable part of the agreement rather than a side note.
Step 2 Deliver the draft, then run revisions against the agreed standard. Submit deliverables in a traceable way and log the date and version. Keep revisions tied to the acceptance criteria in the SOW. If requests add scope, pause and move that work into an amendment exhibit (and purchase-order path if your contract uses one) before continuing.
Step 3 Get explicit written approval, then issue the final invoice. Do not treat silence or verbal feedback as acceptance. Get written approval against the agreed criteria, and where your agreement requires formal acceptance, use signature-based approval for amendments or renewals.
Step 4 Release final files only after payment confirmation, and keep one audit trail. Make payment confirmation your final release checkpoint. Keep contract version, SOW, schedules, amendment exhibits, invoice IDs, deliverable versions, and approval messages together so you can quickly verify what was agreed, delivered, approved, and paid.
Use this before you price a copywriting project: lock scope, pricing rules, contract controls, payment stages, and approval gates in writing before kickoff.
Document scope, deliverables, timeline, responsibilities, and acceptance criteria in the SOW. Also state what is excluded and how approval works so scope boundaries are clear.
Use a project fee when work and deliverables are clearly defined. If discovery is still in progress, bill that phase hourly, then switch production to fixed pricing after the SOW is updated.
Put revision caps, change-order handling, and kill-fee terms in writing. Scope changes should be handled as written contract modifications, not informal messages. For kill fees, define the trigger and amount; for example, one publication agreement uses 50% and 75% in different rejection scenarios, but those percentages are not universal rules.
Send a deposit invoice, then use milestone billing with a clear invoice schedule tied to deliverables and dates. Align payment terms across the proposal, SOW, and invoice to reduce disputes. Agree milestone amounts, deliverables, and deadlines before work starts.
Set a written client approval deadline for each stage and keep approval records with delivery and invoice proof. One fixed-price milestone flow uses a 14-day action window as a model; adapt the gating logic to your own contract terms. Release final handoff files only after the invoice schedule conditions are met.
This pairs well with our guide on How to Price a Branding Package for a New Business. If you want to confirm what's supported for your specific country/program, talk to Gruv.
Start with an hourly rate for discovery, not a guessed project fee. That gives you a paid way to clarify goals, assets, approvers, and draft acceptance criteria while the work is still moving. Before you switch to a fixed total, update the SOW so the deliverables, milestones, and timeline are written down. A common risk is locking a flat fee before strategy questions are settled, then absorbing the rewrite risk.
Yes, sometimes, especially when the output is mostly volume based, like straightforward web or blog content. Per-word pricing is one common method, alongside hourly and project pricing. One 2026 rate guide shows a broad web content range of $0.10 to $1.00 per word, which is useful as a market example, not a universal pricing rule across niches, seniority levels, or markets.
Use hourly when interviews, stakeholder input, or scope are likely to evolve after kickoff. Use a project fee when the task is well defined and you can name the deliverables, milestones, and timeline up front. If the job starts fuzzy but becomes stable after discovery, reissue the quote and move the production phase to fixed pricing.
Include the scope boundaries, pricing model, pricing details, and revision terms. A good quote should let the client see what is included, what is not, and what triggers added charges. The test is simple: if a third party read the quote, could they tell whether a request is a revision or new scope?
Put revision terms in every proposal and contract, and make them specific. For example, state that the quote includes two rounds of revisions, then name the charge for any extra round. Also define approval and payment timing in writing so the workflow is clear.
Usually, show the project total and what the client gets for it. Fixed pricing is agreed as a total cost before work begins, regardless of how many hours it takes, so your internal math can stay internal. If a client asks for time based scoping or you are selling a discovery phase, then sharing an hourly estimate can make sense. If you need to tighten that math first, use How to Calculate Your Billable Rate as a Freelancer.
Price website work from page assumptions, not from a vague “site copy” label. Page-level scope can change the fee materially: one guide shows $100 to $400 per page and $1,500 to $3,500 for a small website, which tells you why page inventory matters. List each planned page or template, cap revisions, and name the overage rule in the SOW. The failure mode is agreeing to “Home, About, Services, and maybe a few more pages” without a page list or revision cap.
A former product manager at a major fintech company, Samuel has deep expertise in the global payments landscape. He analyzes financial tools and strategies to help freelancers maximize their earnings and minimize fees.
With a Ph.D. in Economics and over 15 years at a Big Four accounting firm, Alistair specializes in demystifying cross-border tax law for independent professionals. He focuses on risk mitigation and long-term financial planning.
Includes 3 external sources outside the trusted-domain allowlist.
Educational content only. Not legal, tax, or financial advice.
--- ---
**Start with the business decision, not the feature.** For a contractor platform, the real question is whether embedded insurance removes onboarding friction, proof-of-insurance chasing, and claims confusion, or simply adds more support, finance, and exception handling. Insurance is truly embedded only when quote, bind, document delivery, and servicing happen inside workflows your team already owns.
Treat Italy as a lane choice, not a generic freelancer signup market. If you cannot separate **Regime Forfettario** eligibility, VAT treatment, and payout controls, delay launch.