🔌 Every feature you ship should also be an endpoint
The rule is simple: if your product can do something, code should be able to do it too. Chat, reports, settings, whatever. One feature, two surfaces.
This has always been good practice, but agents just changed the math on it completely.
Your product's users used to be humans clicking through your UI. Increasingly, they're Claude Code, Codex, and custom agents acting on a human's behalf, and those users can't click anything (at least not well). Every feature without an endpoint is invisible to them, which means it might as well not exist for a growing share of your usage.
And the upside compounds beyond agents:
Your customers stop asking for integrations because they build their own
Features get composed into workflows you'd never have prioritized (someone triggering an analysis from a support ticket was never on our roadmap, and it's one of my favorite use cases now)
An API contract forces cleaner boundaries in your own architecture, so your product code gets better as a side effect
Every endpoint is a surface an MCP server can expose, so agent support becomes nearly free
We just went through this ourselves at @Basedash: AI data analyst. We spent the last few months exposing everything Basedash does through an API (AI analyst chat, dashboards, automations, all of it), and it shipped on Product Hunt today (check it out!). The thing that surprised me is how much demand came from both directions at once: product teams wanting our analyst inside their products, and data teams wanting to drive it from their own systems. Same answer for both.
The pattern I'd bet on: every product slowly becomes a platform, because the agents doing more and more of the work need programmatic surfaces, and the products that have them will just quietly win that traffic.
Replies
What happens to products where the UI is intentionally opinionated? Could exposing everything through APIs accidentally make the product harder to use?
What happens to products where the UI is intentionally opinionated? Could exposing everything through APIs accidentally make the product harder to use?
I am wondering about the opposite side of this: are there any features you deliberately chose not to expose through the API, and why?
agree with the principle but the part nobody talks about is upkeep - the API surface and the UI surface drift apart the moment one team ships a UI-only edge case fix under deadline pressure and forgets the endpoint. did you have to build actual process/tooling to keep the two in lockstep, or has it just been discipline so far now that the team is small?
How do you decide whether a feature should be exposed as one powerful endpoint or several smaller composable endpoints?
I wonder if “API-first” will eventually become as important as “mobile-first” was a decade ago. Are we already at that point?
The composability point is underrated. We build citation verification (DocuTruth), and the users who surprised us most are lawyers wiring their own agent pipelines — one runs research through Perplexity, pulls cases from Lexis, drafts with Claude, and wants verification as a step in his workflow, not as our UI. For him, "verify these citations" is a function call that happens to have a product attached.
The MCP framing is where this lands for us: a verification endpoint inside a drafting agent means the check happens before the mistake exists, instead of auditing after. Congrats on the launch — the both-directions demand matches what we're seeing.