Skip to content
Yuvraj RauljiLet's talk

Ongoing ownership

Most website problems are not technical failures. They are ownership failures: nobody decides when to update, nobody watches the thing that fails quietly, and the person who knows how to deploy is on holiday. Management is the arrangement that makes those decisions somebody's job before they become an incident.

How I approach it

What it means

  • Website management is continuous technical ownership of a site or an estate of sites: keeping versions current, applying security releases on a cadence rather than on alarm, monitoring the parts that fail without announcing themselves, holding a deployment path more than one person can run, and making the small architectural decisions that otherwise wait until they are expensive.

  • It is not a ticket queue, and the difference matters commercially. A support arrangement answers what has already broken. Management is the work that reduces how often that happens, which is why a good engagement should make its own ticket volume fall rather than justify itself by how many tickets it closes.

  • The goal is to hand it back. Documentation, runbooks and enough transfer that an internal team can hold it. An arrangement that quietly makes itself indispensable has become a commercial arrangement rather than a technical one.

Problems solved

The symptom as the person with the problem describes it, then what is usually underneath it.

  • Only one person can deploy

    Releases wait on an individual and their holiday is a business risk. It also means the deployment path is undocumented, so the first time anyone else runs it will be during an incident.

  • Updates are deferred because the last one broke something

    The gap grows, each update gets larger, and the security exposure compounds. Eventually the update is a project, which is exactly what deferring was meant to avoid.

  • Problems are reported by customers first

    A failed cron, a stalled queue, a form that stopped delivering. Uptime monitoring says the homepage answered, which was never the risk. By the time support hears about it the recovery includes an apology.

  • Nobody owns the estate, only the pieces

    A marketing site on one stack, a store on another, a landing page somebody built for a campaign. Each has an owner and the whole has none, so anything that spans them is nobody's job.

When it applies

Signals it is time

  • More than one site or stack, and no single technical owner
  • A deployment that depends on one person being available
  • Security releases applied late, in batches, or not at all
  • Backups that exist and have never been restored
  • Recurring incidents that each get fixed and never get prevented

And when it is the wrong call

This is the wrong engagement when everything runs on one platform and the work is genuinely that platform's upkeep. A single Magento store needs a patch cadence and a rehearsal environment, not an estate-level arrangement, and the platform maintenance pages describe that better and cost less. It is also wrong where there is an internal team that already has the discipline and simply needs capacity, which is a hiring question rather than a consulting one.

Every technology page on this site carries one of these. A consultant who recommends everything for everyone is a vendor with a wider catalogue.

Approach

  1. Establish what exists

    Every site, stack, host, domain and certificate, who holds each one, and where the knowledge lives. On an inherited estate this alone is usually the first accurate picture anyone has had.

  2. Make releases repeatable

    A deployment path more than one person can run, with the same steps in staging and production. Removing the single point of failure is normally the highest-value week of the whole arrangement.

  3. Set a cadence

    Security releases promptly, everything else on a schedule agreed in advance rather than when something forces it. Cadence is what keeps each update small enough that nobody is tempted to defer it.

  4. Monitor what actually fails

    Queues, crons, integration boundaries, form delivery, certificate expiry and error rates, alerting a person rather than a log file. Then backups, restored on a schedule to prove they work.

  5. Hand it back

    Runbooks, documentation and transfer. The measure of the engagement is whether the internal team could hold it without you, not whether they still need you.

Stack

Deployment pipelinesStaging paritySecurity patchingUptime and error monitoringBackup and restore testingDNS and certificatesAWS provisioningNginx and PHP-FPMCloudflare

Related work

The builds where this practice area shows up, with the decision inside each one.

All selected work across Magento, Shopify and headless commerce

Related writing

All writing on commerce architecture, performance and AI

Related expertise

These overlap on purpose. A platform decision is an architecture question first, and an AI project is usually a process question first.

Questions

What is the difference between website management and support?
Support is reactive and answers what has already broken. Management is the work that reduces how often that happens: patching, release discipline, monitoring and the ownership decisions nobody is currently making. Buying only support is why some estates have a monthly invoice and a monthly incident.
We only have one website. Do we need this?
Probably not. One site on one platform is better served by that platform's own maintenance arrangement, which is narrower and cheaper. This page is for an estate where more than one thing runs, or where the technical decisions span the sites and nobody currently owns them.
Is managed hosting the same thing?
No. Managed hosting covers the server, and often core updates and backups, which is a genuine foundation. It does not own your plugin or extension list, test an update against your checkout, notice that a form stopped delivering, or decide when to upgrade. Those are the failures that actually cost money.
Do you replace our developers?
No, and an arrangement that tried to would be the wrong one. Where there is an internal team, what is usually missing is the routine rather than the capability: a cadence, a staging step, a restore test and an owner for the list. That can be set up and handed over.
How do we know it is working?
Incident count and severity fall, updates stop being events, and a release does not depend on one person being reachable. If the engagement is measured by tickets closed rather than by incidents that did not happen, it is being measured backwards.