The brief arrived on a Tuesday and contained one sentence: “New developers take five weeks to ship anything, and we don’t know why.” The client was a 60-engineer logistics software firm — I’ll call them Meridian Freight Systems — and the engagement that followed became my first real PlatformOps assignment: standing up and operating an internal platform as a product, on a fixed clock, as a one-person external team. This is the account of those ninety days, written up precisely because the shape of the work surprised me, and because other independent consultants are being asked for exactly this kind of help now.

Before the details: the vocabulary I used to structure the engagement comes from xOps School’s PlatformOps reference, which sets out the product model, the lifecycle rules and the architecture layers in a form you can quote in a statement of work. Having the definitions in writing mattered more than I expected; in client meetings, a named concept travels further than a good argument.

The Client and the Situation

Meridian had five product squads shipping to the same Kubernetes clusters, and a four-person infrastructure team that served them through a ticket queue. The numbers from my first week told a clean story. Median time from repo creation to first production deploy for a newcomer: twenty-three working days. Distinct CI pipeline formats across the estate: eleven. Documented onboarding procedures: four, of which two contradicted each other. Every squad had assembled its own concatenation of scripts, and the infrastructure team spent most of its week answering requests the scripts were supposed to answer.

Crucially, nobody had done anything wrong. Each local decision had been reasonable. The compounding of ninety small reasonable decisions was the problem, and that is what platform thinking addresses.

The infrastructure team’s side of the ledger deserved recording too. They were not idle — their queue logs showed a median response under a day — but their effort went to bespoke one-off requests rather than to anything reusable, because nothing in their incentives rewarded generalising. A request answered with a script saved one squad; a request answered with a template saved every squad that followed. Nobody at Meridian had been given the second job. That gap, more than any technical deficiency, was what the engagement was hired to close.

Weeks One and Two: Counting Before Building

My instinct was to start with a portal. I’m glad nobody listened to it. Instead we ran two weeks of interviews — one with each squad lead, one with each infrastructure engineer — and an inventory of every shared capability in service, recorded in a table with an owner column that was mostly blank.

The interviews produced a list of duplicated effort: secrets handling, environment provisioning, log access, deploy triggers. They also produced the single most useful sentence of the engagement, from a squad lead who said she didn’t want more tooling, she wanted to stop waiting for permission to ship. That sentence became the charter’s opening line. The inventory, meanwhile, showed the estate was already half-platformed — the capabilities existed; they just had no owner, no level of service, and no front door.

The charter itself fit on one page and was signed — literally, in ink, which I recommend for the theatre of it — by the CTO and two squad leads. Its commitments were few and deliberately modest:

• One supported route for the most common kind of work, kept optional for every team.
• A named owner for each shared capability, recorded where everyone can see it.
• A published level of service per capability, reviewed quarterly in the open.
• Anything being retired gets a date and a person, never a wiki warning.
• The platform group does nothing a squad could safely do for itself.

The Middle Month: One PlatformOps Path, One Partner

Days fifteen to forty-five produced exactly one artefact: a golden path for the most common job, which at Meridian was standing up a new service. One repository template, one pipeline definition, one observability default, one secrets pattern, one deploy route. Opinionated to the point of rudeness, supported, and — this was the part I negotiated hardest for — optional.

The billing squad built against it as design partner, partly because their roadmap was heaviest and partly because their lead had the most credibility to complain loudly. Every hour she lost to friction became a ticket in my column. In three weeks of paired work the template went through nine revisions, and I would defend all nine in front of any client: the version that ships is the one a sceptical team already used, not the one a consultant admires.

Two things I deliberately did not build: a custom portal, and a second golden path. The platform-as-product reading is blunt about scope — the thinnest viable platform wins because every added surface is a permanent maintenance promise, and a ninety-day engagement that ends with two half-paths has delivered nothing a successor can operate.

The Beta: Where the J-Curve Shows Up

Days forty-six to seventy moved the path to two more squads. The research warns you to expect a dip and the research is right: week eight was the worst week of the engagement, when a migration broke two services’ release cadence and the objections I had been collecting all got aired at once, in one meeting, with the CTO present.

What carried it through was measurement already in place. The four numbers on the wall — time to first deploy, share of new services on the path, defections off it, support requests per week — told the honest story: two defections, both caused by a defect fixed within a day, and first-deploy time down from twenty-three days to four for path users. Defection numbers matter more than adoption numbers, a distinction I now put in every proposal. Adoption can be compelled; defection cannot be faked.

PlatformOps Handover: The Last Ten Days

The final stretch was paperwork, and it was the part that turned a project into a going concern. Each capability on the path received a lifecycle stage, an owner with a name on it, a published service level, and a support tier distinguishing “platform engineer paged” from “ask in the channel tomorrow”. We ran the first deprecation — Meridian’s oldest Jenkins jobs, superseded by the path — with a dated notice and a named person, me, walking the last two teams across. Warnings alone would have achieved nothing; a scheduled human achieved everything.

Then the exit test: an internal engineer ran the onboarding for a new hire using only the published materials, and shipped to production on day three. That was the acceptance criterion in the statement of work, and I recommend the practice to any independent consultant — put the handover in writing before day one.

What I Would Tell Another Freelancer

Four things transfer beyond this assignment. First, sell the operating discipline, not the toolchain; clients have bought toolchains before and it is why they called you. Second, the counting fortnight earns its cost — every difficult conversation later was settled by a number from those two weeks. Third, one path with one partner beats five initiatives; scope discipline is the service you are actually selling. Fourth, the credential question that opens the FAQ for new DevOps freelancers — whether you need special standing to advise on platform work — has a practical answer: you need one client story told precisely, which is what this engagement became.

It also helped that I wasn’t alone in the genre of work. A reliable support network and a couple of mentors reviewed my charter draft and my exit plan; both improved. And the engagement sat naturally alongside the kind of combined cloud and DevOps consulting many independents already offer — the platform work is the same skills, arranged around a product model and a longer time horizon.

On commercial structure, one choice earned its keep: fixed-scope phases with a re-quote between them, rather than a single fixed price for ninety days. The counting fortnight was phase one, priced small, and its findings reset the client’s expectations before the expensive phase began. When the beta’s dip arrived in week eight, the phase boundary gave us a natural moment to re-commit — or to stop — without renegotiating from scratch. Independent consultants underprice discovery more often than they overprice delivery, and platform engagements punish that harder than most, because the discovery findings change what the build should even be.

Meridian renewed for a second, smaller engagement the following quarter: reviewing their catalog data against actual usage. That, too, is characteristic. The first engagement installs the discipline; the maintenance of it is where the ongoing relationship lives.