The Second Team vs Custom Builds

Part 10 of “The Landing Zone That Survived”, a year in the life of a New Zealand platform team, told from fakey.xyz. Fictional organisation, aggressively fake people, realistic problems.

Recap. Increment four’s first ENFORCE wave is live: twelve of thirty-one controls, zero surprise blocks, the increment-one audit mode baseline doing the job Serge signed for under protest. The 2am PIR validated the operating model. The estate still runs on 1.6 FTE of platform capacity (Robbie at 1.0, Fakey at 0.4, the security engineer at 0.2; Tessa’s 0.1 sits with finance), plus contractor Max Overhead, whose conversion waits on Barry’s annual plan. Hugh Documents’ onboarding workload, passports, driver licences, the strictest data classification fakey.xyz possesses, residency pinned to Azure NZ North since Discovery Week, is now moving to production, against an estate that is already enforcing. The second customer is where platforms either become platforms, or become a bespoke agency with a roadmap.

There is a law of platform engineering that everyone discovers and nobody enjoys:

The first customer of your platform is a design partner. The second customer is a test of whether you built a platform or a product for the first customer.

Netty Latency’s team had shaped the golden path, the vending form, the RBAC defaults, the one pager, the joint cutover checklist. Every one of those artefacts was co-authored with a team building a low latency, cloud native scoring service with a latency budget. Every default carried Netty’s fingerprints.

Hugh Documents’ team was building something almost perfectly opposite: a document-verification pipeline with hardened PII handling, batch processing, long retention audit requirements, integrations into legacy scanning hardware, and a regulatory posture that treats every document as though an auditor is already reading it. Netty’s fingerprints were on every default. Hugh’s workload matched none of them.

The ENFORCE wave met him on day one. Twelve controls, already live, already watching a top-classification production landing. Zero surprise blocks: increment one’s audit mode counts had already shown these twelve as clean, which is why Serge had agreed to stage them. He was in the channel anyway, because a signed commitment to a man who keeps the exception register does not get to be a footnote on the week it finally bites a real workload.

Within a week of production onboarding starting, the platform channel had received the following requests, reproduced verbatim from the channel history because Fakey later screenshotted them as teaching material:

1. Netty’s shared workspace default. “We need the diagnostics policy initiative to exclude our document processing storage accounts, the log volume would contain document metadata we cannot have in the shared workspace.”
2. Netty’s owner on the resource group default. “We need a different RBAC model, our verification engineers must not be able to read raw documents, so owner on the resource group does not work for us at all.”
3. The shared workspace’s ninety-day retention. “We need 7-year retention on audit logs and our compliance says the shared workspace’s retention does not apply.”
4. The hub policy shaped by the fraud corridor. “Can we get a dedicated firewall rule set? Our traffic profile is nothing like the fraud team’s.”
5. Discovery Week’s own customer PII examples. “The vending form’s data classification examples do not cover our case, we process other people’s identity documents, not our own customer records.”

Five requests. Every one of them reasonable. Every one of them, if answered with “sure, we will build that for you,” a step toward the platform becoming two bespoke environments wearing one management group.

Fakey McFakerson recognised the moment, because she had been dreading it since Discovery Week, when Hugh’s workload first sat on the register as the one that would not fit Netty’s shape:

“This is the week the platform stops being an engineering project and starts being a product. Products say no. Products have a roadmap. Products route demand instead of absorbing it. Nobody teaches you this because everyone who builds platforms came from engineering, and engineering’s whole culture is ‘someone asked, so we built it.‘”

The Framework: Build, Route, Decline

The platform team, now Fakey, Robbie Deployment, and Max Overhead, with Tessa Spreadsheet and Serge Secure adjacent, and Locksley Keymaster on the classification-model gap because that gap is his stream, spent one afternoon turning the five requests into a reusable framework, which is now on the wall of the platform channel’s pinned message and is the core artefact of this post:

For every request that falls outside the golden path, exactly one of three answers is available:

BUILD, if the need is general (two or more current customers, or one customer plus an obvious future one), it goes on the platform roadmap as a proper feature: designed, sized against operating capacity, shipped to everyone.

ROUTE, if the need is legitimate but specific to one customer’s architecture, the customer builds it inside their subscription, within the platform’s guardrails, and the platform documents the pattern so the next customer with the same shape can copy it.

DECLINE, if the need would fragment the platform’s operating model (per customer infrastructure the platform must operate, exceptions to evidence/logging/identity controls, bespoke anything in the shared layers), it is declined, in writing, with reasons, and with the declined-need recorded so it can be revisited when conditions change.

The one forbidden answer is the silent custom build, the bespoke favour done quietly for an important customer that becomes an undocumented operating obligation forever.

The framework’s power is not in its categories. It is in the discipline of choosing deliberately and writing it down. Here is how each of the five requests landed:

