Web Development Planning

Questions to Ask a Web Developer Before Starting a Business Website or Web Application Project

Knowing the right questions to ask a web developer before starting a business website or web application project helps you turn a broad idea into an accountable plan. The purpose is not to test whether a developer can use technical vocabulary. It is to confirm that the person or team understands your business outcome, users, required features, content, integrations, security exposure, delivery constraints, ownership expectations, and post-launch responsibilities.

Most preventable project problems begin before coding. A vague request such as “build a modern website” can conceal very different expectations about lead generation, ecommerce, customer accounts, dashboards, automated workflows, search visibility, multilingual content, internal approvals, and data protection. When these expectations are not translated into deliverables and acceptance criteria, the project can appear on schedule while still moving toward the wrong result.

This guide gives founders, operations teams, marketing leaders, product owners, procurement teams, agencies, and established businesses a practical discovery and provider-selection checklist. It covers websites and custom web applications, including how to discuss scope, technology, cost, milestones, testing, accessibility, security, intellectual property, hosting, maintenance, and handover. It also explains when a freelancer, agency, dedicated professional, or managed development team may be the better fit.

Quick Answer: What Should You Ask a Web Developer Before Starting?

Ask the developer to explain what will be built, why it supports the business goal, who will do each part, how the work will be tested, what the project will cost under stated assumptions, and what your business will own at the end. The strongest answers are specific enough to become contractual deliverables, milestone criteria, or documented responsibilities.

At minimum, cover business objectives, target users, pages and features, integrations, content, data migration, technology choices, responsive behavior, accessibility, performance, security, analytics, search requirements, environments, testing, launch, support, and handover. Ask what is excluded as carefully as you ask what is included.

Do not choose a supplier only because the proposal has the lowest price or shortest timeline. Compare discovery quality, relevant experience, communication, governance, security awareness, testing discipline, ownership terms, and the clarity of the statement of work. A short paid discovery phase is often safer than committing to a large build based on assumptions.

Key Takeaways

• Start with the business outcome: define the action the website or application must enable and how success will be measured.
• Convert conversations into scope: pages, features, roles, integrations, content, dependencies, and exclusions should be written down.
• Ask for acceptance criteria: every important deliverable needs an objective way to confirm completion.
• Protect ownership and access: your business should control domains, repositories, hosting, analytics, design files, and production accounts.
• Plan security and accessibility early: they affect architecture, design, content, testing, and cost.
• Separate defects from new requests: use a defined change-control process to prevent budget and timeline confusion.
• Require a handover: source code, documentation, credentials, licences, backups, deployment instructions, and support responsibilities must be clear.

What This Page Covers

• The questions to prepare before contacting a web developer.
• How to distinguish a marketing website, ecommerce site, portal, and custom web application.
• How to discuss scope, technology, integrations, content, cost, and timeline.
• How to compare a freelancer, agency, dedicated developer, and managed team.
• How to set security, accessibility, performance, testing, and launch expectations.
• How to manage ownership, change requests, support, maintenance, and handover.
• How Rudrriv can support discovery, defined projects, dedicated professionals, or managed development delivery.

Table of Contents

1. How this guide was prepared
2. What to prepare before the first meeting
3. The essential questions to ask
4. Scope, deliverables, and acceptance criteria
5. Freelancer vs agency vs dedicated professional vs managed team
6. Technology, security, accessibility, and performance
7. Budget, timeline, payments, and change control
8. Testing, launch, support, and handover
9. Practical project examples
10. Final developer-selection checklist

How this guide was prepared

This guide is based on practical requirement discovery, provider selection, project governance, quality assurance, account ownership, and delivery-management considerations used in business website and web application projects. It also directs readers to established technical references rather than treating a sales proposal as the only source of truth.

Accessibility expectations should be discussed against the W3C Web Content Accessibility Guidelines 2.2. Application teams can use the OWASP Application Security Verification Standard to define security controls and verification depth. Performance requirements can refer to Google's Web Vitals guidance, while implementation teams can consult MDN guidance on responsive web design and its website security overview.

Technical standards, browser behavior, platform features, vendor prices, hosting services, legal obligations, and provider capabilities can change. Verify current requirements with authoritative documentation and qualified legal, privacy, security, or compliance advisers where the project processes regulated or sensitive information.

