Basedash: AI data analyst
AI-native Business Intelligence Platform
Start new thread

🔌 Every feature you ship should also be an endpoint

by
•

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 . We spent the last few months exposing everything Basedash does through an API (AI analyst chat, dashboards, automations, all of it), and it (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.

122 views

Add a comment

Replies

Best

Have you found that designing the API first actually changes the way your team designs the underlying product features?

 we still design around the UI first (for now) but every feature needs to be possible to manage through the API as well. I think that order may change as agent become more ubiquitous.

 Thats great

The most interesting part for me is the unexpected workflows. What’s the strangest or most creative customer workflow someone has built using your API so far?

I have seen companies spend months building integrations that customers eventually outgrow. Giving them composable endpoints seems like a much more scalable approach.

I love the idea that your customers can build integrations without waiting for your team. But how do you balance flexibility with preventing people from creating fragile, unsupported workflows?

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?

I like the idea of "one feature, two surfaces." Treating the UI and API as first class citizens keeps products flexible and opens up use cases that teams often don't anticipate.

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?

12
Next