Before hiring a web developer: scope, ownership, and handover questions
A useful proposal starts with an observable outcome and clear boundaries. Write what will be delivered, who owns accounts and files, and how work is accepted before comparing developers.
Start with an outcome brief
Write why you need the project, who will use it, and which decision or action should become easier. “We want a modern website” starts a conversation; “a visitor can find a service and send a clear enquiry from a phone” can be reviewed.
Record what is ready and what needs writing, translation, or entry. State languages, Arabic direction, and priority devices. Do not invent a budget or schedule before the scope is clear.
Define what is in scope
Turn the outcome into pages or records, functions, and states. List forms, search, permissions, integrations, data entry, and testing, then ask the developer to separate inclusions from exclusions.
Make assumptions explicit: who writes copy, supplies images and accounts, and whether mobile, both languages, and content entry are included. Ambiguity becomes a change in price or delivery later.
| Area | Question for the brief | Delivery evidence |
|---|---|---|
| Pages | Which pages and purpose for each? | Page list, internal links, and phone test |
| Functions | What does a user create or send? | Repeatable acceptance scenario |
| Content | Who writes, reviews, and enters it? | Content file and owner per language |
| Integrations | Which accounts, data, and failure fallback? | Successful test and named responsibility |
| Operations | Who runs hosting, updates, and support? | Access guide and service boundaries |
Agree on content and review
Content is part of the project. Attach a page map, available copy and images, and a decision owner for each language. Agree what happens when content is late or changes after design approval.
Define empty states, error messages, and external links. Request real Arabic and English review; do not treat machine translation or placeholder copy as publish-ready.
Write acceptance criteria before building
Give every output a way to inspect it. Write scenarios such as opening a page on a phone, submitting a form with a missing field, switching language, or receiving source files. Acceptance criteria describe behaviour and outcome, not a general preference such as “looks good.”
| Scenario | Expected result | Approver |
|---|---|---|
| Service page | Approved content with no broken link | Content owner |
| Form | Clear success/failure and notification delivery | Enquiry owner |
| Two languages | Equivalent copy and correct direction | Language reviewer |
| Phone | No unintended horizontal scroll; usable controls | User representative |
| Handover | Account and file access plus runnable copy | Project owner |
Ask about ownership and access
Agree in writing who owns the domain, hosting, accounts, data, source code, and designs. The client should know where keys are held, who can change them, and how they are received when the project ends.
Use client-owned accounts where appropriate, and grant the developer access without hiding the owner’s access. Record what is delivered at each stage and any external licences or limits.
| Item | Ownership question | Delivery evidence |
|---|---|---|
| Domain and hosting | Whose account and who holds credentials? | Documented admin invitation |
| Source | Where is the repository and what is delivered? | Buildable source copy |
| Data | How are records and files exported? | Test export with description |
| Designs | Which design files and licences? | Source files and licence links |
| Accounts | How is developer access removed? | Tested removal procedure |
Plan handover and training
Handover is a process, not a final attachment. Request an account, file, configuration, publishing, update, backup, and project-specific restore or export checklist. Perform handover using the client account.
Define role-based training and have another person edit content or follow an enquiry after the developer steps away. Record what remains out of scope and who decides.
| Handover pack | What to inspect |
|---|---|
| Access | Domain, hosting, email, outside services, and keys |
| Source | Repository, configuration, build method, and media |
| Content | Editing method, languages, fields, and errors |
| Operations | Publishing, backup, restore, and agreed monitoring |
| Training | Practical exercise, short guide, and guide owner |
Separate maintenance from change
Define a defect versus a change request. Write support channel, hours, and response expectations if included, plus update, monitoring, and backup boundaries.
Ask about recurring costs, outside services, and what happens if one stops. “Maintenance” does not automatically include content writing, new features, or instant response.
Questions before choosing a developer
Send the same brief to each candidate and request an answer against its scope. These are purchasing questions, not universal terms or Mawaqe3 promises:
- What are the deliverables, stages, and completion criteria?
- What is excluded, and which assumptions shape the price?
- Who owns accounts, source, data, designs, and licences?
- Who writes, enters, and reviews content in both languages?
- How will phone, forms, languages, links, and empty states be tested?
- What does the client receive at handover, and how is access removed?
- What support, maintenance, recurring costs, and change limits apply?
Frequently asked questions
Do I need final specifications before contacting a developer? No, but state what you know and what needs a decision. A good brief reduces guessing without ending discussion.
Should I choose the cheapest proposal? Compare scope, acceptance, ownership, and support before price. The total alone does not describe the result.
Do I automatically own the source code? Ownership and access vary by project; write the terms before signing.
How should I start? Complete the brief, tables, and acceptance criteria, then discuss them and request a detailed proposal.
Discuss your project brief
Share your goals, pages, constraints, and handover responsibilities. Mawaqe3 can help turn them into a scope for discussion.