Topic Introduction
Freelance work starts with a conversation that acts like a contract draft. If you wait until after you begin, you usually end up negotiating changes under time pressure, which increases the chance of scope creep and payment delays.
For your first gig, discuss the work in terms that can be checked later: what you will deliver, how it will be reviewed, when it will be due, and what happens when requirements shift. A practical example: if you’re designing a landing page, you can define “deliverables” as a Figma file plus exported assets, then define “done” as client approval in writing. If you’re writing copy, you can define “done” as a document with tracked changes and a final version after up to a set number of revision rounds.
Main Problems Or Pain Points
People often get the first gig wrong by treating the initial chat as a vibe check instead of a requirements capture. The client hears “I can do that,” and you hear “we’ll figure it out later,” then both sides discover they meant different things.
Another common failure is unclear scope boundaries. “Marketing support” can mean anything from ad copy to analytics reporting. Without a written scope, you end up doing extra tasks that were never priced, never scheduled, and never approved.
Dependencies create hidden risk. Many freelance tasks depend on third-party access: a client’s content management system, a design system, a spreadsheet with product data, or a developer account. If you do not name those dependencies upfront, you will discover them mid-project, and the delay becomes your problem even when it originates elsewhere.
Solutions And Advice
Define Deliverables And “Done”
Write a short deliverables list that names format, location, and acceptance criteria. For example: “One PDF report (A4, 2–3 pages) plus a CSV of source data,” or “Three logo concepts in SVG and PNG, delivered via a shared folder.” Then define “done” as a specific approval event, such as a reply email stating “approved” or a comment thread resolved in a tool like Google Drive or Notion.
Use a revision policy that matches the work type. A common starting point is two revision rounds for small projects and three for larger creative or technical deliverables. If the client requests changes outside the scope, treat them as a new request with a new estimate. This is where people get stuck because they fear sounding difficult, yet silence usually costs more time than a clear boundary.
Include versioning details when output changes. If you’re editing a document, specify whether you will deliver “v1” and “v2” files, or a single final file with tracked changes. I’ve seen confusion when one side expects “final” to mean “ready to publish,” while the other expects “final” to mean “final for review.”
Set Timeline With Review Windows
Break the schedule into work blocks and review windows. Instead of one vague deadline, propose milestones like “draft by May 10,” “client feedback by May 13,” and “final delivery by May 17.” This makes delays visible and prevents the client from compressing your work by delaying their review.
Ask for access dates and response-time expectations. If the client needs to share assets, define a date when they will provide them. If they cannot commit, adjust the timeline or adjust the scope. A mild frustration is normal here: many clients say they can respond “within 24 hours,” then they respond on day four, and the project schedule still assumes day one.
For tools, name the environment. If you’re building something in a CMS, specify the platform and whether you will work in staging. If you’re using a design tool, mention the file type and export settings. Even a small detail like “Figma file with components” or “Word document with headings” reduces rework.
When you estimate, include a buffer for review cycles. A practical rule is to allocate at least 30–50% of the total calendar time to client feedback and iteration, especially for first gigs where expectations are still forming.
Agree On Payment, Invoices, And Taxes
Discuss payment structure before work begins. Common options include a fixed price with a deposit, hourly billing with a weekly cap, or milestone payments. For first gigs, a deposit often reduces risk; a typical range is 30–50% upfront, with the remainder due upon delivery or per milestone.
Define the invoice trigger. Examples: “Invoice 1 due upon contract signing,” “Invoice 2 due upon delivery of v2,” or “Invoice due within 14 days.” If the client uses a procurement process, ask about payment terms early because “Net 30” can turn into “Net 60” depending on internal approvals.
Clarify what expenses are included. If you will need stock images, software subscriptions, or travel, specify whether those costs are billed separately. Also clarify currency and payment method. A small aside: I once saw a project stall because the client paid in a different currency and the freelancer’s bank fees were not discussed, so the freelancer’s net amount differed from the invoice expectation.
Taxes depend on your country and the client’s location. Do not guess. Use your local tax guidance or a qualified accountant to determine whether you need invoices with tax, how to handle VAT/GST, and whether you must collect any withholding. If you cannot confirm, write the uncertainty into the agreement and ask the client to confirm their side.
Case Examples
Copywriting With Revision Boundaries
A freelance writer agrees to “rewrite product pages” for an ecommerce brand. Upfront, they define deliverables as 6 product pages in a shared Google Doc, each with a target word count range and a specified tone. They set two revision rounds and define that new SEO keyword research counts as an additional request. The client provides product specs on day 3, feedback arrives on day 6, and the writer delivers the final pages on day 9. The project stays on schedule because the agreement names what “done” means and what changes trigger a new estimate.
Website Setup With Access Dependencies
A freelancer is hired to set up a landing page in WordPress. The initial chat mentions “just publish it,” but the freelancer asks for staging access, theme version, and the plugin list. The client shares a staging URL and confirms the theme version on day 2. The freelancer delivers a draft by day 5, then waits for client feedback within a defined review window. When the client requests a new form field and a different email template, the freelancer treats it as a scope change and quotes a small add-on rather than silently absorbing it. The timeline holds because the agreement treats access and review as dependencies, not surprises.
Comparison Table Or Checklist
| Topic | What To Ask | Good Sign | Red Flag |
|---|---|---|---|
| Deliverables | Formats, counts, and acceptance criteria | Client can describe what “approved” means | “We’ll decide later” without a list |
| Timeline | Milestones and review windows | Client commits to feedback dates | Single deadline with no review plan |
| Payment | Deposit, milestones, invoice timing | Clear payment terms like “Net 14” | “Pay when you’re done” with no date |
| Access And Data | Credentials, storage, deletion after work | Limited-permission access and revocation plan | Sharing passwords or unclear data handling |
Use this checklist before you start: write deliverables, define “done,” set revision rounds, list dependencies and access dates, agree on payment triggers, and document data handling. If any item stays vague, you can still proceed, but you should price the uncertainty or reduce the scope.
Common Mistakes
One mistake is sending a proposal that lists tasks but omits acceptance criteria. A client can reject output without a clear standard, and you end up debating taste instead of requirements.
Another mistake is agreeing to revisions without defining what counts as a revision. “We’ll revise until it’s perfect” creates unlimited work. A revision policy should cover the number of rounds and whether revisions include new research, new assets, or only edits to existing material.
Freelancers also underestimate the cost of unclear communication. If you do not define response times and channels, you end up waiting for feedback in email threads that nobody monitors. A practical fix is to name one primary channel and one backup channel, then set a response expectation like “client feedback within 48–72 hours during the review window.”
People sometimes forget to document changes. If the client requests a new feature on day 7, you need a written change note: what changed, what it costs, and how it affects the timeline. Even a short email thread can serve as a record, and it prevents “I never agreed to that” later.
Finally, avoid promotional writing in your agreement. If your contract reads like an advertisement, it becomes harder to enforce scope boundaries. Keep the language factual: deliverables, dates, payment terms, and what happens when either side delays.
FAQ
What should I discuss first?
Start with deliverables and acceptance criteria, then cover timeline milestones with review windows, then payment triggers. Those three topics determine most disputes.
How many revision rounds should I offer?
For many first gigs, two rounds for small tasks and up to three for larger creative or technical deliverables works as a starting point. Define what counts as a revision versus a new request.
Should I ask for a deposit?
For first gigs, a deposit reduces the risk of non-payment and covers early work. Common ranges are 30–50%, but the right number depends on your costs and the client’s payment reliability.
What if the client delays feedback?
Write a review-window policy and adjust deadlines when the client misses those windows. If delays repeat, pause work or move to a milestone-based approach.
Do I need a contract for a small job?
A short written agreement helps even for small jobs. At minimum, document scope, deliverables, revision policy, payment terms, and data/access handling in email or a simple contract.
Author's Insight
Good freelance agreements reduce ambiguity, not creativity. The most reliable upfront discussions translate “what we want” into checkable deliverables, acceptance criteria, and review dates.
When dependencies exist, you reduce risk by naming access requirements and response windows before work begins. That approach also makes it easier to explain schedule changes without blame.
Payment terms matter because invoicing timing affects cash flow. Clear triggers like “upon delivery of v2” prevent disputes about whether work finished.
For privacy and data handling, the safest path is to ask what data categories you will touch and whether a data processing agreement already exists. If you cannot confirm legal coverage, you should pause or narrow the scope until the client clarifies their responsibilities.
Key Takeaways
- Define deliverables, formats, and “done” in writing before you start.
- Set milestones with review windows so client feedback delays do not silently become your problem.
- Agree on payment triggers and revision rounds, then document scope changes.
- Clarify access and data handling, including how credentials and personal data are managed.
- Use a short written record (contract or email thread) to prevent “we meant something else” disputes.
