Choosing a Web Development Company: Questions That Reveal Fit

Most comparisons between development agencies start with the proposal. Three suppliers send near-identical documents: a cover page, a list of technologies they like working with, a phased timeline nobody has discussed with you, and a number at the bottom. Read all three side by side and you will learn almost nothing, because a proposal is a sales document. It has to be flattering enough to win the meeting and vague enough to survive contact with your actual requirements.

The questions you ask in the room are more revealing than the document that arrives afterwards. A firm that has delivered this kind of work many times has specific, occasionally unflattering answers, and it will usually have questions for you. A firm that is learning on your budget does not.

Below is roughly the question set I would use, ordered the way I would ask it. It is not exhaustive, and several of the questions are worded awkwardly on purpose, because an answer that only fits a rehearsed response is itself an answer.

Who will actually write the code

There is usually a gap between the person who sells a project and the people who build it. Both roles matter, but not equally. Ask whether the person scoping your work stays involved through delivery, and how many live projects that individual is carrying. An account manager coordinating eight engagements is not making architectural decisions for any of them.

Then ask what proportion of the build is custom code versus configuration of something that already exists. Honest firms give a mixed answer and can tell you which parts of your requirement force one or the other. “Everything is custom” usually means nobody has looked closely at your problem yet. “We configure an existing theme” means you are buying a template with your logo on it.

The most useful question in this group is about existing work. Ask to see a project in a similar domain — not the curated case study with the stock photography, but the live system or the repository, with the client’s permission. If they cannot show you anything, that is informative too.

This is a question we invite when a prospective client approaches SmartEdge IT Solutions, and one reason our team page describes roles and seniority instead of listing client logos. It is far easier to answer honestly when the expectation is set at the start of the relationship rather than during a tender.

Ask them to describe something that went wrong

Almost every question you would think to ask is designed to produce a success. This one is not. Ask them to describe a project that went badly, and then leave the silence alone for a few seconds.

A good answer has three parts: a decision that was made, a consequence that followed, and a change to how they work afterwards. “We found out late that the client’s data model could not support the reporting requirement, so we rebuilt the aggregation layer and it cost us three weeks” is genuinely useful. It names a failure at a specific point in a specific project, and it implies they now probe that earlier. An answer that pivots back to a success story, or that locates the entire fault in a client who “was not clear” about requirements, tells you the firm either has never had failures or does not examine them.

Follow it with the mirror question: what kind of work will you refuse? A team that will build anything, in any stack, to any date is telling you it holds no opinion, which usually means the opinion arrives later as a change request and a revised invoice.

Treat scope change as the normal case

Your requirements will change. That is not a failure of planning. It is what happens when people who have thought about a business problem for years finally meet the constraints of real software — the legacy field that is not unique after all, the payment provider that will not support the refund flow you imagined, the report nobody can compute without storing every event.

Fixed price, time and materials, and a hybrid are all defensible. What matters is whether the firm can explain who carries the risk in each case. Under a genuinely fixed price, somebody absorbs the cost of your changing mind, and often that is the delivery team, quietly, with the consequence showing up later as thin testing rather than as a shorter feature list. Ask what gets dropped first when a fixed-price project runs late. The answer is usually more honest than the price.

For anything large or loosely defined, a paid discovery phase earns its cost precisely because it moves the hard questions to the moment when answers are still cheap. Our app consulting and strategy work exists for that reason: the deliverable is a decision about what to build and, more usefully, what to leave out.

Also ask how change originating from technical reality is handled. When a third-party API deprecates a field or a payment provider changes a flow, whose problem is it? A firm with a written process will tell you. One that says “we work with the client” is describing somebody’s worst week.

Listening to the technical answers

You do not need to be able to write code to evaluate this section, but you do need to notice inconsistency. Listen for whether the person talks about environments. Where does staging live, and is it a copy of production or a separate system built from scratch? How does code move from a laptop to a live server — by hand, or by pipeline? Who holds the deployment credentials?

Where the data goes

These questions sound procedural but they are really about risk. Hand deployments mean every release is an opportunity to take the site down, and nobody in the firm necessarily finds out until a customer reports it. That is a support cost you will pay for quietly, in the form of “is the site down?” messages at inconvenient hours.

