A useful website quote starts with what must work.

Inventory the content before counting pages

List the pages that customers need to make a decision: services, pricing where appropriate, company information and a clear way to contact you. Separate content that already exists from material that needs interviews, writing, photography or approval. A designer cannot create accurate company facts by choosing a template.

A ten-page brochure site and a ten-page site with a product catalog, member access or complex quoting logic are not equivalent projects. Describe the actions visitors need to complete, not just the menu labels. Each integration adds decisions about data, permissions, error handling and maintenance.

Decide who will edit the site

The right platform depends partly on who maintains content. Explain whether staff need to update services, add resources, manage products or change landing pages without development help. Ask to see how those tasks would work in the proposed setup, including any role or subscription requirements.

Dappr designs and develops websites on most builders. Platform selection should follow the requirements rather than a claim that one builder is best for every business. Custom code, a builder and a commerce platform can each be appropriate for different needs. Confirm what is included before assuming a platform name describes the whole scope.

Include the work around launch

For an existing website, preserve valuable URLs or map them to relevant replacements. Account for contact-form delivery, mobile layouts, keyboard access, metadata and analytics choices. A polished home page does not prove that every inquiry reaches the right person or that older links continue to work.

Agree on what the acceptance review covers. Identify who supplies final copy, who checks business claims and who approves launch. If the project depends on a third-party booking or payment service, identify the account owner and subscription cost. Do not place account credentials in a design brief.

Compare initial and ongoing costs separately

A project quote should distinguish discovery, design, implementation, content work and launch support. The ongoing cost may include domain registration, hosting, platform subscriptions, maintenance and future changes. Ask which accounts belong to your business and what happens if you change providers.

Dappr's recurring marketing plans are not a substitute for a scoped full-website quote. Major website builds can be separate projects. This guide does not publish a fabricated Utah market average or imply that every build includes a free domain, free hosting or unlimited revisions. Those terms must appear in the actual agreement.

A practical brief to send with your inquiry

Include the current website, intended audience, page list, required integrations and a short description of the action you want visitors to take. Note which content is ready and which needs to be produced. Give the desired launch date and explain any event or dependency behind it.

Request a scope that states deliverables, revision boundaries, account ownership and support after launch. Compare proposals against that same brief. If the prices differ, ask what work or responsibility differs before assuming the more expensive proposal is unnecessary or the cheaper proposal is incomplete.

Compare page types before comparing page counts

A ten-page brochure site and a ten-page site with customer accounts are not equivalent builds. List the different page types and the behavior each requires. A service page may use a shared layout with original copy. A searchable directory needs data and filtering. A booking page may depend on an outside system. This inventory makes the work behind the page count visible.

For each page type, identify who supplies the content, who edits it and how it will be maintained. Ask whether the estimate includes migration of existing text, image preparation, new writing and review. If your team must supply material, give it a delivery date tied to the project schedule. Missing content is a dependency, not a reason to publish invented claims.

Decide which changes need a content-management interface. A business that regularly adds products or articles may need an editing workflow that a small static brochure does not. Conversely, adding a complex editing system to a rarely changed page can create maintenance work without solving a real problem. Compare the actual editing tasks your staff will perform after launch.

Budget for a migration as a migration

A redesign of an existing site should begin with an inventory of useful URLs and business functions. Record which pages remain, which move and which are intentionally retired. Include inquiry forms, downloadable material and tracking behavior in that inventory. The visible design is only one part of replacing a site that customers and search engines already use.

Ask whether redirect planning, content migration and launch verification are included. A provider should explain how important old links will reach the appropriate new destinations. Sending every retired URL to the homepage can conceal missing content rather than solve the customer’s problem. Keep a reviewable mapping for actual changes, and preserve useful URLs when a new address is unnecessary.

Separate migration risk from a promise about rankings. A careful release can verify redirects, page content and inquiry delivery, but it cannot guarantee how a search engine will respond. The useful comparison is whether a proposal includes the preparation and checks needed for your site. A lower price that omits those responsibilities may simply move the work onto your team.

Make the form and follow-up part of the estimate

A contact form should be scoped as a complete interaction. Define the required fields, confirmation behavior and destination for the inquiry. Include validation, a useful error message and an alternative contact route when delivery is unavailable. A button that appears to work is insufficient if nobody can find the inquiry afterward.

If your project connects to Dappr’s own CRM, specify what information is passed and how the receiving record will be checked. Decide which attribution details are needed without collecting unnecessary personal information. Do not assume that an integration with a different CRM is included. The actual destination and responsibilities should be agreed before implementation.

Use a clearly labeled test during acceptance and coordinate it with the people who receive notifications. Verify the submitted fields and the user’s confirmation screen. If automated follow-up is in scope, review that content and its conditions separately. Testing the inquiry path provides a concrete acceptance result and prevents a design review from overlooking the site’s main business action.

Specify quality checks you can actually review

Ask which representative pages and devices will be checked. Review navigation, readable content, keyboard access, forms and layout at narrow widths. An accessibility review should explain its scope and remaining limitations instead of presenting a generic badge as proof. The estimate should identify who fixes issues found during the agreed testing period.

Performance work should consider images, fonts, scripts and the amount of content the browser must load. Google’s web.dev performance course covers these as distinct areas of work. A proposal that promises a score without stating the pages, test conditions and included third-party tools is difficult to assess. Ask for a practical plan and evidence from the finished implementation.

Keep laboratory checks separate from actual visitor measurements when reporting results. A local test can help find a problem before launch, while field data may require enough real visits to become available. Neither should be fabricated to fill a report. Record the tested page and conditions so a later comparison is meaningful.

Ask what changes after the handover

A useful handover names the owner of the domain, hosting account, website files and editing access. It also explains backups, routine updates and the support route. Confirm which services continue after launch, how they are charged and what your team must maintain. Free introductory services, if offered in a specific agreement, should have clear terms.

Define the difference between correcting an agreed defect and adding a new feature. A short support period may cover defects without including ongoing design changes. Ask how later requests are estimated and what information the maintainer needs. Clear boundaries help the business plan its next improvement without reopening the meaning of the original quote.

Sources and further reading

• https://trydappr.com/about/faq
• https://trydappr.com/services/web-design
• https://web.dev/learn/performance