Freelance capacity planning happens before you promise a delivery date. List current commitments, estimate the new work by deliverable, identify client and third-party.
Freelance capacity planning happens before you promise a delivery date. List current commitments, estimate the new work by deliverable, identify client and third-party dependencies, reserve review and correction time, then offer an accept, revise, or decline decision with explicit assumptions.
A full calendar is not proof of productive capacity, and an open week is not proof that every dependency will arrive. This interview is a risk check, not a guarantee. It gives both sides a realistic basis for scope, sequence, communication, and change decisions before work begins.
State the decision the interview must support: accept the proposed scope and date, offer a smaller or later version, or decline. Ask what outcome must exist at delivery and which elements are essential. A vague request to make a website modern cannot be estimated until pages, content, workflows, devices, approvals, and launch responsibility are visible.
Separate the client’s desired date from a fixed external deadline. Ask what event depends on delivery, what happens if it moves, and which partial outcome would still help. Do not manufacture urgency or dismiss a real event. Record the source of the date so later tradeoffs can protect the important outcome rather than an arbitrary calendar marker.
List active projects, recurring support, teaching or employment hours, personal obligations, and administrative work. For each commitment, record the next deliverable, review window, likely correction time, and non-movable dates. Count sales, invoicing, file preparation, meetings, testing, and handoff work rather than estimating only visible design or development hours.
Use conservative available hours, not every waking hour. Preserve sleep, health, travel, and recovery. If a current project is uncertain, represent a range and reserve a buffer. Capacity planning should reveal competition between commitments before a conflict reaches two clients at once.
Translate the request into inspectable outputs such as approved sitemap, responsive page designs, implemented templates, migrated content, tested forms, analytics setup, launch checklist, and handoff notes. Name what is excluded. Estimate each deliverable separately because one total number conceals where uncertainty and client effort live.
Add discovery, setup, review, correction, quality assurance, and deployment tasks. PMI scheduling references treat durations, dependencies, milestones, resource information, and buffers as connected planning inputs. A freelance plan can stay lightweight while still making those relationships explicit.
Ask who supplies copy, images, brand files, access, legal text, product data, and feedback. Record the owner, required format, due date, and fallback when an input is late. A dependency is not complete merely because someone says it exists; confirm whether it is approved, accessible, and usable for the intended deliverable.
Do not hide client work inside your estimate. If final design depends on final copy, show that sequence. Offer safe options such as a content-first milestone or a limited template demonstration, but do not build production layouts around placeholders that will radically change hierarchy.
Confirm hosting, domain, CMS, plugins, accounts, integrations, licenses, data sources, and authorized access. Ask which systems must remain and who can approve changes. Never request passwords in an ordinary proposal document or accept credentials through an unsafe channel.
For each integration, distinguish configuration you control from service behavior you cannot guarantee. Reserve time for documentation review, sandbox testing, support delays, and fallback behavior. If a required platform is unknown, make discovery a paid milestone instead of pretending the uncertainty fits inside a fixed implementation estimate.
Name the decision owner and subject reviewers for content, brand, accessibility, technology, and policy. Define which deliverable each person reviews, how feedback is consolidated, and how long the review window remains open. Multiple uncoordinated reviewers create schedule risk even when production work is small.
W3C accessibility planning guidance recommends defining goals, scope, responsibilities, resources, reviews, and monitoring. Apply the same discipline to the project: accessibility is not a final-minute check, and review time must exist for content, design, implementation, and appropriate user evaluation.
Arrange work by dependency rather than preference. Discovery precedes committed architecture; approved content precedes final layouts; implemented workflows precede end-to-end testing; corrected defects precede launch. Mark work that can happen in parallel and work that cannot.
Add milestones with observable completion criteria. A date called design complete is ambiguous; approved desktop and mobile layouts for named pages is testable. Use a schedule range when uncertainty is meaningful, and update the forecast when inputs or scope change instead of silently consuming every buffer.
Ask what could make the plan fail: late content, unavailable reviewers, unfamiliar integration, dependency outage, revision volume, illness, or overlapping launches. Rate probability and impact in simple terms, then choose a response such as reduce scope, add time, prototype early, secure backup support, or decline the dependency.
Buffers are not hidden free revision time. Place contingency where uncertainty exists and explain the assumption. When the deadline has no room for testing or correction, the responsible response is a smaller deliverable or later date, not a confident promise unsupported by the work sequence.
Accept when scope, access, capacity, review ownership, compensation, and risk are workable. Revise when a smaller first release, later date, phased discovery, or different review process creates a credible plan. Decline when the work requires unavailable expertise, unsafe access, impossible timing, misleading claims, or terms you cannot responsibly satisfy.
Give the client a concise reason tied to the project, not a defensive life story. A revised offer should state deliverables, assumptions, exclusions, dependencies, milestones, review limits, and change process. A decline can still be professional and timely, leaving the client able to seek another provider.
Summarize the accepted scope, schedule, responsibilities, dependencies, fees, payment timing, intellectual-property terms, confidentiality, accessibility expectations, communication, acceptance criteria, and change control in an appropriate agreement. Seek qualified local advice for legal terms rather than treating a generic article as a contract.
Recheck the capacity plan immediately before signing because other commitments may have changed. A structured Web Design course can build practical delivery skills, but each freelance commitment still requires its own evidence-based qualification. Start only after the written baseline and required access are in place.
Turn the interview into a one-page worksheet with fields for outcome, deliverables, exclusions, target date, date source, available hours, dependencies, reviewers, access, technical uncertainty, and next decision. Complete it during or immediately after the call. Empty fields are visible evidence that the commitment is not ready, not an invitation to make a favorable assumption.
Add three estimates for uncertain work: a plausible low case, a working estimate, and a high case when a named risk occurs. Record why the range exists. Compare the working and high cases with genuinely available capacity across the same calendar period. This stress test reveals whether a modest delay would affect another client or eliminate testing time.
The worksheet should state the next validation action. That might be receiving an approved sitemap, testing access in a staging environment, reviewing an API, or identifying the final decision maker. Give each action an owner and due date. Revisit the decision after the evidence arrives instead of treating the first interview as permanent approval.
Pause when the buyer will not name deliverables, expects unlimited revisions, asks you to bypass security controls, refuses a written agreement, or treats every dependency as your responsibility. Also investigate requests to copy a competitor, use unlicensed assets, publish unsupported claims, or conceal the actual purpose of a system. These are delivery and professional risks, not minor negotiation details.
A low budget is not automatically a bad project, and a demanding deadline is not automatically impossible. The warning sign is a mismatch that cannot be resolved transparently. A smaller first phase may work when expectations, ownership, and acceptance criteria become clear. When the client rejects every practical adjustment, declining protects both parties from a predictable failure.
Keep a short decision record after the conversation. Note the evidence reviewed, unresolved assumptions, proposed mitigation, and final answer. Do not store unnecessary personal information or credentials. Over time, compare estimated and actual effort by deliverable so future interviews use your own delivery evidence rather than confidence or memory alone.
For example, if a five-page launch depends on copy, product photography, domain access, and two reviewers, show those four dependencies beside the production sequence. Offer a date after required inputs, a phased launch with approved pages, or a discovery milestone. The client can then choose a real tradeoff rather than hearing a date that assumes every input arrives perfectly.
Use a buffer tied to identified uncertainty rather than one universal percentage. Consider review delays, integration risk, corrections, and competing commitments, then explain what the delivery range assumes.
Only with a clear content dependency plan. Define who supplies approved content, when it is due, which work can proceed safely, and how late delivery changes scope or schedule.
Decline when timing, expertise, access, ethics, safety, payment terms, or dependency risk cannot be made workable through a smaller scope, phased discovery, or revised schedule.
Explore RisingEdge courses designed to help students learn real skills, build projects, and prepare for career opportunities.
Share client work only when you have permission for the exact material, audience, channel, and duration, and when the released package has been checked for confidential data.
Get the latest guides, insights, and course updates.
No spam. Unsubscribe anytime.
A freelance website proposal should define the work clearly enough for the client and freelancer to make the same decision. State the business outcome, deliverables.