You get sharper answers on infrastructure from a team that treats it as a discipline rather than an afterthought, which is why our DevOps consulting and CI/CD deployment discussions usually happen before a framework is chosen. Pipelines are not interesting in themselves. What matters is that a release is a repeatable action and a rollback is not a crisis.

Whether they ask what you run today

Moving a live business onto a new stack is a different job from building something new, and firms that treat them identically hand you a migration plan that is really a fresh build with an unstated data-transfer problem attached. Our legacy software modernisation service exists because that distinction is where a lot of projects quietly fail.

What happens in the weeks after launch

The worst support experiences usually come from agreements that ended tidily at go-live. The project was delivered, the invoice was settled, and the relationship then consisted of a shared inbox and a hope.

Ask three things. Who is the named contact for a production incident, and what are the response times, and what sits outside them — “reasonable time” is not a response time, it is a conversation waiting to happen. Second, what documentation is handed over: deployment steps, environment configuration, database schema, a list of every third-party integration with its credential owner. If documentation is described as something you can request afterwards, assume it will be thin and slightly out of date.

Third, and most easily skipped, ask who owns what. Source code in your repository. Infrastructure in your organisation’s cloud project. Domains registered to you. Third-party accounts held by you rather than by the agency. This is not distrust. Firms with a long relationship with a client usually welcome the question because it makes their own delivery simpler, and it removes the awkward conversation three years later when someone needs to change a payment provider.

Read retainer terms with the same attention. Some are genuinely about continuity of named engineers. Others are structured so that leaving is expensive, which is a different proposition and should be priced as one. We would rather you hire developers from our team and agree a support arrangement on its own terms than bundle the two into something you cannot exit cleanly.

Put the scope in writing before you compare prices

Once you have chosen a supplier, the work moves into a written scope, and this is where quotes finally become comparable. A price only means something next to a document that states what is being built.

A scope should name the pages or screens specifically enough that you could count them. “About ten pages” is not a scope; “home, four service pages, six case study templates, contact, privacy policy” is. It should carry an explicit exclusions list, which protects both sides and prevents the recurring argument about whether a small addition was included. It should say who supplies the copy and who supplies the design assets, and in what state — copy written by an agency and copy written by your marketing team are not the same input, and the difference appears as a schedule delay rather than a budget line.

It should state the environments, the browsers and devices you will actually test on, and what happens to the project if a service you depend on changes its terms. Acceptance criteria for each phase should be written so that someone other than the developer can check them.

A shorter format works too. We have seen projects run happily on a one-page scope that names the screens, the exclusions, the content owners and the acceptance test, provided everybody signs it before work starts. Detail is useful; agreement is essential.

Our process page describes how SmartEdge IT Solutions structures this work. The point of writing it down is not control. It is reducing the number of conversations that begin with “I thought that was included”.

Answers that should end the conversation

Some responses are sufficient on their own. You do not need several to make a decision.

• A promise of results — rankings, uptime, revenue — with no definition of what is promised and no discussion of who carries what risk.
• Reluctance to name the stack, the repository, or the deployment process on grounds of proprietary method.
• Declining a paid discovery while quoting a firm fixed price for a project whose scope nobody has written down.
• Pressure to sign before a competitor’s deadline. Deadlines are a legitimate commercial tool; a rushed signature is a purchase you will keep paying interest on.
• Unowned decisions. If no named person chooses the database or owns the design system, those choices get made by accident in week four.
• Badges, certificates and accreditation logos offered in place of references from people you can actually phone.

No fit is also a legitimate outcome, and a good agency will sometimes say so plainly. If your requirement is a small brochure site, a large team is dead weight. If it is an internal tool carrying compliance obligations, a three-person shop is a risk. Ours is a mid-sized engineering group in Noida that works on long-running project portfolios and maintenance retainers, which suits some projects better than others. What SmartEdge IT Solutions does and who we are is a fair place to check whether the shape of the engagement matches what you need before anyone quotes.

The goal is not to identify a single best agency. No such thing exists as a general category, and anyone claiming otherwise is selling. The goal is to find a group whose habits — how they quote, how they escalate, what they decline, who owns the repository at the end — are compatible with the habits you want in a supplier. Ask the questions, write the answers down, and compare those instead of the prices. Get in touch when you want that conversation started properly.