A freelance development proposal works when it defines what "done" means in testable terms, splits the build into milestones that are each paid on delivery, and states in writing that new requirements are new scope. Everything painful about client dev work — endless tweaks, moving targets, unpaid debugging — traces back to a proposal that skipped one of those three.

Define done, or the project never ends

"Build a booking system" is not a scope; it is an argument waiting to happen. Does it include email notifications? Refunds? Admin reporting? Time zones? Write acceptance criteria the client can verify without reading code:

  • "A visitor can book a slot, pay by card, and receive a confirmation email."
  • "An admin can view, cancel, and refund bookings from a dashboard."
  • "Works on current Chrome, Safari, Firefox, and mobile browsers."

When the client later asks for SMS reminders, you are not the difficult one — the criteria are. That feature simply was not on the list, and now it can be quoted.

Milestones beat hourly, and beat one big invoice

Hourly billing punishes you for being fast and makes clients audit your timesheet instead of your results. One payment at the end concentrates all the risk on you. The structure that works for most freelance dev projects:

  • Deposit (25–50%) to book the work and cover setup
  • Two or three milestones, each a demoable slice — "auth and user accounts working," "payments live in test mode"
  • Final payment before production deploy or handover of repository access

Each milestone is paid when its acceptance criteria pass. If the client goes quiet mid-project, you are only ever one unpaid milestone deep — not three months deep.

The "simple feature" objection

Every developer hears it: "it is just a button" or "can you quickly add login with Google?" Clients are not being cynical — they genuinely cannot see the auth flows, edge cases, and testing behind small-looking features. Your proposal should pre-empt this with one honest line: estimates cover the listed features only, and additions — however small they appear — are estimated separately. Saying it before the project starts is a policy; saying it mid-project sounds like an excuse.

Handle the maintenance question up front

Code does not stay done. Dependencies get security patches, APIs deprecate, PHP and Node versions age out. If your proposal is silent on this, the client assumes lifetime free support. Include a warranty window — 14 or 30 days of bug fixes on delivered scope is common — and then either a monthly maintenance retainer or an hourly rate for future work. Distinguish clearly between a bug (delivered feature not meeting its acceptance criteria) and a change (anything else). That single definition prevents most support disputes.

Say who owns the code and where it lives

Spell out that the client owns the delivered code on final payment — and that ownership transfers on payment, not before. Note anything that stays yours or third-party: your starter boilerplate, open-source licenses, their responsibility for hosting, domain, and API costs. Clients rarely ask about this up front, but it is the first thing their next developer or their lawyer will ask about later.

Send it fast, make paying faster

Dev leads go cold quickly — a prospect comparing three freelancers usually hires the one who responds like a professional first. A proposal that arrives within a day, reads clearly, and lets the client pay the deposit in one click beats a longer, cheaper one that arrives next week. That is the gap Tendrly closes: answer five questions about the project and it produces a branded proposal with a one-click Stripe payment link, so the deposit that starts the clock arrives while the client is still excited.

FAQ

Should freelance developers bill hourly or fixed price?

Fixed price per milestone for defined projects — it rewards your speed and gives clients cost certainty. Keep hourly only for open-ended maintenance or exploratory work.

How do I handle a client who keeps adding "small" features?

Point to the acceptance criteria in the proposal and quote each addition separately. If the proposal said additions are estimated as new scope, this is policy, not conflict.

When should I hand over the code repository?

On final payment. Deliver demos and staging access throughout the project, but transfer repository ownership and production credentials only after the last invoice clears.