Bawan · CS Graduate · University of Kent
MIRRAGE.
A privacy-first ambient AI smart mirror — a graduate engineering project pairing a React interface with a FastAPI backend and an AI provider abstraction, built toward a Jarvis-style home assistant.
- Stack
- React · FastAPI
- AI Layer
- Provider abstraction
- Data
- Live weather + cache
- Status
- Under active dev
08:42 AM
Sunday, 17 November 2024
12°C
Auckland, NZ · Cloudy
System Status
All systems nominal
Voice Status
Voice system inactive
AI Assistant
Good morning.
How can I help you today?
MIRRAGE AI
YOUR AI SMART MIRROR
Why this project is worth your attention
A 15-second read: what Mirrage demonstrates about how I build software.
Full-stack product engineering
A React + TypeScript frontend and a FastAPI backend, designed as one coherent system rather than disconnected pieces.
AI integration with provider abstraction
An AI layer that sits behind a single interface, so stub, local Ollama, or OpenAI-compatible providers can be swapped without touching the UI.
Tested, documented, Dockerized
Automated backend tests, linting, formatting, type-checking and a one-command Docker Compose setup — built like a maintainable project.
Hardware & software product thinking
A documented hardware roadmap and signal path show the product is planned end-to-end, not just as a screen demo.
An ambient AI assistant for the home
Build an intuitive, private and powerful AI companion that lives in your mirror and understands your world. The mirror is the first interface — the long-term product is a home AI system that can understand context, respond naturally, and eventually control smart home devices.
Minimal Home State
The mirror stays quiet and ambient — time, a glance of weather, a soft pulse. Nothing competes for attention until you need it.
Focused View
Ask for weather, the assistant, or media and the requested information animates smoothly into full focus, front and centre.
Return to Home
After a short moment the interface collapses back to its calm resting state, leaving a clean, mirror-first surface.
The mirror should stay quiet and minimal until needed — then animate the requested information into focus.
What Mirrage can do now
Everything below is built and running today, grouped by layer. Voice, Spotify, calendar, smart-home control and the physical mirror are planned — not yet complete.
Frontend
- React + TypeScript + Tailwind mirror interface
- Minimal home state
- Ambient focus views
Backend
- FastAPI service
- Health / system / voice / weather / assistant endpoints
- Pydantic schemas
- Service-layer separation
AI
- Provider abstraction
- Stub provider
- Ollama provider (supported / configurable)
- OpenAI-compatible provider (supported / configurable)
- Safe fallback responses
Data
- Open-Meteo live weather
- Cached / fallback weather response
Infrastructure
- Docker Compose
- GitHub Actions CI
- Pytest
- Ruff / ESLint / Prettier / TypeScript checks
Working now vs planned
Mirrage is under active development. This is the clearest way to see what is real today versus what is on the roadmap.
Working now
- React mirror frontend
- FastAPI backend
- Assistant endpoint (stable response shape)
- AI provider abstraction boundary
- Live weather (Open-Meteo + cache/fallback)
- Docker Compose setup
- GitHub Actions CI and backend tests
- Hardware planning documentation
Planned
- Voice input/output (real STT/TTS)
- Spotify / media controls
- Calendar integration
- Memory layer
- Smart home controls
- Physical mirror installation
- Production deployment
- Authentication & user accounts
How the system fits together
Three views of the architecture: the high-level stack, the live weather path, and the assistant request path. Lower hardware and voice layers are planned.
A. High-level system
The frontend owns the mirror interface; the backend owns APIs and service logic. The AI provider layer lets local or cloud models be swapped without touching the frontend.
B. Weather flow
Live weather comes from Open-Meteo, but the service caches results and falls back gracefully — the mirror keeps showing something useful even if the API is unavailable.
C. Assistant flow
A message hits a thin route, the assistant service routes it through the provider abstraction, and the response always comes back in a stable shape. Real replies require a configured provider.
A small, predictable backend
The FastAPI backend exposes a deliberately compact set of endpoints. The assistant endpoint returns a stable response shape; real model replies require a configured provider. Calendar is planned, not live.
Dev base: http://localhost:8000/healthService health check/api/system/statusSystem status for the dashboard/api/info/weatherLive weather (Open-Meteo, cached)/api/voice/statusVoice engine status (status only)/api/assistant/messageSend a message to the assistant/api/info/calendarPlannedCalendar eventsEndpoint paths are representative of the current backend. There is no public authentication or user system yet — auth is part of the future roadmap.
How the codebase is structured
The decisions a technical interviewer would ask about — kept concise and concrete.
Thin API routes
Routes delegate logic to service modules instead of holding business logic directly, keeping endpoints small and testable.
Provider abstraction
The AI layer supports multiple providers behind the same interface, so the model can change without touching the frontend.
Typed frontend contracts
TypeScript types mirror backend response shapes to reduce frontend/backend mismatch and catch errors early.
Resilient external integration
Weather data uses caching and fallback behaviour instead of blindly depending on a live API being available.
CI-backed quality
Automated checks run linting, formatting, tests, type-checking and frontend build validation on changes.
The Physical Mirror Build
The software platform is under active development today. The physical mirror below is planned and documented — here is how the finished product is designed to work.
Build concept
PlannedConcept layout of the planned hardware — not yet built.
Signal path
Components
Software prototype
£0 – £300
Runs on existing hardware
First physical prototype
£700 – £1,500
Display, SBC, glass, frame
Premium home installation
£2,000 – £5,000
Finished, wall-mounted build
A look at the interface
The live dashboard preview below is rendered from the real interface concept. Other views are clearly labelled as upcoming captures — no mocked-up screenshots are presented as finished features.
08:42 AM
Sunday, 17 November 2024
12°C
Auckland, NZ · Cloudy
System Status
All systems nominal
Voice Status
Voice system inactive
AI Assistant
Good morning.
How can I help you today?
MIRRAGE AI
YOUR AI SMART MIRROR
Weather focus view
Live conditions animating into full focus.
Assistant focus view
Conversational panel with a stable response shape.
Architecture diagram
Frontend → backend → service → provider layers.
Physical build concept
Two-way mirror, hidden display, mini computer.
Built like a real project, not a one-off demo
The quality signals an employer can verify in the repository.
Backend tests
Automated suite
Pytest covering backend behaviour and the service layer.
Continuous integration
GitHub Actions
Checks run on changes — lint, format, type-check, tests and build.
Docker
Compose setup
Frontend + backend run together with one command for development.
Documentation
Written up
Architecture, API, roadmap, voice plan and hardware notes.
Frontend checks
Backend checks
Engineering challenges & decisions
The thinking behind Mirrage — the trade-offs and choices that shaped how it is built.
Keeping the UI honest
Every section clearly separates what is working from what is planned. It is tempting to overclaim on a portfolio, but a credible interface that tells the truth is worth more to an employer.
Designing the AI layer before locking in a model
Rather than hard-wiring one model, the assistant talks to a provider abstraction. Stub, local Ollama, and OpenAI-compatible providers all sit behind one interface, so the model choice can change later without a rewrite.
Separating presentation from service logic
The frontend handles the mirror experience; the backend owns APIs and business logic in service modules. Thin routes keep responsibilities clear and the system easier to test.
Planning hardware before buying parts
The physical mirror is documented — components, signal path and cost tiers — before spending money. This de-risks an expensive build and keeps the software-first approach deliberate.
Making the mirror feel ambient, not cluttered
The interface stays in a calm home state and only brings information into focus when needed, so the product feels like a mirror first and a dashboard second.
Building in small, tested phases
Work is shipped in phases with tests, CI and documentation alongside it, so the project stays maintainable as it grows instead of becoming a fragile prototype.
The tools behind Mirrage
Frontend
Backend
AI Layer
Voice Layer (planned)
Infrastructure
Quality
Hardware
What this project demonstrates
The skills behind Mirrage, each one something I can talk through and show in the code.
Where Mirrage is — and where it's going
The software foundation is complete and running. Everything after it is a planned, phased path toward the full ambient home assistant.
Foundation
Software platform
- React frontend
- FastAPI backend
- AI provider layer
- Live weather
- Docker, CI & tests
Phase 1
Voice interaction
- Push-to-talk
- Speech-to-text
- Text-to-speech
- Wake word (later)
Phase 2
Spotify / media
- Spotify connection
- Current track + artwork
- Playback controls
Phase 3
Calendar integration
- Daily schedule
- Upcoming events
- “What do I have today?”
Phase 4
Memory layer
- Local-first preferences
- Goals & routines
- Personal context
Phase 5
Smart home
- Home Assistant integration
- Lights & scenes
- Confirmation for sensitive actions
Phase 6
Physical mirror build
- Two-way mirror glass
- Display + compute
- Mic, speakers, frame
- Install + production deploy
Hi, I'm Bawan.
I'm a Computer Science student at the University of Kent building Mirrage as a serious graduate portfolio project. I'm using it to develop and demonstrate full-stack engineering, AI integration, system design, documentation, testing, and product thinking. The long-term goal is to turn Mirrage into a real ambient AI assistant that I can install and use in my own home.
Built as a portfolio project. Designed as a real product.
Mirrage is being built step by step: software foundation first, ambient interaction next, then voice, integrations, memory, smart home, and finally the physical mirror installation.