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.

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

Every feature without an endpoint might as well not exist is a strong statement, but honestly, I think you are right. Agents are becoming another type of user.

I really like the “one feature, two surfaces” framing. Do you think this should become a product requirement before a feature is even added to the roadmap?

 I think it makes sense nowadays, especially since AI can help spec it out and implement for every new feature. Much easier to support it incrementally than all at once.

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.

Has this changed how you prioritize roadmap requests? If customers can build their own workflows, do you now focus more on primitives than complete end-to-end features?

I wonder if the future product roadmap becomes less about what feature should we build? and more about what capability should we make composable?

This also seems like a forcing function for better architecture. If a feature cant be cleanly exposed as an endpoint, maybe the internal boundaries aren’t clean enough either.

Have you noticed a difference between what humans ask for and what agents try to do with the same API? I imagine agents expose use cases humans rarely think to request.

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?

12
Next
Last