The Second Team vs Custom Builds

Part 9 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. The platform has survived a CFO audit, a 2am P1, and its first contractor on-call rotation. The 2am post-incident review validated everything — and its last open item was a reach matrix, because the second product line was coming. Hugh Documents’ customer 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. The team that proved the platform with Netty Latency is about to learn its hardest product lesson: 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, latency-budgeted, cloud-native scoring service. 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.

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. “We need the diagnostics policy initiative to exclude our document-processing storage accounts — the log volume would contain document metadata we can’t have in the shared workspace.”
2. “We need a different RBAC model — our verification engineers must not be able to read raw documents, so owner on the resource group doesn’t work for us at all.”
3. “We need 7-year retention on audit logs and our compliance says the shared workspace’s retention doesn’t apply.”
4. “Can we get a dedicated firewall rule set? Our traffic profile is nothing like the fraud team’s.”
5. “The vending form’s data classification examples don’t 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’ll build that for you,” a step toward the platform becoming two bespoke environments wearing one management group.

Fakey McFakerson recognised the moment, because she’d been dreading it since Part 1:

“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 — 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 isn’t in its categories. It’s in the discipline of choosing deliberately and writing it down. Here’s 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 wasn’t 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, classification-gated workspace inside their own subscription, with the platform holding no access. Serge Secure co-designed it, signed the evidence-coverage map against CPS 234, 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 7’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 — recall Part 1 — the stakeholder whose requirement carried the most organisational weight. 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’s the reasoning in full so you can push back if I’ve 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’s the single fastest way to make the hub the kind of thing that fails at 2am in ways only one person understands — and the Part 8 incident showed you exactly what our incident surface looks like when it’s 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’ve attached your flows from the corridor review as evidence — and if there’s a specific inspection gap, that’s a BUILD request against the shared policy, which I’ll take. What I can’t 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’s 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’ve 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.”

Request 5: The vending form’s classification examples don’t 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 isn’t 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’s 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 didn’t 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’s the difference between the golden path and 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’s 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’s 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. Choose like the FTE number is real, 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 don’t 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 didn’t feel like it.”

Fakey’s note in the design document, in the section that started in Part 3 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’re 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’s 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.
• 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’s a register of every deliberate deviation from the golden path, and it’s where classification-model gaps belong too.

Next in the Series

Part 10 — “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 isn’t what it’s like to build — it’s what it’s like to leave. Plus: the annual plan lands, and Barry Bigboss keeps a promise.

How many silent custom builds is your platform carrying right now — and would you recognise one if it asked for something new this week? Comments open at fakey.xyz.