The questions that matter are not about portfolio or price. They are about who owns the code, who tests it, who maintains it, and how hard it is to leave. A firm that answers those four clearly is usually a good partner regardless of what its portfolio looks like. A firm that gets vague on them is a risk regardless of how good its work looks.
About the work itself
- Who exactly will build this, and are they in-house?
Subcontracting is common and not automatically wrong, but you should know. What good sounds like: named roles, in-house, with the option to meet them. What should concern you: “we have a large team” without specifics.
- How many unique designs are in this quote?
The single best question for comparing quotes. Page count is a poor comparator; unique design count is the real unit of work. This one question explains most price differences between proposals. When comparing the website development cost, ask each company how many unique page designs are included in the quoted price.
- Who writes the content?
Content is the most common cause of delay and the most commonly ambiguous line in a proposal. What good sounds like: an explicit statement either way, with dates. What should concern you: silence, which usually means they assume you will supply it and you assume they will write it.
- What is your testing process, and on which devices?
What good sounds like: functional, cross-browser and real-device testing, named handsets, plus performance and security checks. What should concern you: “we test everything thoroughly” with no specifics, or device testing done only in a browser emulator.
About performance and search
- What page speed will this site achieve on mobile, and how do you know?
Speed is an engineering decision made during the build, not a feature added afterwards. What good sounds like: a performance budget agreed upfront and a target you can hold them to. What should concern you: “we will optimise it at the end”.
- If you are replacing an existing site, how will you protect the current rankings?
What good sounds like: a URL map, 301 redirects, pre- and post-launch crawl comparison. What should concern you: a blank look, or “the new site will rank better anyway”. This is the question that most reliably separates firms that understand search from firms that do not.
- What structured data will be implemented?
Schema markup is how search engines and AI answer engines interpret a page. What good sounds like: specific types named for your page types. What should concern you: treating it as an optional extra.
About ownership and control
- Who owns the code and the design files when this is finished?
What good sounds like: you do, unambiguously, in writing, including design source files. What should concern you: anything conditional on an ongoing retainer. This is the most important question on the list.
- Whose accounts are the domain, hosting and analytics in?
They should be in your company’s name with you as owner, and the agency granted access – not the reverse. Businesses lose control of their own domain this way more often than you would expect, and it is usually discovered at the worst possible moment.
- If I move to another developer in two years, how difficult is that?
What good sounds like: a straight answer about the stack, documentation and handover. What should concern you: discomfort. A firm confident in its work is not threatened by this question, and the reaction tells you more than the answer does.
About what happens after launch
- What exactly does maintenance include, and what does it cost?
What good sounds like: an itemised scope – security patching, platform updates, backups, monitoring, a defined number of content changes – with a response time and a named contact. What should concern you: “we will look after you”, or a maintenance quote covering only design updates while ignoring security patching.
- Show me a client you have worked with for more than two years.
Portfolios show what a firm can build. Long relationships show what it is like to work with once the invoice is paid. This question is harder to prepare for than any of the others, which is exactly why it is useful.
Three answers that should end the conversation
- “We guarantee first page on Google.” Nobody can guarantee rankings. Anyone who says otherwise is either uninformed or dishonest, and neither is what you want building your website.
- “You don’t need to worry about the technical side.” You do not need to understand it, but you are entitled to have it explained. Deflection here usually indicates it has not been thought about.
- “We can start tomorrow.” On a project of any substance, immediate availability means either no discovery is planned or there is no pipeline. Neither is reassuring.
The Solution: Building an Intelligent Admission Ecosystem
What a good proposal contains
- A scope specific enough that you could hand it to a different firm and get a comparable quote
- Unique design count, not just page count
- A named technology stack with a reason for it
- Explicit content responsibility with dates
- A testing approach, including named devices
- A launch plan, and a redirect plan if replacing an existing site
- Maintenance scope, cost and response time
- Ownership terms in writing
If a proposal contains all eight, you are dealing with a firm that has done this before. That is worth more than a lower number attached to a vaguer document because the gap between two unclear proposals is often filled by change requests later. A professional web development company should be able to provide this level of clarity before development begins.