What should you prepare before meeting a web developer?

Prepare a concise business brief before discussing technology. The developer needs enough context to identify uncertainty, propose a discovery process, and avoid designing around assumptions.

Define the business result

State the outcome in operational terms. Examples include generating qualified enquiries, enabling customers to purchase, reducing manual order processing, providing a partner portal, allowing staff to approve requests, or replacing an unsupported internal tool. Avoid treating “launch a website” as the result; launch is a milestone, not the business outcome.

• Which customer or employee problem should the solution reduce?
• What action should a user complete?
• Which measurable indicators will show improvement?
• What would make the project unsuccessful even if the site technically works?

List users, roles, and critical journeys

Identify primary users and the tasks each must complete. A public visitor, registered customer, sales representative, content editor, finance reviewer, and system administrator have different permissions and risks. For a web application, document the main journey from entry to completion, including exceptions such as failed payment, incomplete data, rejected approval, or forgotten password.

Collect constraints and dependencies

Tell the developer about the required launch date, internal approval process, existing brand guidelines, content readiness, data sources, integration owners, hosting policies, procurement rules, languages, countries, legal review, and internal technical capability. A date tied to an event or regulatory deadline requires a different delivery strategy from a flexible target.

The essential questions to ask a web developer

The best questions reveal how the developer converts business uncertainty into a controlled delivery process. Ask for examples, documents, and decision rules rather than accepting broad assurances.

1. What do you understand about our business goal and users?

A capable developer should restate the problem in clear language and identify missing information. Listen for questions about audience, customer journey, internal workflow, conversion action, operational constraints, and success measures. If the discussion moves immediately to themes, frameworks, or programming languages, discovery may be too shallow.

2. Are we building a website, ecommerce experience, portal, or web application?

Ask the developer to classify the solution and explain the boundary. A business website primarily presents information and supports marketing. Ecommerce adds catalogue, cart, payment, fulfilment, tax, and order workflows. A portal serves authenticated groups. A web application processes data, roles, business rules, and workflows. The classification affects architecture, testing, security, support, and budget.

3. What discovery work is required before you estimate the build?

Discovery may include stakeholder interviews, user journeys, content inventory, feature mapping, integration review, technical audit, risk assessment, prototype, and backlog creation. Ask what artifact you will receive. A paid discovery should produce reusable outputs such as requirements, architecture notes, wireframes, priorities, assumptions, and a delivery estimate.

4. What is included, excluded, and assumed in your proposal?

Request a written list of pages, templates, components, features, integrations, data migration tasks, content responsibilities, environments, testing, training, and post-launch support. Exclusions might include copywriting, photography, product-data cleanup, licence fees, hosting, security testing, accessibility audit, or integration charges. Assumptions should explain client response times, content readiness, third-party API availability, and the number of review cycles.

5. Who will work on the project, and who is accountable?

Ask for named roles: project owner, business analyst, UX designer, UI designer, frontend developer, backend developer, QA specialist, DevOps or cloud specialist, and security reviewer where relevant. A small project may combine roles, but accountability must remain clear. Confirm whether work is subcontracted and how continuity is maintained if a team member becomes unavailable.

6. Why are you recommending this technology stack?

The answer should connect technology to requirements, internal skills, security, performance, scalability, hosting, licence cost, integration support, and future maintenance. Ask what alternatives were considered and what trade-offs exist. Avoid accepting “it is the best” without project-specific reasoning.

7. How will content, data, and integrations be managed?

Clarify who supplies copy, images, product information, translations, legal text, and structured data. For integrations, identify the system owner, API limits, test environment, data mapping, error handling, and support responsibility. For migration, ask how data will be cleaned, transformed, validated, reconciled, and protected.

8. How will you address accessibility, responsive behavior, and performance?

Ask which devices and browsers will be supported, what accessibility target will be used, and how performance will be tested. Require practical acceptance criteria—for example, keyboard operation of core journeys, meaningful alternative text, readable focus states, responsive layouts, optimized images, and agreed Core Web Vitals or laboratory performance targets where appropriate.

9. What is your security and privacy approach?

For a basic brochure site, security still includes software updates, secure administration, backups, least-privilege access, spam protection, and safe hosting. A custom application may require threat modelling, secure authentication, authorization rules, encryption, secrets management, audit logs, vulnerability scanning, penetration testing, incident handling, and data-retention controls. Ask who verifies these controls and what evidence is delivered.

