Build vs buy: what actually goes into a production feature platform?

Why teams build internally — for good reasons

The in-house instinct is not irrational. Your feature logic encodes your business; your data landscape is peculiar; early requirements look small; and capable platform engineers reasonably believe — correctly — that they can build the first version quickly. External platforms, meanwhile, look like a dependency, a procurement process, and someone else’s assumptions. Every one of these points is real. The build-vs-buy mistake is almost never underestimating the first version. It is underestimating the fifth.

The simple first version

Version one of an internal feature platform is genuinely simple, and usually looks the same everywhere:

• SQL (or Spark) jobs compute historical features into tables;
• Redis (or similar) holds latest values for serving;
• a thin Python API reads both.

It ships in a quarter, serves the first models, and works. The trouble is that none of the hard problems have arrived yet — because the hard problems are functions of time, growth, and change.

The complexity that arrives later

Each of the following tends to appear as an urgent incident rather than a roadmap item:

• Feature dependencies — features built on features; something must define and resolve the graph identically in every path.
• Historical materialization — backfills over years of data when a feature changes, without corrupting what exists.
• Point-in-time datasets — availability-aware training data; by far the most common silent gap in home-built systems.
• Online execution — features computed from request-scoped data, with logic identical to training’s.
• Versioning — models pinned to the feature versions they were trained on; changing a feature without invalidating history.
• Idempotency and retries — jobs that can die mid-run and re-run safely, forever.
• Metadata — what exists, who owns it, which version is live, what depends on what.
• Source availability tracking — recording when data arrived, not just what it says.
• Testing — asserting feature values before deployment, not observing them after.
• Deployment and rollback — promoting feature artifacts as governed releases.
• Reproducibility — reconstructing the vector behind a past decision when validation or audit asks.

Any two of these are a project. All of them are a platform — and they interlock: versioning without metadata is bookkeeping, PIT correctness without availability tracking is impossible, online execution without shared dependency resolution is skew by design.

Ownership is the real line item

The build cost is visible and budgeted. The ownership cost is neither: the internal platform needs maintainers indefinitely, and they will be your strongest data-infrastructure engineers — the ones every other project also wants. When they rotate away, the platform becomes the code nobody wants to inherit, exactly when the models running on it have become load-bearing.

Maintenance compounds quietly

Sources change shape. Models multiply. A second team adopts the platform and needs the features documented, versioned, and stable. Each accommodation is small; the sum is a permanent engineering tax paid in your scarcest currency. None of this argues that building is wrong — it argues that the comparison should be made against the fifth year, not the first quarter.

When building internally makes sense

Honestly: more often than vendors admit.

• Your feature needs are genuinely simple — a few models, batch scoring, no request-time computation — and may stay that way.
• Your domain’s requirements are so unusual that no platform’s execution model fits without fighting it.
• Feature infrastructure is close to your core differentiation, and you intend to staff it as a product, permanently.
• You already have the platform, it works, and migration would cost more than ownership. Sunk cost is a fallacy; working software is not.

When adopting a platform makes sense

• The complexity list above is arriving and each item is being solved ad hoc, per team.
• Correctness pressure is real: regulated decisions, audit questions, or a persistent offline/online performance gap.
• Your best engineers are maintaining plumbing that is not your product.
• You need the platform’s properties — PIT correctness, versioned execution, online/offline consistency — now, not after four quarters of internal roadmap.

Open source changes the shape of the decision

The classic dilemma — own everything or depend on a vendor — assumed the platform was closed. An open-source platform is a third position: you adopt an execution model without giving up inspection, self-hosting, or an exit path. You can read the engine, run it in your infrastructure, fork it in extremis; and your feature logic stays your code. “Buy” stops meaning surrender of control, and “build” stops being the only way to keep it.

Where ClearFeature sits

ClearFeature is that third position, built specifically for the list above: dependencies, materialization, PIT datasets, request-time execution, versioning, idempotency, metadata, availability, testing, and promotion are the platform’s job — Apache-2.0, self-hosted, with feature logic living in a Feature Project your team owns. The honest evaluation costs an afternoon: run the quickstart, then compare what it gives you against your internal roadmap for the same properties.

Start with one workflow, not a migration program

Whichever way you decide, do not decide company-wide. Pick one production workflow where the pain is sharpest, run it end to end on the candidate architecture — internal or adopted — and let the result argue. Platforms are chosen well by evidence and badly by slide decks. (How we structure pilots →)