Working with a
freelance developer.

01 / How to get started

Describe the job before choosing the tools.

"I build websites" leaves a client guessing. "I will replace the booking spreadsheet with a form, an availability calendar, and confirmation emails" gives you both something to discuss. Start with the problem, then name the work you can take responsibility for.

Build one project someone can use

A booking form that handles a full calendar, an invalid date, and a failed request shows more than a screenshot. Publish the project, explain the decisions, and make it easy to try. Check it on a phone. Follow the same links a visitor would follow.

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.

Leave time for testing, deployment, and handover in the estimate. Those tasks still have to happen after the last component is written.

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 decisions, not just releases.

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: you kept an existing payment provider because switching would have delayed launch; three months later, its missing refund API became a support problem. That is useful material for a retrospective, a portfolio, or a conversation with the next team facing the same choice.

Ask for feedback on a specific piece of work

"Was the handover clear enough for you to deploy without me?" gets a more useful answer than "How did I do?" Ask while the work is still fresh, then make one change to the next handover.

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.