2
3 Comments

What was the hardest part of building your AI assistant backend?

I’m researching an idea for a managed backend for AI assistants - something like “Supabase for AI assistants.”

The idea comes from a problem I keep seeing: building the actual AI feature is often the easy part. You can call a model and get a response in a few lines of code.

But turning that into a real product requires much more infrastructure:

  • Storing conversations and messages
  • Keeping each end user’s data isolated
  • Managing assistant prompts and configuration
  • Supporting streaming responses
  • Adding long-term user memory
  • Handling files and retrieval
  • Executing tools safely
  • Tracking usage, costs, errors, and latency
  • Supporting multiple models and providers
  • Managing retries, rate limits, and background processing

For a solo founder or small team, this can turn a relatively simple AI feature into a much larger backend project.

The product we’re considering would provide this infrastructure as a managed service. A developer could configure an assistant and send messages through a simple SDK:

const assistant = client.assistant("support-assistant")

const response = await assistant.sendMessage({
  endUserId,
  conversationId, // optional
  message
})

If no conversationId is provided, a new conversation would be created automatically.

Behind that API, the platform would handle conversation storage, model calls, user context, memory, files, tools, and observability.

The goal is not to provide a chatbot UI or a no-code bot builder. Developers would still build their own product, interface, and business logic. We would provide the backend infrastructure that sits underneath the AI assistant.

I’d like to hear from indie hackers who have already built an AI chatbot, copilot, or assistant:

  • What parts took longer than you expected?
  • What infrastructure did you build yourself?
  • Which problems only appeared after you had real users?
  • What frameworks or services did you use?
  • What do you wish had been available when you started?
  • Would you trust a managed platform with your conversation data and AI runtime?
  • Would this save you meaningful development time, or would you prefer to keep everything in your own database?

We haven’t built the product yet. I’m trying to understand whether this is a meaningful enough problem before committing to an MVP.

Honest criticism is especially useful. I’d like to know why you would or would not use something like this.

If you’ve built an AI assistant and would be open to a short 20-minute call about your experience, please comment or send me a DM. I’m looking to learn, not pitch. Thank you all!

on August 5, 2026
  1. 1

    The hardest part is usually not the model call, it is reliable state across tools, retries, permissions, and human handoffs. I would design around traceability first: what the assistant believed, which action it attempted, what changed, and how an operator can reverse or correct it.

  2. 1

    For us it was the cost tracking + multi-provider part. When you route across 4-5 models you lose track of what's actually eating your budget unless you log everything from day one. Silent failures are a close second - they just burn tokens without you noticing.

  3. 1

    The interesting part is that moving fully on-device wasn't just an engineering choice — you accepted real latency and model-quality tradeoffs for privacy.

    With TestFlight open now, what are you hoping early usage will tell you before you commit further to that tradeoff?