Request 1: Diagnostics exclusions for PII-bearing storage, BUILD (with a redesign)

Hugh’s concern was real and important: their document processing storage diagnostics would flow metadata into the shared central workspace, and their data classification treats even metadata as sensitive. Netty’s fingerprints were on the shared workspace-everything design, and Netty’s data was not PII-shaped.

This one was a genuine platform gap, the golden path assumed one sensitivity class. The build: a classification aware diagnostics pattern. High classification resources route a redacted summary stream to the shared workspace (enough for Serge’s detection and health monitoring) while full diagnostics go to a customer owned workspace, gated by classification inside their own subscription. The platform holds no standing access. The vending pipeline deploys the workspace with a time boxed deployment identity; that identity is gone before the first document lands. Serge Secure co-designed it, signed the evidence-coverage map against CPS 234 where MegaCorp Megalodon’s Australian regulated counterparties require it, and the pattern shipped as a vending option available to any workload declaring the top classification, which is what makes it a BUILD and not a favour: it went into the golden path, not around it.

The tell that separates BUILD from a custom favour: does the platform’s documentation gain a pattern, or does the customer gain an exception?

Request 2: RBAC that prevents verification engineers reading raw documents, BUILD

Same analysis, faster. Least-privilege-by-data-sensitivity is obviously general, no workload handling regulated data wants owner-on-resource-group semantics. The build: a second vending RBAC template, “data restricted operator,” with deny-assignments on the raw-document storage paths and elevated rights only on the processing surfaces. Designed with Hugh’s compliance officer in one session, shipped generically. Two templates now exist where one did. The platform got more platform-shaped, not less.

Request 3: Seven-year audit retention, ROUTE

Hugh’s retention requirement is real, regulatory, and specific to their evidence regime. Netty needs ninety days hot. Forcing seven-year retention into the shared workspace would inflate everyone’s evidence costs (see Part 8’s “cost of evidence” lesson) to serve one customer’s regulator.

The route: Hugh’s team provisions their own long-term audit archive inside their subscription, storage-account immutable archive, customer-managed, at their cost, under their control, with the platform’s contribution being the documented, policy-wired export path from the shared workspace to their archive. The pattern is written up in the platform docs as “Long-retention audit archive”, copyable by the next compliance-heavy workload, operated by Hugh, not by the platform team. The platform’s operating load grew by zero.

Request 4: A dedicated firewall rule set, DECLINE (in writing, with love, and an alternative)

This is the one that tested the framework, because Hugh Documents is the stakeholder whose requirement carried the most organisational weight at the mandate meeting. His compliance-driven ask was reasonable. The answer was still no.

The decline note, drafted by Fakey, reviewed by Robbie, and, critically, sent in writing rather than delivered as a meeting “no”:

“Hugh, declining this one, and here is the reasoning in full so you can push back if I have got it wrong. A per customer firewall policy in the shared hub means the platform team operates bespoke security surfaces per product line, forever. With our operating capacity, that is the single fastest way to make the hub the kind of thing that fails at 2am in ways only one person understands, and the November incident showed you exactly what our incident surface looks like when it is clean. What I can offer instead, which I think gets you what you actually need: your traffic profile is already fully inspected under the standard policy, I have attached your flows from the corridor review as evidence, and if there is a specific inspection gap, that is a BUILD request against the shared policy, which I will take. What I cannot do is fork the shared control plane per customer. If that ever changes, it changes in the design document with a trigger, not as a favour.”

Read the structure of that decline, because it is the stealable part: the reasoning is full and challengeable, the underlying need is taken seriously (evidence offered), a BUILD-path alternative is named, the operating-capacity cost is made visible rather than hidden, and the door is labelled (“if this changes, it changes in the design document”).

Hugh’s reply:

“Declined with reasoning is a different product to declined with silence. I have had both. I can work with this. And having read the attached, the inspection coverage is fine, the gap was my assumption, not your policy.”

He later told Tessa, who told everyone, because Tessa, that the decline note was “the first time IT said no to me in a way that increased my trust in them.”

The register has not yet had to survive a hostile appeal. The door is labelled. Nobody has walked back through it angry. That test is still outstanding.

Request 5: The vending form’s classification examples do not cover their case, ROUTE (to the register), then BUILD (small)

The request exposed a genuine ambiguity: Discovery Week’s worked examples covered own customer PII (fraud, payments) but not third party identity documents. The route: it went into the exception register as a classification-model gap, the first entry in the register that is not a network exception, which quietly stretched the register into what it should have been all along: a register of every deliberate deviation from the golden path, of any kind. The small build: the form’s examples gained a third worked case (processor of others’ data), and the classification definitions gained a sentence distinguishing controller and processor roles, borrowed, with gratitude, from Hugh’s compliance officer, who had written one before.

