The best questions to ask a web developer are not limited to “How much?” and “How fast?” Price and timeline matter, but they become useful only after you understand the deliverables, exclusions, evidence, ownership, testing, and post-launch responsibility.
Use these questions for a freelancer or agency. Strong answers are specific and tied to your project. Weak answers rely on broad promises such as “professional,” “fully optimized,” or “unlimited support.”
Project fit and evidence
1. Which live project is most similar to mine?
Ask why it is relevant, not only for a link. Similarity may involve the audience, content model, checkout, integration, language, or operational challenge.
2. What did you personally deliver?
A project can involve designers, writers, developers, marketers, and client teams. Clarify the candidate’s actual role.
3. What problem did the project solve?
Look for an answer about enquiries, sales, content management, booking, workflow, speed, or reliability—not only visual style.
4. When would you recommend a freelancer, agency, or internal team?
A balanced answer acknowledges capacity and specialist limits. Read freelance web developer vs agency before making the delivery-model decision.
Scope and technology
5. What exactly is included in the proposal?
Require pages or workflows, components, content responsibilities, integrations, testing, deployment, documentation, and handover.
6. What is excluded?
Exclusions protect both sides. Common examples include copywriting, translation, photography, provider fees, product entry, complex integrations, and ongoing maintenance.
7. Why do you recommend this technology?
The answer should connect editing, integrations, hosting, performance, security, team skills, and ownership. A preferred stack is not automatically the right stack.
8. What can our team edit after launch?
Ask for a demonstration of the editing workflow and confirm who will receive training or documentation.
9. Which third-party services and licenses are required?
Record provider, purpose, renewal price, account owner, transferability, and what happens if the service ends.
Content, search, and measurement
10. Who supplies and approves the content?
Define copy, translation, images, products, policies, case studies, and deadlines. Content delay is a common schedule risk.
11. What SEO foundations are included?
Look for page intent, headings, metadata, internal links, canonicals, sitemap, robots rules, redirects, structured data where appropriate, and performance. One plugin is not an SEO plan.
12. How will analytics and Search Console be configured?
The business should control the accounts. Agree on important events such as qualified form submissions, phone or WhatsApp contact, purchases, and bookings.
13. How will accessibility and mobile behavior be tested?
Ask about keyboard access, labels, contrast, responsive layouts, touch targets, forms, and real devices or browser tools.
Delivery and quality assurance
14. What are the milestones and approval points?
Milestones should produce reviewable work: structure, design direction, functional build, content population, testing, and launch.
15. How are change requests handled?
Confirm how a request is assessed, approved, priced, and scheduled when it is outside the original scope.
16. How do you test forms, payment, integrations, and failure states?
Happy-path screenshots are not enough. Ask about validation, errors, emails, permissions, payment states, browsers, and rollback.
17. What can delay the launch?
A credible developer names dependencies: content, access, payment-provider approval, DNS, integrations, client decisions, and third-party review.
Read how long website development takes for a phase-by-phase view.
Ownership and support
18. Who owns the domain, hosting, code, design, data, and accounts?
Put the answer in writing. Use who owns a website after development as the handover checklist.
19. What happens during handover?
Expect access, files or repository, deployment notes, account list, backup status, analytics, training, and known limitations.
20. What support is included after launch?
Separate warranty fixes from maintenance, content changes, improvements, monitoring, and urgent support. Define duration, response expectations, and exclusions.
How to interpret the 20 answers
Use this table during the interview. It helps distinguish a concrete delivery answer from a reassuring phrase.
| Question | A useful answer gives you | Investigate further when |
|---|---|---|
| 1. Similar work | A live URL, the relevant similarity, and a constraint they solved | You only receive screenshots or an unrelated template |
| 2. Personal role | A clear boundary between their work, partners, and the client’s work | They imply responsibility for everything but cannot explain decisions |
| 3. Problem solved | The original problem, chosen measure, and result or learning | Success is described only as “modern design” |
| 4. Delivery model | Honest limits around capacity, disciplines, and continuity | Every project is said to fit their preferred model |
| 5. Inclusions | Named templates, workflows, integrations, testing, launch, and handover | The quote relies on “complete website” with no inventory |
| 6. Exclusions | A visible list and a process for newly discovered work | Ordinary launch requirements appear later as surprise extras |
| 7. Technology | A decision connected to editing, users, risk, hosting, and future work | The stack is chosen because it is fashionable or always used |
| 8. Editing | A demonstration, roles, guardrails, and training plan | “Everything is editable” but no workflow can be shown |
| 9. Providers | Purpose, owner, renewal, data, transferability, and exit path | Essential services are hidden under the supplier’s account |
| 10. Content | An owner, inventory, format, deadlines, approval flow, and fallback | Placeholder content is assumed to become final by itself |
| 11. SEO | Page intent, crawl/index controls, metadata, redirects, performance, and measurement | SEO means installing a plugin or submitting a sitemap only |
| 12. Measurement | Client-owned accounts and defined conversion events tested after launch | Only page views are mentioned, or accounts remain supplier-owned |
| 13. Accessibility/mobile | Specific keyboard, form, contrast, responsive, zoom, and device checks | The answer is “the theme is responsive” |
| 14. Milestones | Reviewable outputs and one named approval route | Payments are tied only to dates or vague completion percentages |
| 15. Changes | A written request, impact estimate, approval, and schedule update | Changes happen through chat with no record of cost or timing |
| 16. Testing | Test cases for success, validation, errors, integrations, and recovery | Only the happy path is demonstrated |
| 17. Delays | Client, supplier, and third-party dependencies with owners | The provider guarantees a date before understanding dependencies |
| 18. Ownership | An asset-by-asset answer written into the agreement | Paying the invoice is treated as the complete ownership plan |
| 19. Handover | Access list, files, repository, documentation, training, and backup status | Handover means sending one administrator password |
| 20. Support | Warranty boundary, maintenance options, response expectations, and escalation | “Lifetime” or “unlimited” support has no written service boundary |
Not every warning sign disqualifies a candidate. It tells you which assumption must be resolved and written down before the project starts.
Prepare before the interview
Send a short brief at least far enough in advance for the candidate to review it. Include the business goal, audience, current site if any, page or workflow inventory, languages, integrations, content status, launch driver, budget context, and internal decision maker. Mark requirements as essential or optional.
Bring the same three scenarios to every interview. For example: a form submission fails, a stakeholder requests a new workflow after design approval, and the original developer is unavailable during a hosting problem. Ask how each candidate would communicate, diagnose, document, and resolve the situation. Comparable scenarios produce more useful evidence than a free-form sales conversation.
Do not share passwords during evaluation. Screenshots, read-only analytics, or a supervised review can provide context. Grant scoped access only after the supplier, purpose, and account ownership are clear.
Use a weighted scorecard when the risk is meaningful
The four categories above can become a consistent shortlist tool:
| Category | Example weight | What earns the score |
|---|---|---|
| Project understanding and scope | 25% | Useful questions, explicit assumptions, prioritized solution |
| Relevant evidence | 25% | Live comparable work, clear personal role, references if justified |
| Quality and verification | 20% | Appropriate testing, accessibility, performance, security, and search process |
| Communication and delivery | 15% | Named owner, consolidated feedback, milestones, change control |
| Ownership and continuity | 15% | Client accounts, transferable assets, documentation, support boundary |
Adjust the weights before opening proposals. If a site handles important transactions, quality and continuity deserve more weight. If the project is a focused campaign page, message clarity and delivery speed may matter more. Record one sentence of evidence for each score so enthusiasm from the last call does not replace comparison.
Verify answers after the meeting
Ask for the proposal to restate important verbal answers. Check one or two references when project risk justifies it, but ask specific questions: Was the assigned team stable? Were changes visible before billing? Could the client control accounts and update content after handover? How did the provider respond when something went wrong?
Review a live example yourself. Test mobile navigation, keyboard focus, forms, basic page speed, content clarity, and whether the experience matches the claimed role. A former client may have changed the site, so discuss findings rather than treating one automated score as a verdict.
Convert the chosen answers into the agreement
The interview is useful only if the decisions survive into delivery. Attach or reference the final scope, exclusions, client responsibilities, provider costs, milestones, acceptance checks, change process, account ownership, intellectual-property terms, support period, and exit or termination process.
Create an account register during kickoff rather than waiting for handover. It should list the domain registrar, hosting, CMS, repository, analytics, Search Console, tag manager, email delivery, payment, maps, plugins, and backups, with the business as owner wherever practical. This single document reduces dependence and makes the final handover verifiable.
How to score the answers
Do not create a complicated points system. Use four categories:
- Evidence: relevant live work and a clear explanation of personal responsibility.
- Clarity: written deliverables, exclusions, dependencies, and decisions.
- Control: client-owned accounts, transferable assets, and documented handover.
- Verification: named checks for mobile, forms, performance, accessibility, search, and launch.
A candidate can be technically strong but unsuitable if communication and ownership remain vague. The goal is not to catch someone with trick questions; it is to establish whether both sides can deliver the same agreed project.
Frequently asked questions
Should I send these questions before a meeting?
Send the project brief first and use the meeting for the questions that materially affect fit, scope, risk, and ownership.
Is the cheapest quote a red flag?
Not automatically. It may reflect a smaller scope or lower overhead. Compare what is included, excluded, and verifiable before judging the number.
How many developers should I interview?
Enough to compare different approaches without turning the process into unpaid consulting. A clear brief sent to a small shortlist is usually more useful than many vague calls.
What should I do after choosing?
Translate the agreed answers into a written scope, milestones, payment terms, responsibilities, acceptance checks, ownership, and support terms.
