The problem
An AI chat interface can look finished while leaving important product questions unresolved: where conversation history lives, who controls memory, what happens to uploaded files, and how provider credentials are handled. AdizillaAI is an attempt to make those parts of the experience explicit rather than treating them as invisible plumbing.
Constraints
The application needs to work for both guests and signed-in users. It also relies on external AI, identity, storage, and billing services, each with its own configuration and failure modes. Provider secrets must stay on the server, and usage needs limits that are enforced beyond the browser UI.
What I built
The public app combines a responsive conversation workspace with:
- Firebase email/password and Google sign-in, password reset, and server-side ID-token verification.
- Firestore-backed chat history for signed-in accounts, while guest history stays in the current browser.
- User-controlled memory that can be edited, enabled, disabled, or cleared.
- Attachments for supported images, PDFs, Word documents, text, data, and code files.
- Server-side per-account usage limits and a configurable OpenAI-compatible provider.
Decisions and trade-offs
Keep provider credentials on the server. This adds backend configuration work, but avoids exposing secret API keys in browser code.
Make memory user-controlled. Memory is a feature users can manage, not an opaque behavior they have to accept.
Separate guest and account history. Guests can try the product without signing in; signed-in users get cloud-synced history. The trade-off is maintaining two persistence paths.
The hard part
The hard part is coordinating multiple systems without making the user responsible for understanding all of them. Authentication, chat storage, AI provider configuration, attachments, rate limits, and billing have different failure modes. The product needs clear states and server-side enforcement, not just a polished input box.
Outcome
The project is publicly deployed at adizillaai.vercel.app ↗, with source available on GitHub. The README documents the app's current features and configuration requirements.
I am not publishing user counts, latency figures, or retention claims because I do not have verified public measurements for them.
What I'd improve next
I would make setup and degraded states even more legible, especially when an AI provider, identity service, or billing offering is not configured. The next round should pair that work with repeatable end-to-end tests for guest and signed-in journeys.