Working with a
freelance developer.

01 / How to get started

Describe the job before choosing the tools.

Describe the work in terms a client can review. For a booking project: replace the spreadsheet with a form, an availability calendar and confirmation emails. Agree which parts you will build and what the client needs to provide.

Build one project someone can use

Let prospective clients try the booking form. Show how it handles a full calendar, an invalid date and a failed request. Check the same steps on a phone before sharing it.

Write down what counts as finished

For that booking project, decide whether the price includes payments, cancellations, reminder emails, and importing old records. Name who supplies the content and who approves it. Put the milestones and review dates in writing.

Include testing, deployment and handover in the estimate.

02 / Hiring a developer

Ask how the work will be delivered.

Bring the current problem to the first conversation: who uses the system, where they get stuck, and what a successful change would let them do. Mention the deadline, budget range, existing software, and who can make decisions.

Go beyond the portfolio screenshot

• Which parts of this project did you build yourself?
• Can you show what happens when a request fails?
• What did you decide to leave out, and why?
• Who deploys the site, and who fixes problems after launch?

Choose a first milestone you can review

For a booking system, that might be a working request from date selection through to confirmation, using test data. Review it together before expanding the scope. A paid discovery phase can help when nobody yet knows what the existing system will allow.

Check what each quote includes. Content entry, hosting setup, accessibility checks, and ongoing support can change the amount of work considerably. Agree who will control the domain, source code, and hosting accounts when the job is handed over.

03 / Career

Keep a record of project decisions.

A year later, it can be hard to remember why a project was difficult. Keep a short note when you make a consequential choice: the problem, the options, what you chose, and what happened after release.

For example, a team might keep a payment provider to avoid delaying launch, then spend time handling refunds manually because its API lacks that feature. Recording both the deadline and the later support work explains the cost of the decision.

Ask for feedback on a specific piece of work

Ask whether the client could deploy using your handover notes, and where they got stuck. Update those instructions while they still remember the problem.

Account for the work around the code

Estimates, invoices, proposals, support, and learning all take time. If every hour in your calendar is sold as implementation time, those jobs move into evenings. Include them when deciding how much work you can accept.

04 / Before handover

Try the paths a demo tends to skip.

• Open a detail page directly, refresh it, then use Back and Forward.
• Submit an invalid form. Lose the connection during a valid submission. Check that the entered text survives.
• Use the site with a keyboard and at a narrow screen width. Check focus, labels, zoom, and the mobile menu.
• Confirm who has the production accounts and where deployment and rollback steps are documented.
• Check the published files for old pages, unused scripts, and links that only worked locally.
• Repeat performance checks under the same conditions, and keep the measurements with the release notes.