A polished portfolio can tell you that a web development company knows how to present its work. It does not necessarily tell you how the company handles deadlines, changing requirements, technical decisions, ownership, SEO, testing, or support once your website goes live.

Those details usually become visible only after a project has started  which is exactly when discovering a poor fit becomes expensive.

Before choosing a development partner, the goal is not to ask as many technical questions as possible. It is to ask questions that reveal how the company thinks, works, communicates, and takes responsibility for the final product.

The short answer: before hiring a web development company, ask about relevant experience, project discovery, the team, scope, pricing, timelines, technology, UX, SEO, performance, security, testing, ownership, communication, and post-launch support.

Here are the 15 questions worth taking into your next agency conversation.

Before the Meeting: Know What You Are Actually Buying

You do not need a finished technical specification before speaking with a development company.

You should, however, have a reasonable understanding of the business problem.

For example, are you trying to generate more enquiries, sell products online, improve an outdated company website, automate an internal process, accept bookings, create a customer portal, or launch an entirely new digital service?

These objectives can lead to very different technical requirements. A relatively straightforward company website does not need to be approached in the same way as an e-commerce store, customer portal, internal business system, or custom application.

A good development company should help translate business objectives into practical requirements rather than immediately pushing a preferred platform or technology.

Before contacting agencies, establish four things:

  • What should the website help the business accomplish?

  • Which features are essential?

  • What approximate budget are you working with?

  • Is there a genuine deadline or only a preferred launch date?

You do not need every answer yet. You simply need enough clarity to judge whether the development company is asking the right questions.

Questions About Experience and Project Fit

1. Can You Show Me a Live Project Similar to Mine?

Do not stop at portfolio thumbnails.

Ask the company to open one or two live websites and explain why those projects are relevant to yours.

Similarity does not necessarily mean the same industry.

An e-commerce company, for example, may care more about product management, payment integration, filtering, order processing and mobile usability than whether the developer previously worked with another company selling exactly the same type of product.

Likewise, a B2B company might care more about lead generation, service presentation, integrations and content management.

Ask what the development company was actually responsible for.

Did it handle:

  • Strategy?

  • UX?

  • Design?

  • Development?

  • CMS configuration?

  • Integrations?

  • Testing?

  • Deployment?

  • Post-launch optimisation?

A situation we often see when reviewing agency portfolios is that the final website looks impressive, but it is difficult to determine how much of the work was actually completed by the agency displaying it.

That is why asking for context matters.

You can review examples of how different business requirements translate into websites, e-commerce platforms and custom systems in dexnine's selected development projects.

A portfolio tells you what the finished website looked like. The conversation around that portfolio tells you much more about how the company approaches projects.

2. How Will You Understand Our Business Before Designing the Website?

A website should not begin with a colour palette.

It should begin with questions.

Who are your customers?

Why are they visiting the website?

Which services or products matter most?

What information do customers normally need before contacting you?

What objections prevent them from buying?

What action should the website encourage?

Many businesses make the mistake of beginning with visual preferences such as:

“We want something modern.”

“We like this competitor's website.”

“We want it to look premium.”

Those preferences can be useful, but they are not a website strategy.

If the development company does not understand the customer journey, even an attractive website can end up making the wrong information prominent.

Listen for a discovery process that considers your customers, services, competitors, content, current website problems, functionality and business objectives.

Be cautious when a company immediately starts discussing templates or page counts before understanding what those pages need to achieve.

Good developers do not simply ask what you want the website to look like.

They ask what it needs to do.

3. Who Will Actually Work on Our Project?

The people involved in the sales meeting are not always the people who will build the website.

Ask who will be responsible for:

  • Project management.

  • UI and UX design.

  • Frontend development.

  • Backend development.

  • CMS development.

  • Quality assurance.

  • Deployment.

  • Technical decisions.

For a smaller website, one experienced person may handle several of these responsibilities. That is not automatically a problem.

What matters is knowing who owns each responsibility.

Ask who your primary contact will be and whether you will be able to speak directly with technical team members when important technical decisions arise.