10. How do milestones, demos, approvals, and changes work?

Require a delivery rhythm. Each milestone should identify outputs, review period, responsible approver, and acceptance criteria. Ask how feedback is consolidated and what happens when a request changes an approved requirement. A change request should describe impact on scope, price, and timeline before work proceeds.

11. What testing will be completed before launch?

Testing should match risk. Ask about functional, integration, responsive, browser, accessibility, performance, security, analytics, content, migration, regression, backup, and recovery testing. Confirm who performs user acceptance testing and whether defects are classified by severity.

12. What will we own, and what will you hand over?

Clarify ownership of custom code, configurations, databases, documentation, design files, content, repositories, domains, hosting, third-party accounts, and licences. Ask for a complete handover list and secure credential-transfer process. Open-source or commercial dependencies may retain their original licences; the developer should identify them.

13. What support, warranty, and maintenance are available after launch?

Separate a defect warranty from ongoing maintenance and new feature work. Ask about support hours, response targets, severity levels, monitoring, backups, software updates, dependency upgrades, security patches, hosting management, release process, and reporting. Define who responds if an integration or third-party platform changes.

How should scope, deliverables, and acceptance criteria be defined?

A useful scope describes observable outputs and responsibilities. It should allow a business stakeholder and delivery team to reach the same conclusion about whether a milestone is complete.

Use plain language alongside technical detail. “Customer can submit a support request and receive a reference number” is clearer than a feature label such as “ticket module.” For critical flows, add examples of valid input, errors, permissions, notifications, and reporting.

Freelancer vs agency vs dedicated professional vs managed team

The right delivery model depends on scope breadth, continuity needs, coordination load, risk, and internal management capacity.

A freelancer may be excellent for a defined landing-page build but unsuitable for a business-critical application requiring architecture, UX, backend development, QA, DevOps, and continuous support. Conversely, a large agency can add unnecessary overhead to a small, well-defined task. Match the model to the actual work rather than assuming one category is always safer.

Technology, security, accessibility, and performance questions

Technical quality must be expressed as requirements and verification, not as a list of tools. Ask the developer to explain decisions in business terms and identify the evidence that will confirm quality.

Technology and maintainability

• Is the proposed platform suitable for our expected content, workflows, users, and integrations?
• Can our team or another supplier maintain it without proprietary lock-in?
• Which components are custom, open source, commercial, or hosted services?
• How are dependencies updated, tested, and documented?
• What happens if a vendor changes pricing, features, or support?

Security and privacy

Ask for a security requirement set proportional to the data and business impact. An application holding customer records or enabling payments needs more rigorous verification than a static marketing page. Discuss access control, authentication, authorization, input validation, session handling, file uploads, encryption, secrets, logs, backups, dependency risks, and incident response. Confirm whether independent testing is required and who remediates findings.

Accessibility

Accessibility is not a final visual check. It affects semantic HTML, keyboard use, focus management, colour contrast, forms, error messages, media, content, and component behavior. Ask which WCAG version and conformance target applies, who tests, whether assistive-technology testing is included, and how issues discovered after launch are handled.

Performance and scale

Define realistic traffic, geographic distribution, content weight, concurrent use, and transaction volume. Ask how images, fonts, scripts, caching, database queries, APIs, and third-party tags will be managed. For an application, discuss load testing and capacity planning. For a public website, agree meaningful page-speed and user-experience targets without treating a single laboratory score as the only measure.

Budget, timeline, payments, and change control

A credible estimate states what is known, what remains uncertain, and which assumptions affect cost. Ask for the estimate structure rather than only the total.

Fixed price, time and materials, or hybrid?

Fixed price works when scope and acceptance criteria are stable. Time and materials works when priorities will evolve, provided you receive transparent time records, regular demonstrations, backlog control, and budget forecasts. A hybrid may use fixed-price discovery followed by milestone or capacity-based delivery.

What should trigger payment?

Connect payments to defined milestones, capacity periods, or accepted deliverables. Avoid paying most of the fee before useful evidence exists. At the same time, recognize that discovery, design, architecture, and setup are real work. The schedule should be commercially fair and support continuous delivery.

How should changes be approved?

