Define the problem before comparing providers
A designer can only be a good fit in relation to the project. Before opening a dozen portfolio tabs, write down why the website needs to change. Common reasons include weak credibility, poor mobile use, unclear services, too few qualified inquiries, difficult updates, or a customer action the current site cannot support.
Add the constraints that matter: who will approve the work, what content exists, whether there is a launch date, which systems must connect, and who should maintain the finished site. This brief does not need to prescribe technology or page layouts. It should give providers a clear business problem to respond to.
Send the same brief to each provider. If the proposals solve different problems, their prices will not tell you much. Use the small-business website cost guide to establish a budget and separate launch requirements from work that can wait.
Look past the portfolio thumbnail
Strong visuals matter, but a polished screenshot does not tell you whether the site is useful. Open the live work when possible and test it as a customer would. Can you understand the business quickly? Are services easy to find? Does the primary action make sense? Does the experience remain clear on a phone?
Ask the designer what they were responsible for. Strategy, copy, photography, interface design, development, and ongoing optimization may come from different people. That is normal, but you should know which capabilities the work actually demonstrates.
- Demonstration or concept work can show design and development ability. It does not establish a paid client relationship or a business outcome. Ask which parts are working and which are illustrative.
- Client work should identify the provider’s actual contribution. A site built by several specialists is relevant evidence when you understand the role of the person you may hire.
- Measured results need context. If a case study reports more inquiries, ask about the measurement period, starting point, tracking method, and other changes such as advertising. A screenshot alone cannot substantiate that result.
Check the technical baseline
You do not need to become a developer to ask good questions. The provider should be able to explain how they handle the fundamentals in plain language:
- Responsive behavior across current phones, tablets, and desktops.
- Page speed, image handling, and avoidance of unnecessary scripts.
- Keyboard use, readable contrast, form labels, and other accessibility basics.
- Unique page titles, descriptions, crawlable content, sitemap, and redirects.
- Form reliability, spam protection, security updates, and backups.
- Analytics setup that measures meaningful actions rather than page views alone.
No provider can honestly guarantee rankings or perfect performance scores in every situation. They should be able to describe the technical standard they build toward and the tradeoffs a particular feature introduces.
Clarify ownership, hosting, and support
Before signing, establish who owns the domain, content, design files, code, analytics accounts, and third-party subscriptions. Ideally, critical business accounts are created in the client’s name with the provider receiving appropriate access.
Ask what happens after launch. Some businesses want a handoff and an editing guide. Others prefer a partner to handle hosting, maintenance, content, analytics, SEO, and continued development. Either model can work when expectations, response times, and ongoing costs are explicit.
Communication belongs in this conversation too. Find out who leads the project, who does the work, how feedback is collected, and how often you will see progress. The best process is one your team can participate in without becoming the project manager.
Compare proposals using the same worksheet
Copy these rows into your notes and record an answer for each shortlisted provider. Mark each item as included, excluded, optional, or unanswered, with a reference to the relevant proposal section. A missing answer is a follow-up question, not an automatic rejection.
| Compare | Ask each provider | Record for each proposal |
|---|---|---|
| Deliverables and page types | Which pages, distinct layouts, features, and integrations will be delivered? What is outside the scope? | Page list, repeated versus unique layouts, working features, and exclusions. |
| Content and imagery | Who writes, edits, sources, licenses, and approves text and images? | Named responsibility, content deadlines, and any separate copy or photography costs. |
| Who performs the work | Who plans, designs, develops, and manages the project? Will other specialists participate? | Your contact, delivery roles, and responsibilities for outside contributors. |
| Relevant capabilities | Which examples demonstrate the specific work our project needs, and what did you contribute? | Relevant live work or demos, the provider’s role, and evidence behind any claimed results. |
| Review and approval | When do we review work, who approves it, and how are revisions or scope changes handled? | Review stages, included revisions, decision deadlines, and the change-approval process. |
| Mobile, accessibility, and functionality | What devices, browsers, keyboard paths, forms, and integrations will be tested? How are issues resolved? | Testing scope, accessibility checks, acceptance criteria, and who confirms fixes. |
| Accounts and handoff | Who controls the domain, hosting, analytics, and other accounts? What files, access, and instructions transfer? | Account holders, access levels, handoff materials, licensing limits, and portability questions. |
| Launch responsibilities | Who connects the domain, checks forms, handles redirects, and verifies the live site? | Launch owner, dependencies, go-live approval, and a plan if a launch problem occurs. |
| Ongoing support and costs | What continues after launch, what does it cost, and what happens when support ends? | Recurring charges, edit limits, support hours, response expectations, and handoff or cancellation terms. |
| Unresolved questions | Which assumptions still need a decision before we can approve the work? | Open questions, who answers them, and any effect on price or schedule. |
Ask providers to resolve material gaps in writing before choosing. If one quote includes content, migration, and launch testing while another leaves them to you, compare that responsibility as well as the total. A higher fee may cover more work; it still needs to match what your business actually requires.
Turn broad promises into specific answers
The examples below are invented illustrations, not quotations from providers or statements of Veriq’s terms. They show the level of detail to seek when a proposal uses a broad label.
| Vague answer | What remains unclear | A more specific illustrative answer |
|---|---|---|
| SEO included | Which pages and tasks are covered? Does this include ongoing content or only launch setup? | We will write unique titles and descriptions for the agreed pages, add a sitemap, implement the agreed redirect list, and set up Search Console access. Ongoing content and outreach are excluded. |
| Ongoing support | Which tasks, costs, availability, and response expectations apply? | The support fee covers software updates and restoring backups. Copy edits and new pages are quoted separately. The support schedule lists the fee, service hours, response target, and excluded work. |
| You own the website | Which accounts and files transfer? What depends on a platform or third-party license? | Your business holds the domain and analytics accounts. Handoff includes the agreed source files and editing guide. The proposal lists licensed assets, platform dependencies, and what can be moved to another host. |
Specific language makes proposals easier to evaluate, but wording alone does not settle contractual rights. Confirm that the agreement, account arrangements, and third-party licenses match what you expect. Paying upfront or monthly does not answer these questions by itself; the guide to one-time website pricing and monthly plans explains how to compare continuing costs and responsibilities.
Questions worth asking before you sign
- How will you learn about our business and customers?
- Why does your proposed approach fit the problem in our brief?
- What do you need from us, and what could delay the timeline?
- Which unanswered assumptions could still change the price or scope?
Compare the specificity of the answers, not just the confidence with which they are delivered. A thoughtful provider will sometimes ask for more context before recommending a solution. If the choice is between a solo provider and a larger team, our local designer and agency comparison covers the differences in capacity and communication to check.