Every web development conversation eventually covers the same ground cost, timeline, ownership, what happens if something goes wrong. This post answers the 18 questions that come up most often, in one place, so you have clear answers before you start any vendor conversation.

Cost and Budget

1. How much does a website actually cost?

Costs range widely by type: basic brochure sites run $2,000–$8,000, business websites with a CMS run $5,000–$30,000, and eCommerce starts around $10,000 and scales from there. The main drivers are page count, design complexity, integrations, and content needs. For a full breakdown by website type, see our guide on website costs in 2026.

2. Why do quotes vary so much between companies?

Quotes vary because vendors interpret vague briefs differently, price for different team structures, and sometimes underquote to win work before charging for additions later. A detailed brief sent to multiple vendors produces far more comparable quotes than a general description of "a website."

3. Is the quoted price the final price?

It should be, if scope doesn't change. A fixed-price quote based on a clear specification holds unless you request additions beyond what was agreed these become scope changes, priced separately. Quotes based on vague requirements are more likely to expand once real requirements emerge.

4. What's not included in a typical quote?

Development quotes commonly exclude hosting, domain registration, premium plugin or theme licences, content creation (copywriting and photography), and ongoing maintenance after launch. These add $1,500–$9,000 per year depending on site complexity.

Timeline and Process

5. How long does a website take to build?

A basic site takes three to six weeks, a CMS-driven business site takes six to ten weeks, eCommerce takes eight to sixteen weeks, and custom web applications take four to nine months. These ranges assume ready content and responsive feedback see our full timeline breakdown for details.

6. What causes projects to run late?

The most common causes are slow client feedback, content not being ready when needed, scope additions after the project starts, and unclear decision-making authority on the client side. Technical problems are a less frequent cause than buyer-side delays.

7. How much input will I need to give during the project?

More than buyers often expect. Design rounds require feedback within days to stay on schedule, content needs to be supplied or approved, and questions arise during development that need quick answers. A single point of contact with authority to approve decisions keeps things moving fastest.

8. Can I see progress during the build, or only at the end?

You should see progress at defined stages wireframes, design mockups, and a working build in a staging environment before launch. A vendor who shows nothing until the final reveal is not following a standard process, and that absence of visibility is itself worth questioning.

Design and Content

9. Do I need to provide content, or will the developer write it?

This depends entirely on what's agreed in the brief. Many clients provide their own copy and images; others commission copywriting and photography as part of the project. What matters is that responsibility is assigned clearly upfront content readiness is the most common cause of launch delays.

10. How many design revisions do I get?

Standard engagements typically include two to three rounds of revisions, agreed in advance as part of the project specification. Unlimited revisions aren't realistic in practice; defining the number upfront prevents open-ended cycles that extend timelines indefinitely.

11. What if I don't like the design?

Design happens in stages, wireframes first, then visual design specifically so structural concerns are caught early, before visual work is built out. If the visual direction doesn't land within the agreed revision rounds, this should be discussed directly with your project contact rather than absorbed silently into extra unpaid rounds.

12. Can I update the website myself after it's launched?

If your site is built on a CMS such as WordPress, yes you can edit content, add pages, and publish updates without developer involvement. Structural changes, new functionality, or design changes still typically require developer support. Our post on what a CMS is covers this distinction in detail.

Technical and Ownership

13. Will my new website affect my Google rankings?

It can, in either direction. A redesign that changes URLs without proper redirects can cause significant ranking drops. A redesign done correctly with redirects mapped and content continuity preserved typically maintains or improves rankings, particularly if the old site had performance or technical issues. Our redesign checklist covers this in full.

14. Do I own the website once it's built?

You should. A proper contract specifies that code, design, and content become your property upon final payment. Some contracts retain ownership or use licensing terms that limit this, reviewing IP clauses before signing is essential, and is covered in our post on red flags when hiring a web development company.

15. What happens if I want to switch developers later?

If your site is built on a widely-used platform such as WordPress or Shopify, switching developers is straightforward and a large pool of developers can work with these platforms. Highly custom or niche technology choices make switching harder and more expensive, which is a long-term consideration worth factoring into your initial platform decision.

16. Is WordPress secure enough for a business website?

Yes, when properly maintained. WordPress is the most-targeted CMS by volume simply because of its popularity, but a site with regular updates, a security plugin, strong authentication, and reliable backups is not inherently at risk. Security issues on WordPress are almost always a maintenance gap, not a platform flaw.

After Launch

17. What support do I get after the site goes live?

This varies by vendor and should be defined before you sign. At minimum, expect a short period of post-launch monitoring to catch issues that only appear under live conditions. Beyond that, ongoing support updates, fixes, monitoring is typically a separate maintenance arrangement. 

18. What if something breaks after launch?

This depends on your support arrangement. With a maintenance retainer, fixes are typically covered as part of the agreement with a defined response time. Without one, fixes are billed as needed. Either way, confirming this before launch discovering there's no support plan only when something breaks is one of the most common post-launch frustrations.

Still Have a Question?

If your question isn't covered here, the most efficient next step is a direct conversation. Most remaining questions are specific to your project's particular requirements, budget, or platform, and are best answered with your situation in view rather than in general terms.