2
7 Comments

I stopped building my AI infra product to find if anyone actually needs it

I have been building RuntimeBrain, a Python layer that adds a pre-call EXPLAIN step to OpenAI requests.

The idea is simple: before an AI request runs, show the developer what execution decision is being made, why, what risk/uncertainty exists, and what they may want to review.

It does not proxy the request, make another LLM call, or replace the native OpenAI response.

I have reached the point where the Developer Preview works, and I don’t want to keep adding features without evidence.

So I am looking for 3–5 developers using Python + OpenAI on real workloads, especially agents, RAG, or higher-volume apps, who are willing to try it privately and tell me:

Did it show you anything you didn’t already know?
Did it make you reconsider an execution decision?
Would you keep it installed?
What did you expect it to tell you that it didn’t?

Setup is around 10 minutes. It’s free, private, and there’s no RuntimeBrain account or hosted control plane.

If this sounds relevant to what you’re building, comment or DM me. I’m more interested in blunt feedback than signups.

on August 26, 2026
  1. 1

    This is a brilliant approach to solving the LLM 'black box' problem without adding proxy overhead. I’m currently running Python/OpenAI pipelines and would love to test the Developer Preview. Happy to put it through its paces and give you the blunt, raw feedback you need. DMing you

    1. 1

      Thank you, could you share your contact email? so I can share private preview?

  2. 1

    This is directly relevant to the Python and OpenAI agent systems I work with. I think a strong future direction would be connecting the pre-call explanation to post-call results such as cost, latency, tool failures, and output quality, so its warnings improve over time. I’m an ML engineer with agent and RAG experience, and I’d be happy to join the private preview and give you detailed feedback.

    1. 1

      Hey, just following up in case you missed my reply. If you’re still interested in the private preview, feel free to send me your preferred contact method or email and I’ll send the build + quickstart there.

    2. 1

      Thanks, you sound like a great fit for the preview. Since Indie Hackers doesn’t support DMs, could you email me at the ravibuildswork@gmail.com or share your contact? I’ll share the private build + quickstart there.

  3. 1

    This is the measurement turn-off-the-build-to-measure approach, and it's the move. Most builders reach feature-complete and then start asking "does anyone want this?" You stopped and asked before adding more.

    That question shift matters: you built until you had something working, then you gate advancement on real signal. 3-5 developers using it on real workloads will tell you what 1,000 GitHub stars never could (does it make them reconsider an execution decision?).

    The "blunt feedback over signups" line is key. Signups measure interest in the concept. Actual usage under load measures whether the insight is real and valuable. One developer using it on a RAG pipeline that processes 10K requests/day teaches you more than 100 curious developers who never install it.

    Most teams optimize the wrong measurement: they track GitHub stars, email signups, landing page interest. But the measurement that matters is "does this change actual behavior on real problems?" Everything before that is just flavor preference data.

    1. 1

      Exactly, that’s the signal I am trying to get to. I would rather have a few developers use it on real workloads and tell me it didn’t change anything than optimize for signups or stars.

      If you’re running Python/OpenAI workloads yourself, or know someone who is, I’d be happy to include them in the small preview cohort.