Project status
This page explains where Moveat stands today from a product and operations perspective. It is meant to help non-specialist readers understand what already exists, what is being validated, and what still needs to be completed before the core product loop is considered stable.Moveat is currently in an MVP foundation phase. The system has the core architecture, infrastructure and several business modules in place, but the full end-to-end product loop is still being hardened.
Current stage
Moveat is past the pure prototype stage. The project already has separate repositories, production infrastructure, database persistence, authentication, documentation, API docs, observability and a conversational Agent foundation. The main objective now is to connect the product loops end to end:Nutrition loop
User logs food from web or Agent, Platform stores meal entries, and daily nutrition summaries update once.
Progress loop
User logs weight, Platform stores canonical metric values, and the frontend renders the right display unit.
Training loop
User logs workouts, exercises and sets, and Platform keeps durable training history.
Coaching loop
Agent uses Platform context and LLM interpretation to reduce friction and personalize replies.
What exists today
| Area | Current state | Operational meaning |
|---|---|---|
| Documentation | Mintlify docs repository connected to docs.mov-eat.app. | Product, technical and operations knowledge is centralized. |
| Frontend | Web client is deployed separately, currently through Vercel. | Browser users interact with Moveat outside the backend droplet. |
| Platform | NestJS + Prisma backend with modular monolith structure. | Platform owns business state and exposes public plus internal APIs. |
| Agent | Go service with WhatsApp adapter, LLM adapter foundation, orchestration and Redis session state. | Agent can evolve without polluting Platform with channel logic. |
| Database | PostgreSQL runs in the production stack. | Product data is durable and local to the droplet to reduce latency. |
| Redis | Redis runs in the production stack. | Short-lived session, cache and conversation state are available. |
| Reverse proxy | Caddy handles HTTPS and routing. | Public domains route to the right internal containers. |
| Observability | Grafana, Loki and Alloy are deployed. | Logs and operational dashboards are available for debugging. |
| Container management | Komodo is deployed. | Containers can be inspected and managed from a web UI. |
| API inspection | Platform exposes Swagger for web and Agent/internal APIs. | Engineers can inspect live request/response contracts. |
Platform implementation status
| Capability | Status | Notes |
|---|---|---|
| Email/password auth | Available | Uses HTTP-only opaque sessions for browser users. |
| Google auth backend | Available | Requires frontend Google client flow and configured client ID. |
| Session management | Available | Frontend authenticates by cookie, not by reading JWTs. |
| Onboarding | Available | Creates profile, goals and nutrition settings together. |
| Unit conversion | Available | Platform stores metric canonical values and converts for display. |
| User channels | Available | Channels are separate from users and support future multi-channel expansion. |
| Coaching profile/context | Available | Kept separate from /me to avoid bloating session responses. |
| Meal logging | Available in Platform | Needs continued end-to-end validation with frontend and Agent. |
| Daily nutrition summary | Available in Platform | Updated from meal entries and used for dashboard reads. |
| Weight tracking | Available in Platform | API contract should return display values plus response-level unit system. |
| Workout tracking | Foundation available | Requires more end-to-end product validation and stronger tests. |
| Swagger | Available | Public docs and Agent/internal docs are separated. |
Agent implementation status
| Capability | Status | Notes |
|---|---|---|
| WhatsApp webhook adapter | Available | Handles verification, signature validation and payload mapping. |
| WhatsApp reply sender | Available | Sends replies through Meta Cloud API. |
| Channel-neutral conversation model | Available | Core models avoid WhatsApp-specific business logic. |
| LLM abstraction | Available | Gemini adapter exists; future adapters can implement the same provider contract. |
| LLM parsing/interpreter | Available | Structured output parsing exists for intent and decisions. |
| Redis session store | Available | Stores short-lived conversation state. |
| Platform integration | In progress | Agent should call Platform internal APIs for all durable business writes. |
| Media handling | Planned/partial | Food images/audio require reliable media download and multimodal interpretation. |
Infrastructure status
| Component | Status | Purpose |
|---|---|---|
| DigitalOcean droplet | Active | Hosts backend, database, Redis and operations stack. |
| Docker Compose | Active | Defines the production stack. |
| Caddy | Active | Handles TLS and reverse proxying. |
| PostgreSQL | Active | Durable source of truth. |
| Redis | Active | Short-lived state and cache. |
| Grafana | Active | Dashboards and log exploration. |
| Loki | Active | Log storage. |
| Alloy | Active | Collects Docker logs and ships them to Loki. |
| Komodo | Active | Container management and operational visibility. |
| Mintlify | Active | Hosts product and operations documentation. |
| Vercel | Active | Hosts frontend deployments. |
Near-term priorities
The next project phase should focus on reliability and end-to-end behavior rather than new surface area.- Finish and validate meal logging end to end from web and Agent.
- Harden weight and workout API contracts before the frontend depends on them heavily.
- Complete Agent-to-Platform client integration with internal auth and idempotency.
- Improve Platform coverage in the critical business paths that currently pull coverage below threshold.
- Improve Agent coverage around Platform client, provider behavior and failure handling.
- Export or sync Platform OpenAPI specs into the docs repository.
- Define the bilingual documentation workflow before translating every page.