The Deeper Lesson: The Second Customer Rewrote the Golden Path, Correctly

Step back from the five decisions and look at what actually happened, because it is the part that makes the framework more than bureaucracy:

Four of the five requests exposed real gaps in the golden path, gaps that only a second customer with a different shape could expose. The platform did not just absorb the requests; it learned from them, and every learning made the platform more general: a second RBAC template, a classification aware diagnostics pattern, a long retention archive pattern, a richer classification model.

That is the difference between the golden path and a golden cage.

A golden path that cannot grow is a golden cage.

The path must be allowed to grow from customer pressure, through the BUILD route, or the platform ossifies into “the fraud team’s infrastructure that everyone else tolerates.”

But the growth is only healthy when it is deliberate and general. The test for any request, restated one final time:

“Does answering this make the platform more general, or more specific?” More general: build. Specific-but-legitimate: route. Specific-and-fragmenting: decline. Silent custom builds: never.

And there is a capacity corollary that Tessa insisted be added after watching the week unfold, because she had, of course, costed it:

“Every BUILD is an operating obligation at 1.0x forever. Every ROUTE is a customer obligation at their cost. Every DECLINE is zero for the platform. The cost does not vanish, it moves. Choose like the 1.6 FTE of platform capacity is real (Robbie at 1.0, Fakey at 0.4, the security engineer at 0.2), because it is.”

The Institutional Memory: The Platform Backlog Gets a Public Face

The framework produced one more artefact that turned out to matter more than expected: the platform roadmap, published. Not an internal ticket queue, a visible, ordered list of what the platform will build next and why, with the declined and revisited items marked.

The effect on the workload teams was immediate and slightly startling. Netty read it and commented that seeing the diagnostics-classification work explained why her ingestion costs had tiered. Vera Transaction’s team saw their long-requested item sitting at position three with a reason and stopped asking weekly. And Hugh’s team, the decline recipients, could see that the BUILD items they cared about were genuinely queued, which converted the decline from a rejection into a sequencing conversation.

A published roadmap is a decline with a future attached. Teams do not need everything built. They need to see that the decisions are systematic, visible, and revisable, that “no” means “not now, for a stated reason” and not “never, because we did not feel like it.”

Fakey’s note in the design document, in the section that started in Part 4 as decisions and now reads more like a constitution:

“The platform’s product is not the infrastructure. The platform’s product is the set of decisions about infrastructure, and a product whose decisions are invisible is indistinguishable from arbitrariness.”

The Increment Review Metrics

Serge Secure’s line for the evidence pack, which deserves the last word before the checklist:

“The strictest workload in the organisation is now on the platform, its controls are mapped, its patterns are general, and the one thing it asked for that we refused has a written reason in an auditable register. That sentence, in order, is the security case for the platform.”

The Steal This Checklist

• Expect the second customer to break the golden path, and be grateful, their different shape exposes your one customer assumptions while they are still cheap to fix.
• The three answers: BUILD, ROUTE, DECLINE, and the forbidden fourth: the silent custom build. Favours become undocumented obligations become 2am archaeology.
• BUILD if the need is general (two customers, or one plus an obvious future one), and ship it to everyone, into the golden path, not around it.
• ROUTE if it is legitimate but specific, customer-built inside their subscription, within guardrails, pattern documented for the next one. Platform operating load grows by zero.
• DECLINE in writing, with love, full reasoning, the underlying need taken seriously with evidence, a BUILD-path alternative named, the operating cost made visible, and the door labelled in the design document.
• The test for every request: does answering it make the platform more general, or more specific?
• Cost your answers like FTE is real (it is): builds are 1.0x forever, routes are the customer’s cost, declines are zero for the platform, the cost does not vanish, it moves.
• Publish the roadmap, visible, reasoned, sequenced, with declined and revisited items marked. A decline with a future attached is a sequencing conversation; a decline without one is a rejection.
• Stretch your exception register beyond network exceptions, it is a register of every deliberate deviation from the golden path, and it is where classification-model gaps belong too.

Next in the Series

Part 11, “The Petone Exit, or: Decommissioning Is a Feature.” The colo exit deadline arrives, and the platform faces the work nobody puts in roadmaps: turning off the old world without breaking the new one. Migration waves in reverse, the reach matrix earns its keep, the Decommissioned management group becomes the busiest place in the tenant, and fakey.xyz learns that the truest test of a landing zone is not what it is like to build, it is what it is like to leave. The last cutover does not reopen. At least one thing is still running on the old world that nobody remembered. Plus: the annual plan lands, Barry Bigboss keeps a promise, and Max’s contractor clock comes due.

How many silent custom builds is your platform carrying right now, and would you recognise one if it asked for something new this week?