How to Choose a Web Development Company (10 Questions to Ask)

You have three quotes in front of you. One is ₹60,000, one is ₹2,50,000, and one is ₹9,00,000 — apparently for the same website. All three portfolios look reasonable. Every proposal promises a responsive, SEO-friendly, fast website delivered on time, and you have no reliable way to tell which of them is telling the truth.

That is the actual problem with figuring out how to choose a web development company: the marketing material is identical across the entire market, so it carries no information. What separates a good vendor from a bad one shows up in how they answer specific, slightly awkward questions. Below are ten of those questions, why each one works, and what a good and bad answer sounds like.

We are a web development company ourselves, which you should factor in. We have tried to write questions that would be uncomfortable for us to dodge, and we are not going to tell you that any particular size or type of vendor is the right answer — because it depends entirely on what you are building.

Before the questions: know what you are actually buying

Three very different products share one name

Much of the confusion in quotes comes from clients and vendors using "website" to mean different things.

• A marketing site. Five to twenty pages, a contact form, a blog. This is largely a content and design exercise. Realistic range in India: ₹40,000 to ₹3,00,000 depending on design depth and content production.
• A transactional site. E-commerce, bookings, memberships. Payments, inventory, accounts, order states. Realistic range: ₹2,00,000 to ₹15,00,000, with the top end for multi-vendor or unusual logic.
• A custom application. Software that runs a part of your business, with roles, workflows, and integrations. Effectively a bespoke product build, priced accordingly and requiring an ongoing relationship.

Wildly divergent quotes usually mean the three vendors assumed three different products. Get everyone quoting the same scope before you compare numbers.

Write down your one measure of success

"A better website" is unmeasurable. "Thirty qualified enquiries a month", "checkout completion above X%", "our sales team stops re-typing orders" — these are testable. A good vendor will ask you for this. If none of your candidates does, that itself is a finding.

The ten questions

Question 1: Who exactly will write the code, and where do they sit?

You want names, roles and location. The common failure is meeting a polished senior person during the sales process and then being handed to a junior nobody mentioned, or discovering the work has been passed to a subcontractor.

Good answer: a named developer or small team, their experience level, and honesty about who does what. "Your backend will be built by two developers with three and five years of experience, reviewed by our tech lead."

Bad answer: "We have a team of 50+ experts." That is a headcount, not an answer. Also ask directly whether any part will be subcontracted. Subcontracting is not automatically bad, but concealing it is.

Question 2: Show me something you built two or more years ago that is still running

Portfolios show launch-day screenshots. Anyone can make something look good on launch day. What you want to know is whether their work survives contact with reality.

Good answer: live URLs of older projects, ideally with a note on what has changed since. A vendor comfortable with this has clients who stayed.

Bad answer: evasion, or a portfolio consisting entirely of projects from the last six months. That pattern suggests either a very new company (fine, if disclosed) or a client base that does not renew.

Follow up by asking for a reference client you can phone. Ask that client one question: what went wrong during the project and how was it handled? Every project has something go wrong. The answer tells you about behaviour under pressure.

Question 3: What happens if I want to leave you in year two?

This is the single most revealing question in the list, and the one bad agencies hate.

Good answer: your code lives in a repository you own or can be transferred, hosting and domain are in your accounts, third-party services are registered under your email, and handover documentation exists. There may be a fee for handover work, which is fair.

Bad answer: hesitation, or "we host everything for you" said as a benefit. Some vendors keep the domain registered to themselves, hold the hosting account, and use platform lock-in as a retention strategy. Ask explicitly: in whose name will the domain be registered? If the answer is not "yours", walk away.

Question 4: What is not included in this price?

Every quote has exclusions. The question is whether they are disclosed now or invoiced later.

Check specifically for content writing, photography, stock image licences, third-party licences and plugin costs, payment gateway setup and its transaction fees, SSL, hosting, email hosting, data migration from an old site, training, and post-launch support duration.

Good answer: a written exclusions list, and honesty that content is usually the client's responsibility and usually the thing that delays projects.

Bad answer: "everything is included." Nothing is everything. This phrase reliably precedes change-request invoices.

Question 5: How do you handle changes to scope during the project?

You will change your mind. It is normal. What matters is whether there is a mechanism.

Good answer: a defined process — changes are estimated in writing and approved before work starts, with small tweaks absorbed within reason. Some vendors offer a change budget as a contingency line. That is a sign of experience.

Bad answer: "we are flexible, no problem." This means either that every change becomes an argument later, or that the vendor has priced in a large buffer and you are paying for changes you may never make.

