When Priya and Daniel started their web studio, every project began the same way: a blank install, a favourite theme hacked until it screamed, plugins picked from memory, and a deployment that lived in one freelancer’s head. For two years it worked. Then they took on nine clients in a quarter, and the studio discovered — the expensive way — that they had been selling the same setup work again and again, at full price, every single time. What saved them is a discipline the software world calls PlatformOps.

Their recovery did not involve new clients or higher rates. It involved an idea borrowed from a corner of the software industry most agencies have never looked at — PlatformOps, the practice of treating internal tooling as a product with users, a roadmap and a service commitment — and this explainer walks through what it means in web-team language.

The problem has a name: doing the same build twice

Ask any agency owner where the margin leaks and the answer is rarely design or client management. It is the setup tax. Contact forms wired by hand. Analytics installed from a sticky note. Staging sites assembled from guesswork. Security hardening applied inconsistently because the checklist lives in somebody’s inbox. Each project pays that tax again, and nobody ever sees it on an invoice.

Larger software shops noticed the identical pattern in their own teams — engineers rebuilding pipelines and environments that already existed two floors away. Their solution was to stop treating setup work as a chore each team repeated, and start treating it as a product that one team builds well and everybody else uses. That product is an internal developer platform, and PlatformOps is the discipline of running it: keeping it updated, supporting the people on it, and retiring the parts that age out.

What PlatformOps actually means in a web studio

Strip the jargon and three shifts remain:

• Standardise the start, not the finish. Build one launch kit — baseline install, hardened defaults, analytics stub, backup routine, staging workflow — and start every project from it. The creative work above the fold stays bespoke; the plumbing underneath becomes identical.
• Someone owns the kit. Not “everyone”; one named person who updates it when the CMS ships a new version, answers questions when a launch misbehaves, and prunes components nobody uses. Ownership is what turns a folder of scripts into a product.
• Adoption stays voluntary. If the studio kit is genuinely faster, developers reach for it themselves. If it needs enforcing, the kit is the problem — an opinion worth having before you have built a whole business process around it.

Notice what this is not. It is not buying a portal, and it is not rebranding the ops person as a “platform team”. The software industry learned that lesson the hard way: tools without ownership changes decay, and titles without changed habits fool nobody. A studio kit can begin as one document and one starter repository — the substance is the service commitment behind them.

Templates are the product: a lesson from the big players

The most widely used developer portal in the open-source world grew out of Spotify’s internal tooling, and its most-loved feature is almost mundane: Software Templates that scaffold a new service — repository, pipeline, monitoring, the lot — in minutes. A designer in Mysore or a backend team in Stockholm clicks once and receives a compliant starting point with every organisational rule already applied.

Web studios run the same play with their own materials. A theme starter with the boilerplate sections pre-built. A form-and-analytics package wired once and reused everywhere. A pre-launch checklist embedded in the project board rather than emailed. Each of these is a small golden path: an opinionated route through work that used to require a hundred small decisions, where the defaults have already been chosen by someone who chose them carefully.

The comparison to client work is instructive. You already know that a well-planned site beats a hand-improvised one — our guide to planning a site before any code is written makes the case in detail. Your internal tooling deserves the same planning respect, because it multiplies across every project you will ever run.

PlatformOps service levels, even for a team of two

Here is the part of PlatformOps that sounds bureaucratic and turns out to be liberating. Write down, in one page, what the studio kit promises: what “supported” means, how fast kit problems get fixed, what happens when the CMS ships a breaking update, and which components are officially old. In engineering organisations these commitments are called service levels and support tiers, and they end the quiet resentments that build up when everyone assumes someone else maintains the shared stuff.

• Managed — actively maintained, problems fixed within agreed timeframes. Most of the kit should live here.
• Best effort — usable, but fixes happen when they happen. Aging plugins you have not yet replaced.
• Retired — documented, with a migration note. Nothing simply vanishes.

Three labels, honestly applied, will do more for studio sanity than another project-management app.

Where studios over-apply the idea

A fair warning, because enthusiasm causes its own failures. The first over-reach is building the kit nobody asked for — eighteen components, a custom admin panel, a dashboard tracking launches nobody consults. If a capability has not been requested by the people doing launches, it is decoration. The second over-reach is standardising the creative layer itself: the moment every client site emerges from the same starter looking like the same site, the kit has eaten the thing clients were paying for. Keep the standardisation below the waterline — plumbing, security, backups, deployment — and keep the visible design bespoke. The third over-reach is treating the kit as finished. A starter built for one CMS version will be quietly wrong within a year, which is precisely why the named owner from the previous section exists. Products that stop shipping do not merely pause; they rot.

What this has to do with client results

More than it first appears. When the foundation work is standardised, the hours freed up migrate to where clients actually feel them: information architecture, page structure, conversion paths. A studio that no longer hand-builds its twelfth contact form can spend that afternoon on the questions that win renewals — like which pages a business site truly needs, covered in our structural guide to essential pages for business websites, or how service pages turn enquiries into signed work, as in turning clicks into clients.

There is a trust dividend too. Hardened defaults applied everywhere mean fewer emergency calls about compromised sites, and consistent backups mean a hack is an afternoon rather than a month. Clients rarely ask about your internals, but they absolutely experience them.

The hiring effect is quieter but just as real. Studios with a maintained kit onboard freelancers in days, because the way work gets deployed is documented in the tooling rather than in one senior person’s habits. That resilience shows up the first time a key colleague takes a holiday during a launch week — and does not get a single phone call.

A gentle way to start this quarter

No reorganisation required. The sequence that worked for the studio in our opening story:

1. Audit the last six launches and list every task you performed identically more than once. That list is your product backlog, hiding in plain sight.
2. Build version one of the kit — one starter, one checklist, one backup routine. Resist building anything nobody has asked for twice.
3. Name an owner and write the one-page promise describing what is maintained and what is not.
4. Run the next project through the kit and time the setup. Compare it with the previous launch. Show the studio the difference; adoption will handle itself.

For teams that want to see how the discipline scales beyond a studio — reference architectures, lifecycle stages, adoption patterns and the vocabulary of internal platforms — most practitioners will point you first to the Ops Atlas entry covering PlatformOps.

Priya and Daniel still do bespoke work; that is what clients pay them for. The difference is that the bespoke work now starts at a higher floor, because the boring forty percent got productised once instead of being rebuilt, badly and differently, forty times a year. That is the whole trick of PlatformOps: stop selling the same setup work at full price to yourself.