Motta Industries Blog

Three web development quotes arrive with three different totals. One promises a complete website, another lists design and development separately, and the third offers a monthly arrangement. Choosing the smallest number would be easy if they described the same job.

Usually, that is the first thing to establish. A quote is a proposed set of deliverables, responsibilities, assumptions, and exclusions. Its price makes sense only in relation to those details.

Build a comparison before negotiating the total. You do not need to turn every proposal into the same document, but you should be able to explain what each supplier will deliver, what your team must provide, and what remains outside the agreement. That explanation is more useful than a confident guess about which company is expensive.

Put the same business brief beside every proposal

Start with the customer tasks and staff workflows the project must support. List the problems you expect the work to address and the constraints that matter, such as an existing store, a required integration, or a deadline tied to an operational change.

Check that each supplier received the same information. If one inspected the existing site while another estimated from an email, record that difference. A preliminary estimate and a defined implementation proposal are not directly comparable just because both contain a total.

Make a comparison sheet with one row per work area and one column per proposal. Add separate columns for your questions and the supplier’s response. Keep unanswered items visible rather than filling them with what you hope the price includes.

Our website services overview can help you identify relevant work areas. The comparison should still follow your actual project, not assume you need every discipline simply because it appears on a service list.

Identify allowances and dependencies

Mark work that is estimated, optional, dependent on discovery, or subject to another provider’s response. Ask what would change the price and how that change would be approved. An allowance is useful when its limits are understandable; it is confusing when it looks like a firm commitment.

Compare deliverables rather than broad labels

A line called design can mean very different things. Ask which layouts, page types, states, and revisions are included. Identify whether the supplier is adapting an existing structure or developing a different approach for your content and customer tasks.

Do the same for development. List the functions included in the delivered site, the systems they connect to, and any meaningful limits. A contact form, a booking workflow, and a custom estimating tool should not disappear into a single unexplained line.

Clarify what a page count means. Does it refer to unique layouts, entered content pages, product pages, or something else? Ask how additional pages using an existing layout will be handled. You need a rule your team can apply, not an argument after the content is ready.

For integrations, ask which side of the connection the supplier controls and what information or cooperation is needed from another provider. Record testing responsibility and any outside charges separately from the website work.

Find the content work hiding between the lines

Ask who will write, edit, approve, and enter the content. Separate those jobs. A supplier may include entering approved text without including interviews, research, rewriting, or organizing the service information.

Include images and documents in that review. Identify who supplies them, who confirms usage rights, who prepares suitable versions, and who checks the result. If the proposal assumes you will provide everything ready to use, make that assumption visible to the people doing the work.

Review migration separately from new content. Moving existing pages, products, documents, and relevant data can require decisions about what remains, what changes, and what should be retired. Ask for the included volume, exclusions, and review process.

Do not dismiss content responsibilities as administration. They can determine whether the project is ready for design, development, and launch. Your comparison should include the time and decisions your staff must contribute, even when those costs do not appear on the supplier’s invoice.

Define what acceptance will look like

A proposal should explain how the parties decide that work meets the agreed scope. Tie acceptance to the customer and staff tasks in your brief rather than a vague promise that the website will be professional.

List the important test conditions: supported devices and browsers, key forms, payment routes where applicable, editing workflows, error states, and integration results. Ask what evidence you will receive and who reviews it before launch.

For accessibility, WCAG 2.2’s dated standard provides criteria and conformance levels. Ask which level and pages or processes the supplier is proposing to evaluate, which testing methods are included, and how identified issues will be handled. A word such as accessible is not a complete testing scope.

Separate an agreed requirement from an optional enhancement discovered during review. Both may be worth doing, but they should not be priced or approved through an ambiguous conversation about finishing touches.

Compare the review process too

Ask how feedback will be collected, consolidated, and resolved. Identify the number of included review rounds where relevant and what counts as a change in direction. Your business should know who has final approval so conflicting staff comments do not become unexplained rework.

Read the ownership and licensing lines carefully

Ask what your business will receive at handover: account control, relevant code and assets, instructions, licenses, and the ability to continue operating the site. Record any dependencies that remain managed through the supplier.

