Background
A chat platform that unifies models instead of separating them
Lura grew out of a specific problem: people working with AI switch between different chat interfaces every day. Context gets lost, habits must be rebuilt and every platform behaves differently. The goal was not another AI app, but one coherent tool with cross-project memory, seamless model switching and an interface fast enough to stay out of the way.
Process
Challenge
People working with AI move between different interfaces every day, losing context and established workflows along the way.
Solution
A unified interface with cross-project memory and seamless model switching – one tool, regardless of the underlying model.
Decision
Open-source models instead of relying exclusively on closed APIs – providing greater control over data, costs and availability.
Outcome
A productive chat platform where several models feel like a single tool.
Projects
Multiple chats can be organised within a project. Cross-project memory keeps context available across individual conversations.
Models & providers
Choose and manage different AI models from multiple providers in one central interface. This makes it easy to use the right model for each task and switch whenever needed.
Memory & Chat Context
Lura keeps relevant information available across chats, so project context remains intact when a conversation ends or the active model changes.
Code generation
Code is generated directly in the chat and can be reviewed in an integrated preview – from an idea to a working component.
Architecture & engineering
Four decisions that support the system
Lura uses a lean full-stack architecture built on Next.js and Firebase, deliberately avoiding an additional server layer that would require separate maintenance.
All model responses are streamed token by token through server-side API routes. Credentials and model routing stay in one place, and providers can be changed without modifying the client.
Learnings
What I learned from Lura
The most important lessons from architecture, integration and operation.
The visible part of streaming was completed within a few days. Interruptions, race conditions and incomplete responses required considerably more work.
