Web Development Company in Pune: Twelve Questions to Ask Before You Request a Quote

Web Development Company in Pune: Twelve Questions to Ask Before You Request a Quote

The best way to shortlist a web development company in Pune is to stop comparing portfolios and start comparing answers. Look at work they have actually built, ask twelve specific questions about who does the work, how it is built, who owns it, what happens after launch and what is not included, and drop any company that answers vaguely. A polished portfolio shows what a team could produce once; the answers show how the project will run for you, and that is what decides whether you are happy in month six.

This article is for a business owner, operations head or marketing manager who has a list of five or six names and has to reduce it to two or three before asking for proposals. It is not a ranking of companies and does not recommend one. It gives you a structured way to run a first call, the answers that should reassure you, the answers that should worry you, and a simple scoring sheet. Where we mention our own company, Govindani Infotech Pvt. Ltd., we say so plainly, because you are entitled to apply the same questions to us.

Why shortlisting goes wrong

Most shortlists are built from three inputs: a Google search, a recommendation from someone in your network, and a look at the portfolio page. All three are useful, but each has a blind spot.

A search result tells you who is good at marketing themselves, which overlaps with being good at building websites but is not the same skill. A recommendation tells you one person's experience, often of a different kind of project, with a different team, perhaps years ago. A portfolio shows finished screens; it does not show how long the project overran, how many rounds of fixes it needed, or whether the site still works two years later.

So treat the shortlist as a hypothesis, and use a structured first conversation to test it. The conversation costs you an hour per company and saves you from the expensive mistake: signing with a team that cannot explain, in plain language, how your project will be run.

Before you call anyone: write a one-page brief

You will get better answers if you give better input. Before the first call, write a page covering:

• What the business does and who the website is for. Customers, patients, donors, dealers; local or national.
• What the website must achieve. Enquiries, bookings, online sales, donations, credibility. Pick the top one or two.
• What exists today. An old site, a social media page, nothing. If there is an existing site, its address and who controls the domain and hosting.
• Rough scope. Number of pages, whether you need a blog, an online shop, a booking system, a login area, multiple languages.
• Who decides. Name the person who approves the design and the person who pays. Projects stall when these are three people who have never met.
• Timing. Any real deadline, such as a product launch or an event, and why it matters.
• Budget range, if you have one. You do not have to disclose it, but a range stops you receiving proposals for a different kind of project altogether.

Our article on writing a website redesign brief for a developer covers this in more depth. A page is enough for shortlisting; a fuller brief comes later.

The twelve questions

Ask each company the same questions in the same order, and write down the answers rather than trusting your memory. The goal is not to catch anyone out; it is to make answers comparable.

1. Who will actually work on my project?

Many agencies sell with senior people and deliver with juniors or sub-contractors. That is not automatically a problem, since a good senior person can supervise a capable junior team, but you should know the arrangement. Ask who designs, who develops, who tests and who is your day-to-day contact, and whether any part is outsourced to freelancers or another company.

Reassuring: names and roles, an honest description of what is in-house and what is not, and an offer to let you speak to the person who will lead the build.
Worrying: "our team will handle it", reluctance to say who, or a different answer when you ask a second time.

2. Can I see two or three live websites you built, and speak to the owners?

Screenshots can be edited and case studies can be written to flatter. A live site can be opened on your own phone, tested for speed and clicked through. Ask for sites similar to yours in complexity, and for permission to contact the business owner.

Open each site on a mobile connection. Check how quickly it loads, whether the menu works, whether forms show clear error messages, whether it looks broken at any screen width. Also check whether the site is still maintained: a build from three years ago that has been neglected tells you something about aftercare.

Reassuring: live links without fuss, and a willingness to arrange a short reference call.
Worrying: only screenshots, only "confidential" clients, or portfolio sites that are no longer online.

3. What will you build it with, and why?

Websites are built on WordPress, on e-commerce platforms such as Shopify or WooCommerce, with website builders, or with custom code. None is universally right. The useful part of the answer is the reasoning. A company that recommends WordPress because your team needs to edit content without a developer, and explains the trade-offs, is thinking about your needs. A company that recommends the same platform for every client may be thinking about its own convenience.

Ask what the choice means in practice: who can edit the site afterwards, what ongoing updates are needed, and what would be hard to change later. Our comparison of WordPress and a custom-built website sets out the trade-offs in plain terms.

Reassuring: a recommendation tied to your requirements, with the downsides stated.
Worrying: "we can do everything", or a recommendation made before they understand your requirements.

4. What exactly will I receive when the project is finished?

"A website" is not a deliverable. Ask for a written list: designs, pages, templates, source files, admin login, documentation, training, hosting setup, analytics setup, redirects from the old site, and so on. Ask also what is excluded. Common exclusions are content writing, photography, stock image licences, premium plugin licences, translation, and data entry for a large product catalogue.

