Low-code builders (Lovable, Base44, etc.) keep getting stuck on AI chat features
Hi folks,
I’ve been spending a lot of time on Discord and Reddit helping people who are trying to add AI chat to their no/low-code apps.
What keeps coming up is that the setup is way more fragile than it looks.
It’s usually not the model itself — it’s everything around it:
conversation state, memory, retries, edge cases.
Vibe-coding works for demos, but once people try to ship something real, things start breaking.
After answering the same questions again and again, I tried to simplify the setup for myself.
I recorded a short video showing the approach I’ve been experimenting with, mainly to make the discussion concrete.
Posting it here for context and feedback, not as a promotion.
I’m genuinely curious:
How are you handling chat memory today?
Where does your setup usually fall apart?
Do you avoid chat features altogether because of this?
Would love to hear how others are dealing with this.
Replies
My experience building an AI chatbot on Genstellar.ai (vibecoded with Replit)
Great thread! I recently built "Cosmic" -the AI chatbot for Genstellar.ai, a visual workspace platform -entirely in Replit, and your observations really resonate.
How I'm handling chat memory:
Full database persistence with PostgreSQL. Each conversation is stored with user context, project awareness, and message history. The key insight was treating chat memory as first-class data, not an afterthought. We also implemented per-user isolated AI chats in collaborative workspaces - so multiple users can have private AI conversations while sharing the same canvas. This required careful session management and user-scoped queries.
Where things usually fall apart:
Exactly what you said - it's everything around the model:
Streaming responses were tricky. Getting SSE (Server-Sent Events) to work reliably across different network conditions took iteration.
Multi-model support (we integrate GPT-4, Claude, Gemini, DeepSeek, and Grok) meant building abstraction layers that handle different API quirks gracefully.
Context engineering - knowing what to include in the prompt. We built an auto-indexing system that processes canvas objects (PDFs, images, documents) so the AI has relevant context without overwhelming token limits.
Edge cases like rate limits, API failures, and partial responses needed proper retry logic with exponential backoff.
Do I avoid chat features?
Not anymore, but I understand why people do. The turning point was treating it as a proper backend system rather than a quick integration. Replit's environment made iteration fast - I could test changes instantly, see logs in real-time, and deploy updates without context switching.
The vibe-coding approach got me a working demo in hours, but the production-ready version took proper architecture: typed schemas, streaming handlers, error boundaries, and persistent storage.
One tip: Start with the data model. Define your conversation structure, message types, and context sources upfront. It saves a lot of refactoring later.
Happy to share my thoughts!
Amarsia
Looking for feedback from low code builders out there!
I personally steer clear as it feels like without adding significant knowledge base to it, you are just not in control of what it says on behalf of your brand. I think that is a real risk.
Again not a promo, but I think there are some decent knowledge base tools on some legacy chat apps, eg: live chat apps, that do a more reliable job of controlling the message. But I guess they are also limited too. Tricky one, but totally get it.
I'm using an AI insight popup based on a knowledge base of SOPs that I've built over the years for a marketing app, but cautious to ring fence the amount of AI engagement for exactly your reason. I'm using Lovable for mine. I should probably get you to break my app at some point :)
Really clear and simply video btw
Depending on how long the memory needs to be , just store 5,10 latest messages locally. Or let the user create "important memory" and store in externally and add to every message.. worked for me with locally storing latest messages , longers prompts but the cost is not that significant in only text.
Amarsia
@markus_kask That sounds good for building a demo but does that fulfil your production needs?
What if the user refresh the page?
This matches what I’ve seen too. The model is rarely the problem. State, memory, and edge cases are.
Vibe-coding gets you a demo. Real apps need a boring structure.