Choose a developer by examining how they work as well as what their portfolio looks like. A screenshot can demonstrate visual direction, but it cannot establish who built every part, how the system performs or whether the client owns the necessary accounts.
Ask what the example represents
For each relevant project, ask whether it is a live production site, a public preview or an interface study. Clarify the developer's role, the version shown and which outcomes were measured. A client's current website may have changed after a handover, so a live link and an archived capture can show different work.
Our Emberwell concept project and other selected projects provide interfaces and scope to discuss. They should be assessed as evidence of the described work, not as an implied endorsement from every brand or a guarantee of business results.
Ask for a written scope
- What content and assets must you supply?
- Which pages, workflows and integrations are included?
- How are revisions, approvals and change requests handled?
- What tests determine whether the work is ready to launch?
- Which recurring charges and support responsibilities remain afterward?
For a redesign, ask how useful existing URLs and content will be handled. For ecommerce, ask about real test orders and failure scenarios. For a custom application, ask about permissions, backups and deployment ownership.
Keep control of the essentials
Agree ownership of the domain, hosting, source code and third-party accounts. Ask what documentation and training accompany the handover. A supplier should explain what another competent developer would need to continue the work.
Look for clear answers about limitations as well as capabilities. Guaranteed rankings, unsupported revenue claims or unexplained ownership restrictions deserve further questions.
Use the same comparison sheet for every quote
Send each shortlisted developer the same brief and ask them to answer these points in writing. A low total is difficult to compare when one proposal excludes the content or handover you need.
- Deliverables: List the actual pages, content writing, image preparation and enquiry workflow included. Separate a brochure site from booking, ecommerce or custom application work.
- Your contribution: Name the photos, service details and approvals you must provide, with dates. Ask how missing content affects delivery.
- Launch acceptance: Ask for a phone demonstration, a verified test enquiry and a check of important old URLs. Agree who signs off before the domain changes.
- Ownership and exit: Identify who controls the domain, hosting, source and editing accounts. Ask what you receive if another developer takes over.
- Recurring costs: Separate hosting, domains, licences and ongoing care from the build price. Record which charges can change and who pays each supplier.
- Aftercare: Ask how defects are distinguished from new features, how to report a problem and which response arrangements are included.
For a George business, also agree whether a face-to-face discovery meeting is useful and who will keep local contact and service-area information accurate. A local address alone does not demonstrate technical ability; review a relevant project and the proposed delivery process.
Our Paws On Route case study is a service-business example to discuss alongside the concept work. For a starting brief, use what a George business website needs to do. For launch acceptance, follow the enquiry journey checklist.
Compare like for like
Use the budgeting guide to separate scope from price. Then discuss your most important customer journey with the person responsible for delivery. You can meet Pixaloom and review our website design process before deciding whether the studio is a fit.