You should also understand what happens if a key developer becomes unavailable during the project.

The warning sign is not a small team.

The warning sign is ambiguity.

If nobody can explain who is responsible for an important part of the project, accountability can become difficult once the work becomes more complicated.

If company structure, experience and working approach matter during your evaluation, reviewing the company's and development approach is an example of the type of background information worth checking before an initial conversation.

Questions About Scope, Delivery and Cost

4. What Does Your Development Process Look Like From Start to Launch?

Ask the company to describe the project chronologically.

You are looking for something more substantial than:

“Design, development, testing, launch.”

A mature process normally establishes requirements, responsibilities, approvals and milestones before large amounts of development begin.

You should understand:

  • When requirements are confirmed.

  • Whether wireframes are created.

  • When visual designs are approved.

  • When development begins.

  • How progress is reviewed.

  • How feedback is submitted.

  • When content is required.

  • How testing is handled.

  • Who approves launch.

  • What happens immediately after launch.

The exact project methodology matters less than the clarity of the process.

A small agency does not need to run formal Scrum ceremonies to deliver a good website.

The real question is whether everyone involved knows what is happening, what comes next, who is responsible, and what needs approval.

If the answer feels improvised during the sales conversation, it can become considerably more difficult once several people, deadlines and dependencies are involved.

5. What Exactly Is Included in the Proposal and What Is Not?

Two development proposals with very different prices may not actually describe the same project.

One might include:

  • Discovery.

  • UX.

  • Custom design.

  • Development.

  • CMS setup.

  • Content migration.

  • Analytics.

  • Technical SEO.

  • Quality assurance.

  • Hosting configuration.

  • Training.

  • Post-launch support.

Another might include development only.

Ask for both deliverables and exclusions in writing.

Pay particular attention to:

  • Number and type of pages.

  • Custom functionality.

  • Integrations.

  • Content entry.

  • Content migration.

  • Copywriting.

  • Photography or stock imagery.

  • SEO.

  • Analytics configuration.

  • Hosting.

  • Domain configuration.

  • Training.

  • Maintenance.

  • Premium plugins.

  • Third-party software.

  • API costs.

During website projects, unexpected costs often appear not because someone intentionally hid them, but because both sides made different assumptions about what “website development” included.

A clear proposal reduces those assumptions.

The cheapest quotation is not necessarily the cheapest project if important work starts appearing as additional charges halfway through development.

6. What Happens if the Scope Changes?

Website requirements often evolve.

During design, you may discover that customers need better filtering.

During development, you might decide to integrate another business system.

A stakeholder may request functionality that was never included in the original brief.

That is normal.

What matters is how those changes are handled.

Ask whether the company uses:

  • Change requests.

  • Revised estimates.

  • Additional project phases.

  • Separate development tickets.

  • Updated milestones.

You want to understand the cost and timeline impact before additional development begins.

“Don't worry, we'll take care of it” can sound reassuring at the beginning of a project.

It becomes considerably less useful three months later when nobody remembers whether a feature was included in the original price.

A documented change process protects both the business and the development company.

7. How Did You Estimate the Timeline?

There is a difference between a project timeline and a sales deadline.

Ask what assumptions sit behind the proposed launch date.

Does the timeline depend on receiving content from your team?

Does another vendor need to provide API access?

How quickly must designs be approved?

Will legal or compliance teams need to review anything?

Are payment providers or third-party integrations involved?

A credible timeline normally contains dependencies.

It should also acknowledge uncertainty where uncertainty genuinely exists.

For example, a developer can estimate how long implementing an integration should take. They cannot guarantee how quickly an unrelated third-party provider will approve access.

Be cautious of very precise delivery promises made before the agency understands the requirements.

Fast delivery can be valuable.

An unrealistic deadline simply moves the problem further into the project.

Questions About Technology and Website Quality

8. Which Technology or CMS Would You Recommend and Why?

Do not hire a development company because it uses the longest list of technologies.

Ask why the proposed technology is appropriate for your situation.

