Client Project Portal with Milestones, Approvals and Change Requests

The problem freelancers have with scope and approvals

Freelance projects rarely fail on the code. They fail on scope: unclear deliverables, endless revisions, extra requests that nobody priced, and disputes where neither side can prove what was agreed. A developer quotes for a five-page website, the client asks for "one small change" eleven times, and by the end the effective rate has halved. When the client refuses to release the final payment, the only evidence is a long WhatsApp chat.

Marketplaces solve part of this. Upwork and Fiverr hold milestones and record deliveries, so disputes have a paper trail. But as soon as a freelancer works with a direct client, which is where the better-paid work usually is, that structure disappears. Small agencies with three or four people have the same problem with every client.

What already exists and the gap

• Upwork offers fixed-price contracts with funded milestones, submissions and approvals, but only inside the marketplace and with its fees.
• HoneyBook and Moxie are all-in-one freelancer business tools with proposals, contracts, invoices and a client portal.
• Plutio adds project management with milestones, tasks and time tracking feeding into invoices.

These tools are strong on proposal-to-invoice paperwork. The gap is scope control as a first-class object: a locked scope, a counted revision limit, and a formal change request that must be priced and accepted before extra work begins, with every step in an immutable log. Most freelancers still handle revisions and scope creep in chat. The pricing of these tools is also aimed at established Western freelancers, which puts them out of reach for many students starting out.

What you build

A shared portal per project with two roles:

• Freelancer: drafts the scope and milestones, submits deliveries, raises change requests, sees the full history.
• Client: reviews and accepts the scope, approves deliveries or asks for revisions, accepts or declines change requests.

Main flows: draft scope, both sides accept and it locks; work through milestones; submit a delivery; the client approves or returns it within a revision round; any new request becomes a change request with price and date impact; the project closes when every milestone is approved.

The technically interesting part

The core is explicit state machines with an audit trail. A milestone can only move from delivered to approved or to revision requested; a change request can only be accepted once; a locked scope cannot be edited, only amended through an accepted change request. Model these transitions as data (allowed from, to, and which role may trigger them) and reject everything else on the server.

The activity log should be append-only: write an event for every transition and never update or delete rows. You can then rebuild the current state of a project from its events and prove to your evaluators that the log and the state agree. This is the same event-sourcing idea behind audit logs in payment systems, applied at a scale a student team can finish. Scheduled reminders (approval window about to expire) add a small but real background job.

How to evaluate it

• Transition tests: a table-driven test covering every allowed and forbidden transition for milestones and change requests, all passing.
• Replay check: rebuild the state of 20 seeded projects from the event log and show it matches the stored state.
• End-to-end: a Playwright test of a full project from scope draft to final approval, including one revision and one change request.
• Usability: run it on a real small project with one freelancer and their client, or 5 pairs of classmates role-playing; record where they got confused and how long each flow took.

Suggested plan

1. Weeks 1 to 2: interview three freelancers about disputes and scope creep; write the state diagrams.
2. Weeks 3 to 5: roles, invites, projects, scope with locking.
3. Weeks 6 to 8: milestones, deliveries, revisions, the event log.
4. Weeks 9 to 11: change requests, reminders, PDF export of the log.
5. Weeks 12 to 15: pilot with a real freelancer, tests, write-up.

Path to a product

Your first customers are freelancers you know, including students already selling on Fiverr or Upwork who are moving to direct clients. Offer a free tier with one active project and a small monthly fee for unlimited projects. Small web and design agencies are the next step, with a per-seat plan. Grow through a "powered by" link on every client portal.

Scope warning

Do not handle payments or escrow; record amounts and statuses only. Do not build chat, a task board or time tracking. Keep file storage simple. Clear flows and correct state transitions matter more than feature count.

Learn what you need on Sefism

• Backend roadmap : APIs, auth and data modelling for the server side.
• Backend cheat sheet : quick reference for validation, transactions and background jobs.
• Freelancers Union Contract Creator : see what a real freelance agreement contains before you design the scope page.
• Upwork Help Center for freelancers : how a marketplace handles milestones and disputes.
• Should I start with freelancing or get a job first? : the users of this tool are asking exactly this.

Get help with this idea

Most of the marks here come from the state machines, the event log and a real pilot. Tauseef can help you draw the right states, cut features that do not serve scope control, and plan an evaluation that shows correctness. If you are new here, create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session