Custom website development services
in Long Beach

The same document goes to three suppliers and comes back with three figures that are not close. That is rarely a sign that somebody is overcharging. It usually means the brief left room, and each of them filled it differently.

Ask what is inside the number before comparing numbers. Content migration is the usual gap. One quote assumes you move your own pages. Another includes moving them. On a site with a few hundred pages that single assumption is a large share of the difference.

Design is the second gap. A figure based on applying a template is not comparable to one based on designing screens from scratch, and neither party is lying when they call their version a design phase.

Then the invisible items. Browser and device coverage. Accessibility work. Performance targets. Data protection requirements. Training. A warranty period after launch. Each of those is real work, and each is easy to leave out of a proposal that wants to look competitive.

How the figure is constructed matters as much as its size. A fixed price includes a contingency for the unknowns, because the supplier carries that risk. Time and materials does not, so it looks cheaper and can end higher. A capped arrangement sits between the two. None of the three is the honest one by nature.

Beware the quote that is confident about a part nobody could know yet. If the brief does not say what the legacy system returns, a precise integration figure is a guess wearing a decimal point.

Change control is where the real difference shows up later. Ask what happens when something is added mid-project, how it is priced, and who has to approve it. A supplier with no answer has one answer in practice, and it arrives as an invoice.

The discovery phase exists to close this gap and is worth paying for separately. A short, paid piece of work that produces a specification lets every later quote be compared honestly, and it belongs to you rather than to the supplier who wrote it.

We would rather give a range with the drivers named than a single figure that is wrong in a direction nobody can see.

Every site eventually changes hands. The agency ends, the developer leaves, the marketing manager moves on. What the next team receives determines whether the site keeps improving or slowly freezes.

The common failure is handing over access and calling it a handover. Credentials are the smallest part. What the next person needs is the reasoning: why the content is modelled the way it is, which plugin does what, where the deployment runs, what breaks if a particular setting changes.

A short written document beats a long recorded call. Where the code lives. How a change reaches production. Which third-party services are involved and who holds those accounts. What is scheduled to run, when, and what it touches. Known compromises and the reason each one was accepted.

Accounts deserve particular attention. Services registered to a personal address become inaccessible the moment that person leaves, and the discovery usually happens during an outage. Every external account should sit under an address the organisation controls.

There should also be an honest list of what is fragile. Every site has parts that work and should be approached carefully. Naming them is more useful than pretending the build is uniformly robust, and the next team will find out anyway, at a worse moment.

A useful test of the handover is to have somebody unfamiliar follow it. Ask them to make a small change and deploy it, using only the document. Whatever they get stuck on is what the document is missing.

Doing this well is also in the outgoing team’s interest. The calls that arrive months later, asking where something is, are the direct cost of a thin handover.

A single organisation often runs more than one public brand. A parent and an acquired company. A commercial arm and a foundation. Two product lines with different audiences. Building these together saves real money and creates a specific set of problems.

What can be shared is usually infrastructure and mechanism. Hosting, deployment, the content model, forms, search, analytics plumbing, the component library underneath the styling. Sharing these means one upgrade instead of several, and one place where a security fix lands.

What must stay apart is anything a visitor perceives. Visual identity and tone, obviously. Also navigation, because a menu that lists the other brand tells a visitor they are somewhere other than where they thought they were. Contact routes, because enquiries going to the wrong team is the failure people notice.

Addresses are the decision that is hardest to revisit. Separate domains, subdomains, or paths under one domain each carry different consequences for search, for trust and for how the brands can be separated later. A likely sale or spin-off argues strongly for separate domains from the start.

Content leakage is the common defect. Search results returning the other brand. A sitemap listing both. A related-articles block crossing the line. Each of these is a small configuration detail, and together they undo the separation the design worked for.

Analytics and consent need the same care. Cookie consent given on one brand does not obviously extend to another, and a shared measurement setup can make two audiences look like one, which hides what each is actually doing.

Write down which layer is shared and which is separate, and keep it where developers will see it. Without that note, the boundary erodes one convenient shortcut at a time.