A change-control process prevents informal requests from becoming disputes. The developer should record the request, explain impact, propose options, and obtain approval before changing scope, cost, or dates. Small changes can be managed through an agreed allowance; larger changes may require a revised milestone or backlog priority.

Testing, launch, support, and handover

Launch should be a controlled release with a rollback path, not the first time the full solution is tested.

Ask for a test and acceptance plan

The plan should map requirements to tests and identify environments, test data, responsible people, defect severity, retesting, and approval. Business stakeholders should complete user acceptance testing on realistic journeys. For data migration, require reconciliation showing what moved, what failed, and how exceptions were resolved.

Ask for a launch checklist

• Production domain, SSL, hosting, and access confirmed.
• Backups and rollback tested.
• Forms, emails, payments, integrations, and permissions verified.
• Analytics, consent, search, redirects, and error pages checked.
• Performance, accessibility, and security issues reviewed.
• Monitoring, alerts, support contacts, and incident procedure active.
• Stakeholders approve release and post-launch observation period.

Define the handover package

The package should include source code and repository access, production and staging details, architecture notes, database or data dictionary where relevant, third-party services, licences, design files, content instructions, deployment process, backup and recovery procedure, test evidence, known issues, administrator training, credentials transferred securely, and a list of support responsibilities.

Common mistakes and warning signs to avoid

The largest web-project losses often come from weak decisions before development begins.

• Starting with a visual brief only: design cannot compensate for unclear users, content, workflows, or success measures.
• Accepting a quote without assumptions: missing content, integrations, migration, or testing can appear later as extra cost.
• Choosing technology by trend: fashionable tools can increase maintenance burden without improving the outcome.
• Leaving ownership vague: the business may lose control of domains, code, data, or accounts.
• Skipping security requirements: security added at launch may require architectural rework.
• Treating accessibility as optional polish: late remediation can be slower and more expensive than accessible design and development.
• Using unlimited revisions language: it hides poor governance and creates conflicting expectations.
• No acceptance criteria: both sides can disagree about whether a feature is complete.
• No backup or rollback plan: launch risk increases when recovery has not been tested.
• No maintenance owner: unsupported dependencies, certificates, integrations, and content systems can degrade after launch.

Practical examples: matching questions to the project

Example 1: A professional-services website for qualified leads

A consulting firm wants a new website because the current one looks dated. The better discovery question is whether the site attracts the wrong enquiries, fails to explain services, or makes trust difficult to assess. The project may require service architecture, expert profiles, case-study templates, lead forms, analytics, content migration, responsive design, accessibility, and search foundations. A custom application stack may be unnecessary; content quality and conversion flow may matter more.

Example 2: An ecommerce business connecting stock and fulfilment

An online retailer needs a redesigned storefront plus inventory and fulfilment integrations. Before estimating, the developer should ask about catalogue volume, variants, pricing rules, tax, payment providers, returns, warehouses, inventory ownership, API reliability, reconciliation, peak traffic, and operational exceptions. The right scope includes integration testing, failure alerts, data ownership, rollback, and staff training—not only front-end pages.

Example 3: An internal approval web application

An operations team wants to replace spreadsheets with a request-and-approval application. Important questions cover user roles, approval limits, delegation, audit logs, attachments, notifications, reporting, retention, single sign-on, data sensitivity, and exception handling. A phased MVP can begin with one workflow and a controlled user group. The project should not launch broadly until permissions, auditability, recovery, and user acceptance are verified.

Questions to ask a web developer: final selection checklist

Use this checklist before approving a proposal, statement of work, or purchase order.

• The developer can clearly restate the business problem, users, and desired outcome.
• The proposed solution type—website, ecommerce, portal, or web application—matches the real requirement.
• Discovery outputs, pages, features, roles, integrations, and exclusions are documented.
• Technology choices are justified by maintainability, security, performance, cost, and internal capability.
• Named team roles and the accountable project owner are clear.
• Content, data, migration, and third-party responsibilities are assigned.
• Accessibility, responsive behavior, performance, and security have measurable requirements.
• Milestones include demos, review periods, approval owners, and acceptance criteria.
• Pricing assumptions, payment triggers, third-party costs, and change control are transparent.
• The business controls domains, repositories, hosting, analytics, and production accounts.
• Testing covers functionality, integrations, devices, accessibility, performance, security, and recovery as required.
• Launch includes monitoring, rollback, support contacts, and post-release observation.
• The warranty, maintenance, response expectations, and new-feature process are separated.
• The handover package includes code, files, documentation, licences, credentials, and training.