Question 6: What technology will you use, and why that rather than something simpler?

The "why not simpler" clause is what makes this question work. Anyone can name a stack.

Good answer: a justification connected to your requirements, and evidence they considered the cheaper option. "WordPress with a well-chosen theme fits what you have described; a custom build would cost four times as much and would not do more for you." A vendor willing to talk you down is worth serious attention.

Bad answer: a stack chosen because it is what they always build, or fashionable technology proposed for a five-page brochure site. Over-engineering is as expensive a mistake as under-engineering, and much harder to spot at the time.

Question 7: What is your definition of done, and how will I test it?

Disputes at the end of projects are almost always disputes about what "finished" meant.

Good answer: a written acceptance process. Which browsers and devices are tested, what performance target the site must meet, an accessibility standard if relevant, a defined UAT period during which you test against agreed criteria, and how many rounds of fixes are included.

Bad answer: "when you are happy with it." That sounds generous and protects nobody. It leaves both sides without a stopping point.

Push on mobile specifically. Most of your Indian traffic will arrive on a mid-range Android phone over mobile data. Ask what device the site will be tested on and what the target load time is on a 4G connection.

Question 8: What does support cost after launch, and what does it cover?

Launch is the start of the cost, not the end of it.

Good answer: a clear distinction between bug fixes (defects in what was delivered, fixed free within a stated warranty period, typically 30 to 90 days) and maintenance (updates, backups, security patches, small changes — a monthly retainer, commonly ₹3,000 to ₹25,000 depending on the system). Response times should be stated.

Bad answer: no distinction between the two, so that fixing their own defect becomes a billable request. Or no support offer at all, which means you are on your own with a codebase you cannot read.

Question 9: How do you handle security and data protection?

Relevant to any site that collects customer information, and essential for anything handling payments.

Good answer: specifics. HTTPS everywhere, how passwords are stored, how file uploads are validated, what backup schedule exists and whether restores have actually been tested, who has production access, how dependencies get updated, and awareness of India's data protection obligations for personal data. For payments, a reputable gateway so card data never touches your server.

Bad answer: "we use SSL, it is fully secure." SSL protects data in transit and nothing else. An untested backup is not a backup — ask when they last performed a restore.

Question 10: What could go wrong with this project, and what would you do about it?

Ask this last, and pay close attention to whether the vendor is willing to be negative in a sales conversation.

Good answer: real risks named plainly. Content delays from your side. Integration with an old system whose API is undocumented. A payment gateway approval that takes longer than expected. Approval bottlenecks if too many stakeholders review. Each with a mitigation.

Bad answer: "nothing, we have done this many times." Either they have not thought about it or they are unwilling to tell you uncomfortable things. Both predict a difficult project, because the moment something does go wrong you will hear about it late.

Reading the quotes side by side

On the cheapest quote

Very low quotes are not always bad — a genuinely small team with low overheads can deliver a simple site cheaply and well. The risk is not the price itself but what the price implies about time allocated. Ask how many hours they have budgeted. If a ₹60,000 quote implies twenty hours of work for what is realistically an eighty-hour job, the shortfall gets absorbed by skipping testing, using an unmodified template, or abandoning the project once it stops being profitable.

On the most expensive quote

Higher price should buy something identifiable: senior people, a proper discovery phase, design iterations, testing, documentation, accountability. If a premium quote cannot point to what the extra money buys, it is just a higher margin.

Things that are not useful signals

• Awards and badges. Most are paid placements or directory listings.
• Client logos. A logo may represent one small job done for a large company's regional office.
• Team size. Larger does not mean better staffed on your project; it often means more layers between you and the developer.
• A beautiful agency website. It proves they can build one site well — their own, with no client, no deadline and no budget.
• Years in business alone. Useful context, but a five-year-old company that has not shipped anything ambitious is not safer than a two-year-old team that has.

Our recommendation

Shortlist three vendors, put the same written scope in front of all of them, and run all ten questions in a live conversation rather than by email — you learn as much from hesitation as from content. Weight questions 3, 6 and 10 most heavily: ownership and exit, willingness to recommend something simpler, and willingness to name risks. Those three predict how the relationship goes when the project gets difficult.

Then, before signing anything large, buy something small. A landing page, a single integration, a design phase paid separately. A ₹40,000 trial engagement tells you more about how a company communicates, estimates and delivers than any number of reference calls. If that goes well, commission the rest. If it does not, you have lost a small amount instead of a large one, and you still own everything you paid for.