Choosing a development company is difficult because the thing being bought cannot be inspected in advance and the buyer usually cannot evaluate the work directly. Portfolios show finished screens, not how the project ran. References are chosen by the seller. Price varies by a factor of ten for what looks like the same brief.
What follows is the set of questions that separate firms in practice, written for the person doing the buying. We are one of the companies you might be evaluating, so read it as a checklist to use on us as well.
Who, specifically, will write this
The single most useful question, and the one that most often changes the answer to everything else. Ask for names, roles and how long each person has been with the company. Ask whether the people in the meeting are the people who will do the work. Ask what else they are working on during your project.
Warning signs: the team is described only as a pool, nobody can be named until the contract is signed, or the senior person in the pitch turns out to be unavailable afterwards. Subcontracting is not automatically bad, and it is bad when it is concealed.
Who owns the code, and where does it live
You should own it outright on payment, including the design files. Get it in writing.
Then ask the follow-up that reveals more: where will the repository be, and will we have access during the project? A firm that will not let you see the code as it is written is a firm you cannot leave mid-project. The same applies to hosting, domains and analytics: all of them should be in your name, with the agency holding access rather than ownership.
The test to imagine is not litigation. It is the ordinary case where the relationship simply ends and somebody else picks the work up.
How was this estimate produced
An estimate with a single number and no breakdown is a guess dressed as a quote. Ask what it assumes, what is excluded, and what would make it change. A firm that has genuinely thought about your project can tell you which part they are least certain about.
Very low quotes usually mean one of three things: the scope is understood as much smaller than you meant, the work will be done by someone junior and unsupervised, or the number is a way in and the variations start in month two. Very high quotes are not automatically better, but they should come with a reason you can follow.
The most useful thing a prospective partner can do at this stage is disagree with part of your brief. A firm that agrees with everything has either not read it or is not planning to be there in month four.
What happens after launch
This is where most disappointment lives, and it is straightforward to prevent by asking three things.
- What does support cover, for how long, and at what cost? A bug found in week three: fixed under warranty or billed?
- Who applies security updates? A WordPress or Laravel site left unpatched for a year is the most common way a small business site gets compromised, and it is nobody’s job by default.
- What is the handover? Documentation, an admin walkthrough, access to everything, and a written note of what is unfinished. Ask to see an example from a previous project.
Does local actually matter
Partly, and not for the reason usually given. Being in the same city rarely changes delivery, which happens on calls and in repositories regardless. It changes two things that do matter: you can meet during scoping, which is the phase most damaged by misunderstanding, and there is a real address and a real entity if something goes wrong.
For a business in Delhi NCR the practical questions are whether they can come to you for the important sessions, whether they work your hours, and whether they invoice in a way your accounts department will accept without a month of paperwork. If the answer to all three is yes, the pin on the map matters less than the portfolio.
Six answers that should end the conversation
- “We can start on Monday” before anybody has asked what you are trying to achieve.
- “We will build it and show you at the end.” Six weeks of silence is how a project arrives wrong and unfixable.
- A guarantee of a search ranking. Nobody can promise a position and anyone offering one is describing something else.
- No written scope, because “we are flexible”. Flexibility is a way of working, not a substitute for a document.
- Unwillingness to say what is not included.
- A portfolio of sites that are all offline. Check three of them yourself before the meeting.
What to bring so the quotes are comparable
Most quoting variance comes from firms guessing at different projects. You can remove most of it in an afternoon.
- What the site or system has to do, in plain sentences, ordered by importance.
- Who it is for, and what they are trying to do when they arrive.
- What already exists: current site, hosting, content, brand assets, systems it must talk to.
- The deadline and what it is tied to. “March” and “before the trade show on 4 March” produce different plans.
- Your budget range. Withholding it does not get a better price, it gets three quotes for three different projects.
The one that tells you most
Ask about a project that went wrong, and what they changed afterwards. Everybody has one. The useful answer is specific, takes some responsibility, and describes a process change. A firm that cannot recall one is either very new or is managing you, and both are worth knowing before you sign.
How to compare three quotes that look nothing alike
Even with the same brief, three proposals will differ in shape. Normalise them on five axes before comparing the totals.
- What is being built, feature by feature. One firm has included search and another has not; that gap is most of the price difference.
- Who does it, and how much of it is senior time.
- What happens to content. Migrating two hundred pages is real work and is frequently assumed to be the client’s job without anybody saying so.
- What is included after launch, and for how long.
- What is explicitly excluded. The proposal that lists exclusions is usually the one that has been thought about.
Then ask each firm the same follow-up question and compare the answers rather than the documents: what is the riskiest part of this project, and how would you reduce it? The replies will tell you more than the pricing did.
Payment terms that protect both sides
Milestone payments tied to deliverables rather than to dates keep the incentives aligned: a payment on an agreed, demonstrable stage means the work is visible before the money moves, and it means the firm is not carrying the whole project on credit either. Avoid full payment on completion, which sounds safe and creates pressure to declare things finished, and avoid large upfront payments with no deliverable attached.
Hold a meaningful final payment until after handover, and define what handover means in the contract: access transferred, documentation delivered, and an agreed list of what remains outstanding.
We are a development company in Delhi, and our published work, the stack behind it and the people involved are on our case studies. If you are gathering quotes, send us the brief you are sending everyone else and we will tell you what we would push back on before we tell you a number.