Part of the CTO Operating System · The Modern CTO Circle

Platform vs
Point Solution

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 tool

What it is

Two questions.
Both orthogonal.

Most 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.

The two questions

The framework the tool works through

Each question targets a different dimension of the decision. Together they produce one of four recommendations — and four corresponding governance shapes.

How many teams will need this, and over what time horizon?

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

Does the capability need to behave consistently across contexts?

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 four outcomes

One of four recommendations.
One governance shape each.

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

Platform — strong case

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

Local builds acceptable

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

Platform — divergence risk

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

Build locally

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.

What it produces

A governance record per evaluation.
An audit trail across the portfolio.

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.

How to use it

When to run an evaluation

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.

Platform decisions are
not made by counting teams.

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.