Reassuring: a clear list, including exclusions, offered before you ask for it.
Worrying: a vague description that can be interpreted generously by the company and narrowly by you later.

5. Who owns the website, the code, the domain and the content when it is done?

You should own the domain registration, the content and the right to use the finished website. Ownership of code can be more nuanced: some companies retain rights to reusable components or licence a theme or framework to you. That can be perfectly acceptable if it is written down and you are not locked in. What is not acceptable is discovering at the end that the company holds the domain, hosting account or admin credentials, and will release them only on payment of a further fee.

Ask what you receive on final payment, whether you will have full administrator access, and what a handover would look like if you moved to another provider. We cover this subject in depth in our article on contract, ownership and warranty terms.

Reassuring: a written statement of ownership, domain registered in your name, and a handover list.
Worrying: "we manage all that for you" with no mention of what you hold.

6. How will the project be run and how will I see progress?

Ask how the project is broken into stages, what you will be asked to approve at each, and how you will see work in progress, ideally on a staging site rather than screenshots. Ask how often you will be updated and who you contact between updates.

A sound process has checkpoints at which you approve something specific before the next stage begins: sitemap, design, content, a working build, final testing. Our guide to approval checkpoints from brief to launch lists nine of them.

Reassuring: named stages, approvals in writing, a staging link early on.
Worrying: "we'll show you when it's ready".

7. What do you need from me, and by when?

Delays on website projects are rarely caused only by developers. They come from content that arrives late, feedback from several people that contradicts itself, and decisions that wait for a director who is travelling. A company with experience will tell you immediately what it needs: text, photographs, logos, product data, access to existing accounts, and a single point of approval.

Reassuring: a specific list with dates and an explanation of how late content affects the schedule.
Worrying: "just send us whatever you have", with no mention of deadlines.

8. How will you handle speed, mobile and search visibility?

Most visitors to Indian business websites arrive on a phone, often on a mobile connection of variable quality. Ask how the site will be tested on real devices, what performance targets are used, and whether technical search engine groundwork such as page titles, headings, structured data, redirects and a sitemap is included in the build or sold separately.

For an existing site, ask how rankings will be protected during the transition. Our article on migrating a website without losing SEO lists what should be preserved. If search visibility is a goal, ask also what they consider part of the build and what belongs in a separate SEO service, so you are comparing like with like.

Reassuring: a concrete test process and a clear boundary between build and ongoing SEO.
Worrying: promises of rankings or "page one on Google", which no honest company can guarantee.

9. What happens after launch?

Websites need updating: security patches, plugin and framework upgrades, backups, content changes and occasional fixes. Ask what is included in a post-launch warranty period and for how long, what a maintenance plan covers and costs, how quickly they respond to a problem, and what is charged separately.

Ask also about hosting. If the company hosts your site, ask where, with what backups, and whether you can move it. Our guide on website maintenance and support shows what a sensible plan includes, and the article on backup and disaster recovery explains why backups need testing, not just existing.

Reassuring: a defined warranty, a written maintenance scope and a stated response time.
Worrying: "we're always available", which is not a commitment.

10. How is the price built up, and what causes it to change?

You are not asking for a discount; you are asking to understand the structure. Request a quote that separates design, development, content, integrations, testing, training and any recurring charges. Ask what would cause the price to increase, such as extra page layouts, additional integrations or late changes, and how change requests are priced and approved.

A written change process, in which each change is described, estimated and approved before work begins, protects both sides. For a framework to interpret quotes, see our article on what a business website costs and what drives the price.

Reassuring: itemised pricing, clear assumptions and a defined change process.
Worrying: a single figure with no breakdown, or a price much lower than others with no explanation of what is omitted.

11. What are the payment terms?

Payments tied to milestones, such as design approval, completed development and launch, are the common and sensible pattern. They keep both sides motivated. Be cautious of requests for the full amount upfront, and equally cautious of terms so loose that the company carries all the risk, because a company under cash pressure tends to prioritise other clients.

Ask also about taxes: whether quoted amounts include GST, and how invoices are issued. Confirm anything about tax treatment with your accountant rather than relying on the vendor's description.

Reassuring: staged payments linked to approved deliverables.
Worrying: a large upfront demand with no corresponding milestone, or pressure to pay "today for a discount".

12. What would make you decline or end this project?

This is the question most buyers never ask, and the answer reveals how the company thinks. An experienced company knows the kinds of projects that fail: no single decision-maker, no content, an unrealistic deadline, a requirement that cannot be met within the budget. If it can describe those honestly, it has seen them before and has a way of managing them.

Reassuring: a candid, specific answer.
Worrying: "we never say no", which usually means problems will be discovered late.

A scoring sheet you can copy

After each call, give each company a score from one to five on each question, using your notes. Do not weight the questions initially; simply total them and then look at where the lowest scores fall. A company with a high total and one very low score on ownership or after-launch support may still be a poor choice, because those are the problems that are hard to repair later.