Distinguish the underlying software license from the paid work involved in planning, building, configuring, and maintaining the site. WordPress’s license page states that the software is released under GPLv2 or later. That fact does not describe the scope of a developer’s services or answer every question about the materials in your project.

Ask separately about custom code, design files, photographs, fonts, paid extensions, and outside services. Which terms apply to each? What subscriptions must your business maintain? What happens if the relationship ends? Obtain appropriate legal advice where the agreement or rights are unclear.

Do not accept a broad ownership assurance as a substitute for these answers. Put the agreed handover deliverables and responsibilities in the written scope so the comparison reflects the arrangement you would actually buy.

Compare ongoing costs on a consistent basis

Separate one-time work from recurring charges. Identify hosting, maintenance, licenses, support, and other ongoing services. Ask which are required for the proposed arrangement and which are optional.

For maintenance, request the actual duties, frequency, exclusions, and response expectations. Updating software, testing a recovery copy, making content changes, and handling an incident are different tasks. Do not assume the monthly figure includes all of them.

Software lifecycles belong in the discussion. PHP’s supported-version policy distinguishes active support, security fixes only, and end of life. Ask how the proposed website’s dependencies will be tracked and how compatibility work or upgrades will be estimated over time.

Use the same comparison period for recurring charges across proposals and record your assumptions. You are not predicting every future expense. You are avoiding a decision that compares one supplier’s launch price with another supplier’s launch and ongoing service combined.

Inspect milestones, payment terms, and change control

Connect each milestone to a meaningful deliverable or decision. Ask what you will review before the next stage begins and what happens when an approval or required input is delayed.

Read payment terms alongside that sequence. Identify what triggers an invoice, what happens if scope changes, and how disputed or incomplete work will be handled under the agreement. Seek appropriate professional advice for terms you do not understand.

For new requests, ask how the supplier will explain the effect on scope, price, and schedule before doing the work. A clear change process protects your ability to choose between adding a feature now, replacing another item, or postponing it.

Do not treat every difference as something to negotiate away. A supplier may have a reason for staging discovery before a firm build estimate. Ask what that first stage produces and whether its output will help you make an informed next decision.

Turn an unclear line into a decision

Consider a hypothetical line reading “product setup included.” Before comparing its price, ask how many products, which product types, who supplies the information, whether images are prepared, and whether options or variations require separate work. Those answers define the deliverable more effectively than replacing setup with another broad word.

Do the same with “training included.” Ask who attends, which staff tasks will be covered, whether instructions remain available, and what follow-up support is offered. A short orientation and a documented operational handover can both be legitimate services, but they are not the same promise.

For “launch included,” ask whether the line covers deployment only or also customer-journey checks, address changes, monitoring, and a defined post-launch review. Keep each answer attached to the proposal rather than assuming that your preferred interpretation applies automatically.

Make exclusions useful rather than alarming

An exclusion is not necessarily a flaw. It tells you which work remains outside the price and lets you arrange that work deliberately. The important question is whether the excluded item is necessary for the result you expect and whether someone has accepted responsibility for it.

Mark an item as included, excluded, conditional, or unanswered. Use those labels consistently across the comparison. If an essential task is excluded by every supplier, your budget and plan still need to account for it. It does not disappear because it falls between contracts.

Finally, check that the clarified scope still matches the business brief. It is possible to answer every line-item question and still buy the wrong project. Read the proposed deliverables as a complete customer journey, from the first visit through the staff response, and identify any missing handoff before approving the work. Ask staff to document that review.

Ask for clarification in a form you can compare

Send each supplier the questions specific to its proposal. Quote the unclear line and ask for a concrete answer. Avoid asking everyone to match a total before you understand which deliverables would disappear to reach it.

Add the answers to your comparison sheet and request a revised proposal when an important assumption changes. Keep the final scope together rather than relying on a promise scattered through several conversations.

If you are considering Motta Industries, review how we approach client work and apply the same comparison. We should be able to explain the responsibilities and deliverables relevant to your project without asking you to judge technical vocabulary.

The best next step may be a bounded assessment rather than a full build commitment. Contact us with the business brief and the questions you need resolved. Choose on a clear account of the work, its limits, and its ongoing responsibilities, not the smallest headline number alone.