A service-based business primarily requiring marketing pages, case studies and easy content management has very different requirements from:

  • A marketplace.

  • SaaS product.

  • Customer portal.

  • Membership platform.

  • E-commerce operation.

  • Internal business system.

Ask the developer to explain the recommendation in practical terms.

Consider:

  • Ease of content management.

  • Website performance.

  • Security.

  • Scalability.

  • Required integrations.

  • Developer availability.

  • Maintenance.

  • Hosting requirements.

  • Long-term cost.

  • Platform limitations.

For example, WordPress, Shopify, Next.js and a custom application stack can all be sensible choices.

The question is not:

“Which technology is best?”

The better question is:

“Which technology is appropriate for this project's requirements?”

The strongest answer is rarely:

“We always use X.”

It is usually an explanation of trade-offs.

You can see the range of approaches used for business websites, e-commerce projects, redesigns, CMS implementations and custom functionality on dexnine website development services page.

Technology should follow the problem rather than forcing the problem into whichever technology an agency prefers to sell.

9. How Will You Approach User Experience, Mobile and Accessibility?

Responsive design should now be expected.

That does not mean every responsive website provides a good mobile experience.

Ask how important elements such as:

  • Navigation.

  • Forms.

  • Calls to action.

  • Product pages.

  • Checkout.

  • Search.

  • Tables.

  • Dashboards.

  • Booking interfaces.

will work on smaller screens.

Something that technically fits on a phone can still be frustrating to use.

Accessibility deserves a similar discussion.

Ask whether the project considers areas such as keyboard navigation, readable contrast, alternative text, form labels, focus states, semantic structure and accessible interactive components.

For organisations that need a recognised accessibility framework, the W3C Web Content Accessibility Guidelines (WCAG 2.2) provide an international technical standard for making web content more accessible.

You do not need to turn the agency interview into an accessibility exam.

You are trying to determine whether the developers think about the people actually using the website rather than only whether the page looks correct on their own screen.

10. What SEO Foundations Are Included During Development?

“SEO-friendly website” is too vague to be useful.

Ask what the agency means by it.

At the development level, SEO considerations can include:

  • Crawlable navigation.

  • Logical URL structure.

  • Heading structure.

  • Metadata support.

  • Canonical URLs.

  • XML sitemaps.

  • Robots directives.

  • Redirects.

  • Mobile usability.

  • Image optimisation.

  • Structured data where appropriate.

  • Performance.

  • Internal linking.

  • Indexation controls.

Google's own SEO guidance for web developers specifically covers areas developers influence, including crawlable links, sitemaps, JavaScript rendering and making content accessible to search engines.

This is important because content marketing cannot compensate for a website that search engines struggle to crawl or understand.

At the same time, be realistic about what the development proposal includes.

Website development does not automatically mean the agency will provide:

  • Keyword research.

  • Content strategy.

  • SEO copywriting.

  • Digital PR.

  • Link building.

  • Ongoing ranking monitoring.

Those may be separate services.

The important thing is to establish responsibility before launch.

A common problem is building the entire website first and then asking an SEO specialist to repair its architecture afterwards.

SEO should not dictate every technical or design decision, but the foundations should not be an afterthought.

If SEO continues beyond development, services such as technical optimisation, content SEO, site structure, internal linking and performance may need their own scope. DexNine separates these areas through its SEO and performance marketing services rather than treating every marketing activity as part of basic website development.

11. How Will You Manage Website Performance?

Ask how the development company approaches performance rather than asking whether the website will be “fast.”

The answer will vary depending on the project but may cover:

  • Image optimisation.

  • Caching.

  • Code splitting.

  • Font loading.

  • Hosting configuration.

  • Database performance.

  • JavaScript.

  • Third-party scripts.

  • CDN configuration.

  • Frontend architecture.

You should also ask how performance will be measured.

Google's Core Web Vitals documentation focuses on three aspects of real-world page experience: loading performance, responsiveness and visual stability.

That makes Core Web Vitals useful terminology during the conversation, but they should not become the only measure of website quality.

A visually impressive homepage can still create a poor experience if it contains oversized videos, unnecessary animation, excessive tracking scripts or badly optimised images.

