Web development services, as an ongoing engagement

Web development services are bought when a website has stopped being a document and started being software.

Development versus web design, applied to buying

The distinction between design and development is set out separately on the difference between a web designer and a web developer. Applied to buying rather than to job titles, it comes to this: design decides what the thing is and how it behaves for a person. Development builds and maintains the machinery that makes that behaviour true, including the parts a visitor never sees. A design engagement can reasonably end. A development engagement usually should not, because software that nobody maintains does not stay still. It degrades, quietly, as everything it depends on moves underneath it.

Measured for Australia on 31 July 2026 and recorded in research/national-volume-au.json and research/cpc-competition-au.json, “web development services” draws 390 searches a month at a keyword difficulty of 20, with competition at an index of 14 and advertisers paying 24.95 AUD CPC. That combination is unusual and worth reading properly. Advertisers pay more per click here than on any other services term measured for this site, while the competition index is low. Few bidders paying a lot generally means a small pool of buyers with large contract values. The result page, pulled 3 August 2026 in research/serp-candidates.json, is seven agency pages and two directories.

The two agency directory results

Two of the nine results are agency listing directories rather than businesses that write code. Before reading either list order as an evaluation, find the directory’s own page for agencies wanting to appear on it and see what participation costs. Where placement can be bought, the order of a list is a schedule of who paid, not a finding about who is capable. That does not make the listings useless, since a directory is a reasonable way to assemble a shortlist. It makes the ranking uninformative.

What web development services actually cover in a retainer

A development retainer that is worth paying for covers four categories, and a supplier should be able to allocate any request to one of them in front of you.

Keeping it running

Dependency and platform updates, security patches, certificate renewal, monitoring, backup verification, and responding when something breaks. Backup verification matters more than backups: an untested backup is a belief, not a recovery.

Changing it

New features, new page types, new integrations, changes to existing behaviour.

Investigating it

Diagnosing why something is slow, why a form silently fails for one browser, why an integration stopped without an error.

Advising

The half-hour conversation before a decision, which is the cheapest item on any retainer and the one most consistently underused.

What a retainer does not cover, unless it says so, is a rebuild. If the underlying framework or platform version reaches end of life, that is a project with its own budget, and it will arrive eventually. Ask when the current stack goes out of support, at the start, and write the answer in your calendar.

Development work looks different depending on the platform underneath it

Custom development on a headless or fully bespoke build is a different discipline from development inside WordPress, Shopify or Webflow, and a retainer priced for one does not automatically translate to another. WordPress and WooCommerce development is largely plugin, theme and integration work layered on a platform someone else maintains at the core. Shopify development sits inside a hosted platform with its own release cycle, so “keeping it running” means less server maintenance and more app and theme-code upkeep. Webflow and other visual-build platforms shift more of the work into design-adjacent configuration than into code. A genuinely custom or headless build carries the most development responsibility of all, because there is no vendor patching the core underneath it. Ask which of these your build actually is before agreeing to a retainer scoped for a different one.

Environments and how development work reaches the live site

Ask how a change gets from a developer’s machine to your customers. There are only a few honest answers and one of them is a warning.

A defensible arrangement has at least two environments: somewhere work is built and reviewed, and the live site. Larger arrangements add a staging environment that mirrors production closely enough that a test there means something. Changes are reviewed before release, released deliberately rather than continuously by accident, and recorded so that “when did this change” has an answer.

The warning sign is editing the live site directly. It is faster, it is common in small engagements, and it means every mistake is a customer-facing mistake and there is no version to return to. If that is the arrangement, at minimum insist on a backup taken immediately before every change and a written note of what changed.

Also ask what a release looks like on a Friday afternoon, because the answer tells you whether releases are routine or eventful.

Who holds the custom code behind your web development builds

The repository is the site. Whoever controls it controls whether the site can be worked on by anyone else.

Your business should own an account on the hosting service for the repository, with your own administrator access, and the supplier’s access should be a permission granted to them rather than a possession. The same applies to the deployment configuration, environment variables and any private packages the build depends on. A repository you cannot see is not a backup of anything, and “we hold the code and can send it to you if needed” describes a dependency, not an arrangement.

Two further items get forgotten. Third-party service credentials, including payment gateways, mail providers and mapping or address services, should be issued from accounts in your business name. And any code written specifically for you should be assigned to you in writing, with any open-source components used identified along with their licences, so that a later buyer of your business or a later developer is not inheriting an unanswerable question. The general position is on who owns your website.

Handover and bus-factor risk in a development engagement

Bus factor is the number of people who can be unavailable before work stops. On most small business websites it is one.

That is survivable if the work is documented and recoverable, and expensive if it is not. Four artefacts reduce it, and each can be requested as a deliverable rather than a favour: a written description of how the site is deployed and where it runs, a list of every external service the site depends on and what each is used for, the location and restore procedure for backups, and the code itself in a repository you control.

Test it rather than trust it. Once a year, ask the supplier to describe how a different developer would pick this site up next Monday. Hesitation is data.

Integrations and API development work

Integration is where development engagements exceed their estimates, consistently, and for reasons that are structural rather than careless.

The website is one end of a connection. The other end is a system you did not build and cannot change: an accounting package, a booking system, a CRM, a supplier’s stock feed, a government service. That other end has its own rate limits, its own idea of valid data, its own downtime and its own release schedule. Work that assumes cooperative behaviour at the far end is work that will be revisited.

The questions that predict cost are: has the supplier connected to this specific system before, is the connection documented publicly or is it being reverse-engineered, what happens when the far end is unavailable for an hour, and who is notified when a transfer silently fails. The last question is the one that saves money, because failed integrations do not usually announce themselves. Orders simply stop arriving.

Testing and rollback for development work

Two questions separate a development engagement that can recover from one that cannot.

What is tested automatically

Not everything needs automated tests. The paths that take money or capture leads should have them, because those are the paths that break silently and cost immediately. Ask which specific journeys are covered.

What rollback actually looks like

If a release breaks the site at four o’clock, how is the previous version restored, how long does that take, and has it ever been done. A supplier who can answer with a number has done it. A supplier who describes a process in the abstract has not.

When you need development services rather than a maintenance plan

Maintenance keeps an existing thing working. Development changes what it does. The distinction sounds academic until it appears on an invoice.

Buy maintenance if the site is stable, the feature set is settled, and the only requirement is that it stays secure, backed up and current. Pricing for that is discussed on what upkeep actually costs.

Buy development services if there is a queue of changes, if the site talks to other systems, if custom code exists that only one supplier understands, or if the business is going to ask the website to do something new within the next year. In those cases a maintenance plan will be consumed by change requests billed as extras, and the total will exceed the retainer you avoided.

The questions above about repositories, rollback and bus factor are fair to put to any supplier in exactly the terms written here.