Questions to Ask Before Hiring a Web Developer

The best hiring questions reveal how a developer makes decisions, verifies work and transfers ownership. They are more useful than asking whether the developer can make a site “modern, responsive and SEO-friendly.”

A brochure website, lead-generation site, ecommerce store and authenticated web application have different risks. Before comparing providers, define the business outcome and request written answers about scope, evidence, delivery, testing, accounts and support.

This checklist is designed for Indian small businesses evaluating an independent developer, agency or software company. It helps structure due diligence; it does not guarantee project success or replace legal, financial or security advice.

Quick Shortlist Questions

Ask these before a long sales call:

1. What exact business outcome and users do you understand from our brief?
2. Which deliverables are included and explicitly excluded?
3. Can you demonstrate relevant live work and explain your contribution?
4. Who will own the domain, hosting, repository, analytics and business accounts?
5. How will design, content, testing and approval be handled?
6. What happens when requirements change?
7. What is tested before launch, and what evidence will we receive?
8. What support is included after launch?

Clear, specific answers are a stronger signal than a large feature list.

First Classify the Project

If users must log in, manage records or complete business workflows, evaluate web application services rather than treating the work as a standard website package.

1. Questions About Discovery and Scope

Ask:

• What information do you need before estimating?
• Which pages, templates and user journeys are included?
• Who writes and approves the content?
• Are legal pages, images, icons and copy included?
• Which integrations are included?
• What assumptions affect the price or timeline?
• What is explicitly out of scope?

A provider should be able to translate the requirement into pages, states, responsibilities and acceptance criteria. Be cautious when a fixed quote is offered before anyone asks about content, integrations or approvals.

Use a written website development brief so every vendor prices the same baseline.

2. Questions About Evidence

Ask for evidence appropriate to the work:

• live URLs rather than screenshots alone;
• an explanation of what the provider personally delivered;
• a walkthrough of mobile behaviour and key flows;
• performance or accessibility evidence when those claims are made;
• a clear distinction between templates, demos and client work;
• permission to use any named client result.

Do not demand confidential source code or private analytics. A responsible provider may be limited by client agreements. They should still be able to discuss process, trade-offs and non-confidential evidence.

The fake portfolio detection guide provides a separate verification workflow.

3. Questions About Design and Content

Ask:

1. How will the information architecture be approved?
2. Will we review wireframes or content hierarchy before visual polish?
3. Is the design custom, adapted from a system or based on a purchased template?
4. How many meaningful revision rounds are included?
5. Who supplies final copy and images?
6. How will the design remain consistent across new pages?
7. Which mobile widths and interaction states will be checked?

“Unlimited revisions” often hides an undefined process. A better agreement identifies review stages, decision owners and what counts as a scope change.

4. Questions About Accessibility

Ask whether the delivery covers:

• keyboard navigation;
• visible focus states;
• field labels and error messages;
• meaningful image alternatives;
• readable colour contrast;
• sensible heading order;
• reduced-motion behaviour where animation is used;
• touch-target and mobile zoom usability.

Accessibility should be part of design and QA, not a last-minute plugin. Ask what standard or practical checklist the provider uses and what limitations remain.

5. Questions About Performance

Instead of asking, “Will it be fast?”, ask:

• What is likely to be the largest content element?
• How will images be resized and compressed?
• How are fonts loaded?
• Which features require client-side JavaScript?
• Will third-party scripts be delayed where practical?
• How will performance be tested on mobile conditions?
• Are any score targets written as goals rather than guarantees?

Lab scores vary by device, network and test conditions. Request the URL, test date and major findings rather than a cropped score image. See the website speed optimisation guide for a technical checklist.

6. Questions About SEO Foundations

A website developer can provide technical and on-page foundations, but cannot guarantee rankings.

Ask whether indexable pages will receive:

• descriptive URLs;
• unique titles and meta descriptions;
• one meaningful primary heading;
• self-referencing canonical URLs;
• crawlable internal links;
• XML sitemap and robots rules;
• suitable structured data;
• redirect mapping during migrations;
• Search Console and analytics handover.

Ask to see these values in rendered HTML or a build output, not only in a spreadsheet. For a redesign, old URLs and incoming links need a migration plan.

Review the SEO-friendly website development guide before approving “SEO included” as a deliverable.

7. Questions About Forms and Analytics

Ask:

1. Where are submissions stored or delivered?
2. What server-side validation and spam protection are used?
3. Who monitors failed delivery?
4. What success state does the user see?
5. Which analytics events are implemented?
6. Are personal form values excluded from analytics?
7. Who owns the analytics and tag-management accounts?

Tracking a submit-button click is not the same as tracking a confirmed lead submission. The contact page design guide explains the difference.

8. Questions About Security and Privacy