Performance is partly an engineering issue and partly a design decision.

The best teams think about both.

12. What Is Your Approach to Security, Backups and Privacy?

Security requirements vary significantly between a five-page company website and an application processing user accounts, financial information or sensitive business data.

The development company should be able to explain what is appropriate for your project.

Depending on the system, that discussion might include:

  • Software updates.

  • Authentication.

  • Permissions.

  • Secure connections.

  • Input validation.

  • Dependency management.

  • Secrets management.

  • Backups.

  • Monitoring.

  • Deployment practices.

  • Third-party integrations.

For applications with more substantial security requirements, the OWASP Top 10 is one recognised industry resource covering common categories of web application security risk.

You do not need every company website to undergo enterprise-level penetration testing.

You do need the agency to understand the level of risk associated with what it is building.

Also establish ongoing responsibility.

Who updates dependencies after launch?

Who monitors failures?

Where are backups stored?

How frequently are they created?

How would the site be restored?

Who responds if the website is compromised?

Avoid accepting:

“The platform is secure.”

as the complete answer.

Security is not a feature that can be switched on once and then forgotten.

13. How Will the Website Be Tested Before Launch?

Testing should not consist of opening the homepage on one laptop and confirming that everything looks correct.

Ask:

What will be tested?

Who will test it?

Which browsers and devices are covered?

What happens when an issue is discovered?

For a standard business website, testing might include:

  • Navigation.

  • Important browsers.

  • Mobile layouts.

  • Forms.

  • Links.

  • Content.

  • Integrations.

  • Checkout.

  • Booking functionality.

  • Analytics.

  • Redirects.

  • Error pages.

  • Performance.

  • Accessibility basics.

Custom applications will naturally require deeper functional testing.

If your website accepts payments, manages user accounts, integrates with other business systems or performs important calculations, testing requirements become considerably more important.

You should also understand how bugs are recorded and prioritised.

A company that can explain its QA process clearly is generally easier to evaluate than one promising:

“The website will be completely bug-free.”

No meaningful software project should depend on that promise.

The goal of QA is not pretending bugs can never exist.

It is having a reliable process for finding, prioritising and fixing them.

Questions About Ownership and Long-Term Support

14. What Will We Own and Have Access to When the Project Is Finished?

Ask this before signing the contract.

Not during the handover meeting.

Clarify ownership and administrative access for:

  • Domain name.

  • Hosting account.

  • Source code.

  • Code repository.

  • CMS.

  • Database.

  • Google Analytics.

  • Google Search Console.

  • Advertising accounts.

  • Design files.

  • Third-party services.

  • Premium themes.

  • Plugins.

  • Software licences.

  • Images.

  • Fonts.

  • Other licensed assets.

Your company should know which accounts belong to you, which belong to the developer, and which tools are being licensed rather than transferred.

This becomes particularly important if you decide to work with another provider in the future.

A website should not become impossible to maintain simply because one external developer controls every account required to operate it.

Also ask whether custom source code becomes your property, is licensed to you, or remains owned by the developer.

There is no substitute for having this explained clearly in the agreement.

15. What Happens After the Website Goes Live?

Launch is a milestone.

It is not the end of the website's useful life.

Ask what happens during the first few weeks after launch and what support is available afterwards.

Will the company fix launch-related issues?

Is there a warranty period?

Is ongoing maintenance available?

Who handles:

  • Software updates?

  • Hosting problems?

  • Backups?

  • Security updates?

  • New features?

  • Content changes?

  • Performance problems?

  • Analytics issues?

Also ask how improvements will be identified.

Relevant measurements depend on the purpose of the website.

A lead-generation website might focus on:

  • Qualified enquiries.

  • Contact-form submissions.

  • Calls.

  • Conversion rate.

An e-commerce website might focus on:

  • Purchases.

  • Product discovery.

  • Checkout completion.

  • Revenue.

  • Returning customers.

A SaaS or digital platform may care more about:

  • Registrations.

  • Activation.

  • Feature usage.

  • Retention.

