When building a platform, deciding when to expose functionality in the platform is a hard decision.

Expose too little, and your platform won't get used and might get left behind.

Expose too much, and you'll have significantly constrained your future agility.

Every time you want to change the API, you'll have to get all of the current users of it to update their usage–and they'd all rather not, they have other things to do.

If the update is very challenging, developers will intuitively sense that others also won't do it and maybe the update will be canceled.

In the limit with a lot of these, it can make updating your platform like trying to sprint through molasses.

An absurdly challenging coordination problem.

A general rule of thumb: if a thing is expected to change, don't expose it to users whose decisions you don't control.

If the thing isn't changing, then you won't have to do the extremely challenging updates.

If the people who adopt it are part of your organization, you can technically get the CEO to force them to do it.

But if they're members of the ecosystem outside your company, you have significantly less leverage.

How do you know which parts won't change very often?

The safest parts are existing internal APIs that have stayed constant over multiple years, despite new use cases being added in the overall system and underlying changes.

The hardest ones are new APIs that you've never gotten experience with at all.