The appropriate controls depend on the data and functionality. Ask:

• Will HTTPS be enforced?
• How are dependencies and security updates managed?
• Where are secrets stored?
• How is administrator access protected?
• Are roles enforced on the server for authenticated applications?
• What data is collected, retained and backed up?
• How are incidents or vulnerabilities reported?
• Who is responsible for legal notices and consent language?

If the project handles payments, health data, identity documents or sensitive business records, request a deeper security review and appropriate professional advice. A generic website checklist is not enough.

9. Questions About Ownership and Accounts

The contract and handover should identify ownership of:

• domain registration;
• DNS and hosting;
• source repository;
• content and original design assets;
• paid themes, plugins and licences;
• analytics, Search Console and tag manager;
• form, email, payment and messaging accounts;
• databases and backups.

The business should normally control its core accounts and grant the provider the access required to work. Ask whether source code and exportable data will be available if the relationship ends.

10. Questions About Timeline and Dependencies

Ask for milestones tied to visible output:

Also ask what happens when content, feedback or third-party approval is late. A timeline without client dependencies is not a complete plan.

11. Questions About Pricing and Payment

Ask:

• Is the quote fixed, time-based or phased?
• What is the advance linked to?
• Which milestone triggers each payment?
• How are change requests estimated and approved?
• Are taxes and third-party costs included?
• What is withheld until handover or launch?
• Are maintenance and hosting separate?

Connect payments to defined outputs and acceptance rules. Use the safe website payment milestone plan and the website project agreement guide as discussion inputs.

12. Questions About QA and Launch

Ask for a launch checklist covering:

• mobile and desktop layouts;
• navigation and internal links;
• forms and notification delivery;
• browser checks;
• metadata, canonical and indexability;
• sitemap and robots;
• accessibility basics;
• performance findings;
• analytics events;
• redirects;
• backup and rollback.

Ask who can approve a known limitation and how unresolved issues are documented. “Tested by the developer” is not enough detail for a business-critical workflow.

13. Questions About Support and Maintenance

Clarify:

• the post-launch defect window;
• the difference between a defect and a new request;
• response expectations;
• update, backup and monitoring responsibility;
• maintenance pricing;
• emergency contact process;
• termination and handover procedure.

Maintenance does not mean unlimited redesign work. The business website maintenance guide helps define recurring responsibilities.

Red Flags That Need More Investigation

• Guaranteed Google position or lead count.
• Pressure to pay fully before written scope.
• Refusal to explain account ownership.
• Portfolio screenshots with no verifiable context.
• No distinction between bug fixes and new scope.
• Credentials shared in chat without a secure process.
• Copied content presented as an SEO strategy.
• “Everything included” without exclusions.
• Production launch without backup or rollback.
• No response when asked how form delivery is verified.

A red flag is a reason to ask for evidence, not always an automatic rejection. Small providers may use a simple process and still deliver responsibly; large teams can also leave ownership unclear.

Weighted Vendor Scorecard

Score each area from 0 to 5 and multiply by the weight:

Use notes beside each score. The exercise prevents a polished sales call from outweighing operational risk.

Current VASUYASHII First-Party Boundary

VASUYASHII’s own website and content demonstrate our current approach to final-domain canonicals, static rendering, privacy-safe interaction events, responsive delivery and written scope guidance. That is process evidence, not a claim that every prospective project will achieve a particular ranking, speed score or revenue result.

We scope websites, software development and integrations according to the approved requirement. Any proposal should identify its own deliverables, limitations and acceptance process.

FAQs

How many vendors should a business compare?

Two or three serious proposals are usually more useful than a large list of shallow quotes. Give each vendor the same written brief.

Should I hire the cheapest web developer?

Choose the proposal that best controls the required outcome and risks. A smaller price can be appropriate when the scope is genuinely smaller and ownership remains clear.

Do I need a contract for a small website?

At minimum, document scope, price, payment, timeline, revisions, ownership, support and cancellation terms. Obtain legal advice when the risk or value warrants it.

Who should own the domain and hosting?

The business should normally control its domain and core business accounts. The provider can receive role-based access needed for delivery.

Can a developer guarantee SEO results?

No responsible developer can guarantee a Google position. They can commit to specific technical, content and measurement deliverables.

Should I ask for source code?

Clarify this before work starts. Custom development commonly includes agreed repository access, while managed platforms, licensed themes or proprietary services can have different terms.

What should happen before final payment?

Complete agreed acceptance checks, resolve or document remaining issues, transfer access, confirm backups and deliver the promised handover material.

Next Step

Send every shortlisted provider the same brief and ask for written answers to the shortlist questions. Compare evidence, ownership and delivery control before comparing optional features. To discuss a scoped VASUYASHII project, use the contact page.