Summary: Questions to Ask a Web Developer Before Starting a Business Website or Web Application Project

The right questions create shared understanding before development cost and complexity increase. Begin with users and business outcomes, then define scope, responsibilities, technology, quality requirements, ownership, commercial controls, launch, and ongoing support. Ask the developer to show how each important promise will be documented and verified.

A strong provider will not claim that every uncertainty can be removed on day one. Instead, it will identify assumptions, recommend discovery where necessary, demonstrate work regularly, manage changes openly, and protect your ability to operate the solution after handover.

Frequently Asked Questions

What questions should I ask a web developer before starting a business website or web application project?

Ask about business goals, users, scope, technology, integrations, content responsibilities, accessibility, security, performance, testing, milestones, pricing assumptions, ownership, hosting, maintenance, support, and handover. Require important answers to be reflected in the proposal or statement of work rather than left as informal conversation.

How do I know whether I need a website or a web application?

A website mainly publishes information and supports marketing or transactions through relatively standard flows. A web application usually includes authenticated users, roles, data processing, dashboards, workflows, or integrations. Many projects combine both. Ask the developer to separate public website needs from application functions so cost and architecture are not blurred.

Should a developer recommend the technology stack before discovery?

A developer can discuss likely options, but a firm recommendation should follow discovery of users, features, integrations, traffic expectations, security needs, internal skills, hosting constraints, and maintenance plans. Technology should be chosen for fit and supportability, not because it is fashionable or simply preferred by the supplier.

What should be included in a web development statement of work?

Include objectives, deliverables, page or feature scope, integrations, content and data responsibilities, milestones, acceptance criteria, environments, testing, accessibility and performance requirements, security controls, exclusions, change control, pricing, payment triggers, intellectual-property terms, support, warranty, and handover items.

Who should own the domain, hosting, source code, design files, and third-party accounts?

The business should normally control the domain, hosting or cloud tenant, analytics, email, payment, repository, design files, and production accounts. The contract should state when source code and custom assets transfer, what third-party licences remain restricted, and how credentials and administrative access will be handed over securely.

How should website or web application security be discussed before development?

Ask how authentication, authorization, data validation, secrets, logging, backups, dependency updates, vulnerability testing, incident response, and least-privilege access will be handled. For applications with sensitive data or business-critical workflows, define security requirements and verification activities before development rather than adding them at launch.

How can I compare fixed-price and time-and-materials proposals?

Compare the certainty of the scope, not only the headline fee. Fixed price works best when requirements and acceptance criteria are stable. Time and materials suits evolving products but requires backlog control, regular demos, budget visibility, and prioritization. A hybrid can use fixed discovery followed by milestone-based or capacity-based delivery.

What testing should happen before a business website launches?

Testing should cover agreed functionality, responsive layouts, supported browsers, forms, integrations, content, accessibility, performance, analytics, redirects, security checks, backups, roles, error handling, and recovery procedures. The business should complete user acceptance testing against written acceptance criteria before production approval.

What ongoing support should I ask a web developer to provide?

Clarify the warranty period, response times, support hours, severity definitions, monitoring, backups, security updates, dependency maintenance, content or feature changes, hosting responsibilities, release process, and monthly reporting. Separate defect correction from new development so support expectations remain clear.

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

Warning signs include quoting without discovery, vague deliverables, no named owner, refusal to provide repository or account access, weak security answers, no testing plan, no change-control process, unclear ownership, unrealistic timelines, dependence on one undocumented person, and a proposal that excludes launch support or handover.

Need help defining the right web development engagement?

Share your business goal, intended users, current systems, priority features, target timeline, and internal capacity. Rudrriv can help structure requirement discovery, a defined website or web application project, a dedicated development professional, ongoing technical support, or a managed delivery team with clear responsibilities and controls.

Discuss your requirement

Explore Rudrriv's development services and specialist talent options when you need scoped delivery or additional technical capacity.

At Rudrriv, we make it easier for businesses to access the right expertise, execute important work, and scale with confidence.