4
10 Comments

The Feature I Underestimated as a Founder turned out to be the Real Product

I thought we were building a product experience problem in Agent37. Turns out it was an integration problem. When we started building, most of my focus went into internal UX design. Agent lifecycle management, workflow orchestration, configuration layers and how everything would be controlled inside the platform.

The assumption was simple. If the system feels good internally, users will naturally adopt it. But once we started getting feedback, a different pattern showed up.

  • Users were not asking for more dashboards or UI improvements.

  • They kept asking for API access.

At first, I treated it as a secondary layer, something we would expose later once the core product was more mature. In my head, the UI was the main product surface, and the API was just an extension. But for many users, the API was the product.

They were not trying to use the platform directly. They were trying to plug it into their own systems, pipelines, and automation workflows. Without that, it did not really fit into their stack. That changed how I think about product design. Users are not evaluating features in isolation. They are evaluating integration cost, system fit, and how easily something drops into their existing architecture.

Now I spend less time polishing internal UX first and more time thinking about external interfaces, APIs and composability from day one.

What’s one feature you thought was minor but later realized it was actually the core way users wanted to use your product?

What would you prefer as a founder when building a product?
  1. I prioritize APIs first
  2. I prioritize UI first
  3. Both are equally critical
  4. I’m still figuring it out
Vote
on June 16, 2026
  1. 2

    Honestly this is how I use most tools now. If it doesn’t connect to my existing setup, I just stop using it after a while.

    1. 1

      Yes that was the pattern that kept showing up for me as well. A tool can be great on its own, but if it doesn't fit into the workflow you're already using, it becomes another thing to manage instead of something that actually saves time.

  2. 2

    I rarely log into dashboards anymore. I just want something I can automate and forget about.

    1. 1

      Dashboard is mostly setup and monitoring now. Real usage happens through API calls, scheduled jobs and automated workflows that run in the background.

  3. 2

    This is a classic 'head-fake' in product design. We obsess over the 'front door' (the UI/UX), but our power users are actually looking for the 'back door' (the API) because they don't want to add another tab to their workflow—they want to embed the logic into what they already have.

    At Mobiwolf, we've seen this transition play out time and again. It’s the difference between building a 'destination app' and building a 'utility component.'

    To your question: For us, it was webhooks. We initially treated notifications as a 'nice-to-have' feature for the UI dashboard. Then, we realized that for most of our clients, the lack of real-time event triggers was the reason they weren't using our core features. Once we treated the webhook event as the primary interaction, the product adoption curve completely shifted. It taught me that 'composability' is almost always more valuable than 'completeness.'

    How has this shift changed your roadmap? Are you now building 'headless' first and treating the UI as just one implementation of your own API?

    1. 1

      That's a great way to frame it. The webhook example sounds very similar to what we are seeing. We're not fully headless first yet, but we're definitely moving in that direction. APIs and integrations are becoming first class parts of the platform rather than something added after the UI. The big realization was that for many users, the dashboard is just one way to interact with Agent37 not necessarily the primary one.

  4. 2

    A good lesson. It seems like users often care less about where a product lives and more about how easily it fits into what they're already doing. Did API requests come mostly from developers or were non technical teams asking for integrations too?

    1. 1

      Mostly developers at first. But interestingly even non technical teams were asking for the same thing in a different way. They wouldn't ask for an API directly but they'd ask things like "Can this connect to our workflow?" or "Can we use this with our existing tools?" So the request wasn't really about APIs specifically it was about making Agent37 fit into what they were already using. That was the pattern that kept showing up.

  5. 1

    We saw users ignore dashboards completely once API coverage reached 80% of core actions. After that , everything shifted to programmatic usage , specially batch operations and automation scripts

    1. 1

      Yeah, we saw the same thing. Once API coverage hit a certain point, the dashboard became mostly onboarding. Real usage moved to batch jobs and automation. After that, users cared more about reliability and rate limits than UI.

Trending on Indie Hackers
I got my first $159 in sales after realizing I was building in silence User Avatar 52 comments I spent more time setting up cold email than actually selling. Here is what fixed it. User Avatar 41 comments Three Days Before Launch, I Let My Own Tool Tear Me Apart User Avatar 35 comments I got tired of rewriting the same content for 9 different platforms. So I built Repostify. User Avatar 29 comments A pattern I keep seeing in EdTech: traffic isn't usually the problem. User Avatar 23 comments I thought I was building a news visualization tool. Users thought it was a catch-up tool. User Avatar 21 comments