Search performance can also be monitored through tools such as Google Search Console, which provides information about how Google crawls, indexes and serves a website in search results.

A development company does not necessarily need to manage your marketing indefinitely.

It should, however, understand what the website was built to accomplish.

If your site needs ongoing technical, search or conversion improvement after launch, those responsibilities should become a defined maintenance or optimisation scope rather than an informal expectation.

A Simple Way to Compare Web Development Companies

Once you have spoken with several companies, do not evaluate every answer independently.

Look for patterns.

A strong development partner should be comfortable explaining decisions, limitations, trade-offs and responsibilities.

Be cautious when every answer sounds like a promise:

“We can build anything.”

“Everything is included.”

“SEO is completely taken care of.”

“There won't be delays.”

“You'll never have security problems.”

“Don't worry about the technical side.”

Real projects contain constraints.

Experienced teams tend to explain those constraints instead of pretending they do not exist.

When comparing two capable companies, consider five areas together.

Understanding

Do they understand the business problem, or are they simply responding to your feature list?

Evidence

Can they show relevant work and explain what they actually contributed?

Process

Is it clear how the project moves from requirements through design, development, testing and launch?

Responsibility

Do you know who owns decisions, accounts, testing, code and ongoing maintenance?

Communication

Are difficult questions answered clearly, or does the conversation repeatedly return to sales messages?

Price still matters.

It simply makes more sense once those questions have been answered.

Frequently Asked Questions

What should I ask a web development company before hiring them?

Ask about relevant experience, project discovery, who will work on the project, scope, pricing, timelines, technology, mobile UX, accessibility, SEO, performance, security, testing, ownership and post-launch support.

The objective is to understand how the company operates, not simply whether it can build a website.

How do I know if a web development company is good?

Look for relevant live work, clear explanations, transparent scope, realistic timelines, defined responsibilities and a documented approach to testing and support.

A technically capable agency should also be able to explain technical decisions in language that business stakeholders can understand.

What are the biggest red flags when hiring a web developer?

Warning signs include unclear ownership, vague pricing, unrealistic timelines, no testing process, no written scope, unwillingness to provide appropriate account access, and promises that everything will be handled without explaining how.

One warning sign does not automatically mean you should reject a company, but several together deserve closer attention.

Should I choose the cheapest web development company?

Not automatically.

Compare what each proposal includes, the quality of the proposed solution, expected ongoing costs, ownership arrangements, technical support and the likelihood of requiring substantial rework later.

The useful comparison is cost against scope, capability and risk, not price alone.

Should a web development company handle SEO?

A development company should at least understand the technical foundations affecting search visibility.

Full keyword research, content strategy, SEO content, digital PR and ongoing optimisation may be separate services.

Clarify responsibilities before development begins.

Who should own the website after development?

Ownership should be clearly defined in the contract.

Your business should normally have appropriate control or administrative access to essential assets required to operate the website, including the domain, hosting, CMS, analytics and relevant third-party services.

Source-code ownership and software licences should be discussed separately because contractual arrangements can differ.

How long should a web development project take?

There is no useful universal timeframe.

A small marketing website and a custom business platform are fundamentally different projects.

Requirements, number of page templates, integrations, design complexity, content availability, stakeholder approvals and testing all influence the schedule.

Instead of asking only for the completion date, ask the company how it calculated that date.

Choosing the Right Development Partner

The best web development company is not necessarily the agency with the largest team, the cheapest proposal or the most impressive list of technologies.

It is the company that understands what you are trying to achieve and can clearly explain how it intends to get you there.

Use these 15 questions with every company you shortlist.

Ask the same core questions.

Take notes.

Compare the substance of the answers rather than relying entirely on the sales presentation.

You can also review a company's previous website and application work, services, technical capabilities and working approach before arranging a meeting. That usually gives you better questions to bring into the conversation.

If you are considering DexNine as one of your options, explore its website development capabilities and previous projects first.

Then bring this checklist to the conversation.

A useful first discussion should help clarify the project even if you have not yet decided exactly how it should be built.