Keep the scoring sheet. When the proposals arrive, you can compare them against what you heard on the call; discrepancies between what was said and what was written are informative.

Reading proposals once they arrive

A proposal is a sales document, but it also shows how the company thinks. Check these things before you look at the price.

Does it restate your needs correctly? A proposal that echoes your brief and shows that the writer understood your business is a good sign. A proposal that could have been sent to anyone, with your name inserted, is a warning that the next stage will be similar.

Is the scope specific enough to be tested? "Responsive design" cannot be tested; "layouts designed and tested at defined screen widths on current versions of the major browsers" can. "SEO friendly" cannot be tested; "unique page titles and meta descriptions, a sitemap, redirects from the old URLs and structured data on defined page types" can.

Are assumptions stated? Good proposals list assumptions: "content supplied by the client by this date", "up to two rounds of revisions per design", "integration with the following third-party systems". If assumptions are not stated, they exist anyway and will emerge in arguments.

Is the timeline built from stages? A timeline of "eight weeks" tells you little. A timeline broken into design, build, testing and launch, with the dates on which your input is needed, is a plan.

What is excluded? Look for a short list of exclusions. If there is none, ask for one.

Red flags worth taking seriously

Some warning signs are strong enough to remove a company from the shortlist outright:

• Guaranteed search rankings or traffic. Search engines do not sell guarantees, and anyone offering one is either misinformed or being less than honest.
• Refusal to put ownership terms in writing.
• Reluctance to show live sites or offer references.
• Unusually low price with no breakdown. The cost has to come from somewhere: fewer unique designs, a template, offshore sub-contracting, minimal testing, or charges added later.
• Pressure to decide quickly. A real company has capacity constraints, but a deadline invented for your benefit is a sales tactic.
• Asking for your hosting or domain credentials with no explanation of why and how they will be protected.
• A single contact who cannot answer technical questions and will not bring in someone who can.

A single red flag is a question; two or three together are a decision.

Matching the company to the kind of project

Not every company is equally suited to every kind of site. Think about what you are building, and test the shortlist against it.

A business brochure or service website. Here the priorities are clear messaging, speed, mobile layout, and a content system your staff can edit. Look for companies that talk about page structure and search groundwork, not only visual design. Our guide to choosing a website designer in Pune covers this kind of project.

An online store. Catalogue structure, payment and shipping integrations, tax invoices and returns need experience that a brochure-site developer may not have. Ask for live stores they built, and check that product pages, filters, the cart and checkout work well on a phone. If this is your project, read our guide to ecommerce website development in Pune.

A website with software behind it. Booking systems, portals, CRMs and dashboards are applications, not pages. Ask about testing, security, data protection and how the system will be maintained. For these projects the company's engineering practice matters more than its visual portfolio.

A non-profit website. Donation flows, 80G receipts, FCRA considerations, donor records and transparency pages need domain knowledge. Ask whether the company has built donation platforms, and ask to see them. Our NGO website service is built around this work, and the portfolio includes more than five hundred non-profit websites, but whichever company you choose, ask for live examples rather than a number.

Working with Govindani Infotech

Govindani Infotech Pvt. Ltd. is a web development company in Pune. Our website creation service covers business websites, WordPress builds, custom-coded websites and online stores, and we apply the same questions above to our own proposals: we list what is included and excluded, put ownership terms in writing and tie payments to approved stages. If you would like to put these twelve questions to us, message our team on WhatsApp or use the contact page. We confirm scope and pricing against your written brief, not from a headline figure.

When the build is finished, use our website handover checklist to confirm you own the domain, hosting, files and accounts.

Frequently Asked Questions

How do I choose a web development company in Pune?

Write a one-page brief, then put the same questions to each company on your list: who will do the work, what you will receive, who owns the website, how the project is run, what happens after launch and how the price is built. Compare their live websites and written answers rather than relying on a portfolio page alone.

What should I look for in a web development company's portfolio?

Look for live websites similar to yours in size and complexity, test them on your own phone, and check whether they are still maintained. Ask permission to speak to the owner of at least one site. Screenshots and case studies are useful, but a live site you can click through tells you more.

How many quotes should I get for a website?

Two or three well-matched quotes are usually enough. More than that rarely improves the decision and increases the effort of comparing them. Give each company the same written brief so the quotes can be set side by side.

Is the cheapest web development company a bad choice?

Not necessarily, but a much lower price than the others needs an explanation. It may reflect a template instead of custom design, less testing, fewer integrations or charges added later. Ask for an itemised quote and compare what is included and excluded before judging on price.

Do I need a web development company in Pune specifically?

Not always. A local company is convenient for in-person meetings, site visits and quick responses, which helps on larger or more collaborative projects. For simpler sites, a well-run remote process can work as well, so decide on process, ownership terms and aftercare rather than location alone.