A decision instrument for the question that surfaces every time a capability is being built: does this belong in the shared platform, or as a local build? Two orthogonal axes answer it — and either axis alone is enough to decide.
Decision Discipline · Platform Governance · Structural Coherence
Open the toolMost platform decisions are made by counting teams. That produces the wrong answer half the time. A capability used by one team may still require platform treatment — because inconsistent implementations, even across two systems, will produce structural conflicts that compound over time.
Platform vs Point Solution is the discipline for asking the two questions independently. Usage frequency: how many teams need it, and on what timeline. Consistency requirement: would divergent implementations produce structural conflicts, even between just two teams. Either axis alone can establish the platform case. Skipping the consistency question is how shared infrastructure becomes technical debt.
Consistency is the test that catches capabilities that look local but are actually shared.
Run this tool every time a capability is up for decision. Build a portfolio of evaluations — one per capability — and the audit trail becomes a record of how platform discipline is actually being applied.
Each question targets a different dimension of the decision. Together they produce one of four recommendations — and four corresponding governance shapes.
I
Measures usage frequency — demand volume across the organization. A necessary but not sufficient condition for the platform case. A capability needed by many teams is a candidate for the platform. Whether it belongs there depends on Question II.
Usage frequency
II
Separate from usage frequency. The test that catches capabilities that look local but are actually shared. Inconsistent implementations — even between two systems — produce structural conflicts that compound. Consistency is the stronger signal.
Consistency requirement
The matrix produces a decision — and the decision shapes what gets captured into the governance record. Platform decisions get a delivery plan + migration path. Local decisions get watch signals + flip conditions.
HIGH frequency · CONSISTENCY required
Multiple teams need it, and divergent implementations would produce structural conflicts. Building this locally — in any team — is building technical debt from the first commit.
HIGH frequency · NO consistency requirement
Multiple teams need it, but each implementation can behave differently without structural problems. Local builds are acceptable here — monitor for duplication overhead as team count grows.
LOW frequency · CONSISTENCY required
Only one team needs this today — but a second implementation will produce structural conflicts that compound. The platform case is established by the nature of the capability, not by current adoption. Build before the second team arrives.
LOW frequency · NO consistency requirement
Low usage frequency and no consistency requirement. This capability can be built locally without structural risk. Revisit if usage frequency increases or a consistency requirement emerges.
Each evaluation produces a governance record matched to its recommendation — owner, review date, migration path or flip conditions, platform gap or watch signals. Save the evaluation; update it when the situation changes. Each update lands as a new version on the audit trail.
Across the portfolio, the trail shows where platform treatment was applied with discipline, where local builds were chosen for principled reasons, and where divergence risks remain open. The portfolio is the operating record of platform decision-making — more honest than any architecture diagram, and more actionable than any roadmap.
The tool is most useful when run before a build decision is irreversible — and re-run as the situation evolves. These are the right triggers:
01
New capability surfacing
A team is about to build something that another team might also need — or that touches data or behavior shared with another system. Run the evaluation before the build starts. Decisions made before code is written are cheaper than decisions made after.
02
Divergence appearing
Two teams have built similar implementations independently — or are about to. The cost of letting divergence continue is almost always higher than the cost of consolidation. Run the evaluation; the recommendation surfaces the structural argument.
03
Platform request rejected
A team is bypassing the platform to build locally. Before that becomes a precedent, run the evaluation. If the recommendation is local, document the conditions. If the recommendation is platform, the rejection is a platform-roadmap question, not a team-discipline question.
04
Quarterly platform review
Walk the existing evaluations. Any divergence risks still open? Any local decisions where the conditions for flipping to platform have now been met? The portfolio is the input to the platform's quarterly governance.
They are made by asking the two questions independently — and recording the answer. Each evaluation becomes part of the portfolio. The portfolio becomes the audit trail.
Open the tool