When the web project has a technical layer your team does not want to own.

You are not hiring “a Linux person” or “a Cloudflare person”. You are externalising a technical responsibility.

A technical request usually arrives with two layers: the visible symptom and the underlying constraint. “We need Docker”, “Cloudflare is broken”, “the form stopped sending”, “we need an API”, or “the old site has to move” may describe the correct solution—or only the place where the problem became visible.

Technical Partner starts by understanding what must be true when the work is complete, what exists now, what cannot be disrupted and who controls the systems involved.

One partner can cover several connected layers without pretending to be every kind of IT provider.

Technical Partner is not presented as a 24/7 SOC, managed enterprise IT department or guarantee that every infrastructure problem can be resolved remotely. If a request needs a different kind of specialist or service level, that should be said early.

First establish the problem; then decide what to change.

Technical Requirements form →

Existing systems deserve an inventory before they deserve a command.

When the work touches a live website or hosting account, we first establish what is serving production and what other services depend on it. A web root can contain an old site, email-related DNS can share the same zone, redirects can feed campaigns, and a “cleanup” can remove files that were still operationally important.

Where supported and included, we make a backup before destructive changes and define a rollback path. A backup is useful evidence only when we know what it contains and where it belongs.

Technical work does not require us to roam through the rest of your computer.

Preferred access is a collaborator/restricted account with only the permissions required. When a provider makes that awkward, attended remote assistance can be cleaner: you open the relevant dashboard, log in personally and stay present while the agreed work is performed.

Keep unrelated folders, email, documents and applications closed. You can type primary passwords yourself. Unattended access is not required by default.

See the step-by-step Access Guide →

Security is a constraint on how we work, not a slogan printed on the page.

We aim to minimise credentials, avoid unnecessary data collection and keep technical access proportionate. Where work exposes confidential or personal information, the relevant confidentiality and data-processing responsibilities should be part of the applicable agreement.

No legitimate technical partner can promise that a website will never be attacked, never fail or never need another change. We can reduce unnecessary exposure, make safer changes and leave a clearer recovery path.

The technical solution should not quietly transfer ownership of your infrastructure.

Where practical, domains, hosting and paid third-party services remain contracted directly by the client or agency. We can recommend the provider/link and configure the service without collecting the billing or identity data required for that purchase.

Third-party services remain subject to their own uptime, billing, renewals and policies. Helping configure Cloudflare, a registrar, hosting provider or API does not make WebAgencyOn the provider of that external service.

Ownership & Handover →

Technical uncertainty should not be disguised as a fake fixed answer.

Some tasks are immediately definable and can be scoped directly. Others require investigation because the visible symptom does not yet reveal the work necessary to fix it.

If responsible implementation cannot be priced until we inspect or diagnose the environment, we say so before promising an outcome. A diagnosis/discovery step can be separated from implementation rather than hiding unknown work inside an arbitrary quote.

“It works on my machine” is not the deliverable.

Depending on scope, handover can include deployed code/files, configuration changes, the final production location, relevant DNS/SSL state, notes about third-party dependencies, backup/rollback information and which temporary accounts can now be removed.

For a one-off technical project, we do not assume permanent access after handover. If ongoing responsibility is needed, that becomes an explicit service rather than a forgotten admin account.

Questions that matter more than a technology logo wall.