Freelance Project Milestones and Acceptance Criteria

"The website is nearly finished" is hard to review. "The agreed homepage prototype is ready, including its mobile view and error states" gives the client something specific to check. Freelance project milestones and acceptance criteria turn that difference into a written plan.

A milestone marks a point in the work. Acceptance criteria say what the deliverable must satisfy. Agree on both before starting, along with dependencies, review dates and a way to handle changes. The examples below are hypothetical planning choices, not standard rates, legal advice or ALHarih payment rules.

Start with scope and exclusions

Write down the problem, audience and outputs. For a five-page business website, list the five pages. Then clarify whether the fee includes copywriting, photographs, design, implementation, hosting setup or ongoing support. A page count alone does not settle those questions.

Record what the client must supply, including brand files, approved text and access. Name the person who can approve work. Ask about constraints before estimating: an existing integration or a required browser may affect the work more than the number of pages.

Keep exclusions visible. If a booking feature is outside the agreement, say so rather than relying on an informal conversation. This also gives the client a clear basis for requesting a separate quote later.

Choose milestones that support decisions

Atlassian describes milestones as significant points that mark progress. Use them where a deliverable or decision makes the next stage possible, rather than turning every small task into a formal checkpoint.

A website engagement might have discovery, design, development, testing and handoff stages. Discovery produces an agreed brief and sitemap. Design produces the specified layouts and prototype. Development implements the approved scope. Testing checks the agreed behaviour, and handoff supplies the promised files, documentation and access.

That sequence is a sample, not a required method. A small prototype may need fewer stages. A complex integration may need a separate investigation before either party can estimate implementation responsibly. Ask whether each milestone gives the reviewer a meaningful decision to make.

Write conditions a reviewer can observe

Atlassian's acceptance-criteria guidance focuses on clear, testable conditions for completion. Replace "looks professional" or "works properly" with a description of the expected result.

For a homepage design, this might mean the approved logo, navigation, hero area and contact button appear in the agreed desktop and mobile layouts. For a working contact form, specify what happens when required fields are empty, an email is invalid or submission succeeds.

Be precise about the type of deliverable. A clickable prototype can demonstrate validation and confirmation states without sending a real message. A developed form needs separate checks of its actual submission behaviour. Do not accept one as evidence of the other.

For compatibility, list supported browsers and viewports rather than saying "all devices". For files, name the format and delivery location. Not every condition needs a number, but the client and freelancer should be able to reach the same conclusion when checking it.

A hypothetical milestone table

This example concerns a small homepage prototype, not a complete production website. The review windows are sample durations for negotiation. The parties still need actual dates, a named reviewer and agreement on what happens if an input is late.

Milestone	Deliverable and acceptance test	Dependency	Sample review window
Discovery	Written brief and agreed target tasks; reviewer confirms included screens and exclusions	Client provides existing research and requirements	Two business days
Prototype	Desktop and mobile homepage views; navigation, validation and confirmation states demonstrated in the clickable prototype	Approved copy, brand assets and discovery decisions	Three business days
Handoff	Editable files, decision log and unresolved issues delivered to the agreed location	Consolidated prototype feedback	Two business days

Suppose the reviewer says the contact form does not work. First compare that feedback with the agreed prototype criteria. If a required state is missing, record and correct the gap. If the reviewer now wants a live email integration, estimate it as a scope change. The distinction depends on the written agreement, not on which party uses the word "finished" first.

Original explanatory diagram generated for this editorial correction; not a product screenshot. The diagram contains no copied image assets. Source: this article’s worked example. No third-party image licence is asserted.

Allow time for dependencies and review

Estimate the work and the waiting time separately. A designer may finish a layout before the client supplies final copy, but that does not make the content dependency disappear. Record the owner and due date for each input.

Agree on how delayed assets, access or feedback affect later milestones. If the client misses a review date, discuss a revised schedule and the freelancer's availability. Do not silently compress testing to preserve a deadline that no longer fits the work.

Define business days and time zones where the team works across countries. A review window should begin when the agreed deliverable and supporting material are available to the named reviewer, under the arrangement you have documented.

Separate delivery, acceptance and payment

Documenting payment alongside milestones can make an agreement easier to follow, but submitting work is not the same as acceptance or payment. Record the amount, what makes it due, the review process and the payment deadline.

For illustration, a fictional website fee of $1,000 could be split into $150 for discovery, $250 for design, $350 for development and $250 for testing and handoff. The amounts total $1,000. They are not market-rate advice or a recommended percentage formula.

That payment example covers a broader website engagement than the prototype table above. Do not combine the two as a ready-made contract. Adapt any schedule to the actual scope, currency and terms agreed by both parties.

Before relying on a platform, check its current funding, approval, release, fee and dispute rules. This guide does not establish an automatic release process, a payment-protection guarantee or a rule that silence means acceptance.

Make feedback and revisions manageable

Agree on the number of revision rounds and who will consolidate comments. When submitting a milestone, include a link to the version under review, a short list of completed criteria and any known limitations. Ask the reviewer to confirm acceptance or identify unmet conditions.

Separate corrections to agreed requirements from new preferences or features. A new page or different design direction may need a separate estimate. Record the request, its effect on price and timing, and written agreement before starting the extra work.

If a condition is disputed, refer to the actual wording and evidence. Agree on a clarification rather than rewriting the history of the requirement. Keep a versioned record so everyone knows which scope applies.

Track progress without adding paperwork

A shared spreadsheet can be enough. Include the milestone, deliverable, acceptance conditions, dependency owner, planned date, current status, feedback and acceptance date. Add payment status where relevant, keeping it distinct from delivery status.

Send short updates at the agreed interval: what is ready, what comes next and what needs a decision. If photographs have not arrived, explain the affected milestone and offer options. Early notice is more useful than a confident update that hides a blocked task.

Before starting or handing over

• Confirm included work and exclusions.
• Give each milestone a reviewable deliverable and observable checks.
• Name input owners, the reviewer and actual dates.
• Agree on review windows, revision rounds and changes.
• Record payment terms separately from submission status.
• Check the promised files, supported environments and handoff instructions.
• Document known defects and limitations instead of claiming universal compatibility.
• Keep written acceptance and a record of what remains to be done.

Prepare your ALHarih brief

Use the freelance project brief guide to turn the plan into a brief. Explore the ALHarih talent directory and ask shortlisted specialists to discuss the proposed deliverables, dependencies and availability.

For related guidance, browse ALHarih articles. Public reading and directory pages were checked; authenticated contract and payment flows were not tested for this article. Confirm the current terms through the available workflow rather than treating these fictional examples as platform rules.