Email registration OTP
A new email/password account remains pending until the email code is confirmed. The OTP screen persists if the user opens their mailbox and returns.
Melager is a multi-mess management app for members, meals, daily expenses and deposits—with simple, guarded administration.
↗ 12% Monthly activity is up
Members first. Every feature is scoped to the selected mess and the member's role.
Safe by design. Sensitive changes require an email verification code.
Fast on mobile. Cached sessions and monthly snapshots reduce wait time.
A closer look at the core mobile experience for tracking meals, expenses, deposits and shared mess accounting.






The normal path is deliberately short. New users can register with email verification, use Google sign-in, then create or join one or more messes.
Sign up with name, email, password and optional phone, then confirm the six-digit email code.
Creators become primary admins. Members can request entry using a mess key and wait for approval.
The root hub keeps every membership in one place. Switch messes at any time without signing out.
Record meals, expenses and deposits, then review member balances from the dashboard.
Authentication and verification flows preserve the user's place when they leave the app to read an email.
A new email/password account remains pending until the email code is confirmed. The OTP screen persists if the user opens their mailbox and returns.
Google ID tokens are verified on the backend. An existing verified email is linked to its Google account; new Google users are created directly.
Forgot-password requests use an email code before a new password is accepted. The reset code screen is also restored after app resume.
A JWT session is stored locally with a cached profile. The app restores known state first, then refreshes it in the background.
Passwords are never stored in the mobile OTP flow. The backend retains only a temporary hashed payload until email verification succeeds.
Melager separates account identity from mess membership. A person may join different messes as a member in one and an admin in another.
All active memberships and pending/rejected join requests appear on the root page. With more than four messes, the list scrolls while Create a New Mess and Join a Mess stay visible.
Admins can search pending requests by name or email, then accept or reject each request. Approval creates a linked consumer record in the mess.
Admins have a searchable member directory with contacts. They can add members, copy details and remove manually added members when no accounting records block deletion.
The selected month drives the core workspace. Navigation moves between months while each mess keeps its own records isolated.
Admins enter per-member daily meal counts in a horizontally scrollable grid, with totals by member, day and month. Fill mode speeds up repetitive entries.
Each day holds multiple named expense items. Open a day to inspect its list, then add, remove or save entries from an optimized keyboard-aware sheet.
Record timestamped deposits with optional notes. The app shows a ledger and a member history, while aggregate month totals remain visible.
Review meals, total costs, deposits and balances per consumer. Admins can export a PDF breakdown and send email summaries.
Admins can set meal availability, opt-out windows and menus for breakfast, lunch and dinner. Members can opt out where a window allows it.
Monthly snapshots are cached locally. Operations that need a server connection clearly require the device to be online.
Members see view-only accounting screens. Admin actions are protected by the selected mess and, for sensitive actions, an email OTP.
A mess may have more than one admin. Adding a co-admin leaves the current admin unchanged.
When the primary admin role is transferred, the sender becomes a normal consumer and the selected member becomes primary admin.
An admin cannot remove their own role if they are the only remaining admin in that mess.
The product is split into an Expo React Native app and an Express/Drizzle backend. This website is a third, independent Next.js project.
AuthContext holds the account, active mess and session. MessContext owns month data. Network, notifications and drawer behavior use separate providers.
Bearer JWT middleware protects private routes. Controllers validate mess access before returning or changing data. Unique database constraints prevent duplicate monthly cells and duplicate member requests.
All API routes are prefixed with /api. Except for registration and sign-in routes, requests require an Authorization: Bearer <token> header.
/auth/signupCreate a pending account and email a verification code.
/auth/verify-otpVerify registration OTP and begin a session.
/auth/loginSign in with email and password.
/auth/googleVerify a Google ID token and sign in or link an account.
/auth/meLoad the account, available messes and join requests.
/mess/createCreate a mess; the creator becomes its primary admin.
/mess/joinSubmit a join request using a mess key.
/mess/data/:yearMonthGet consumers, meals, expenses and deposits for a month.
/mess/mealsWrite a meal count for a member and date.
/mess/expensesSave all expense items for a day.
/mess/deposit-entryRecord a timestamped deposit entry.
/settings/security/request-otpStart a protected security action by email OTP.
/settings/accountVerify the password, delete the login account, and anonymize retained mess ledger records.
/auth/account-deletion/request-otpEmail a short-lived account deletion verification code.
/auth/account-deletion/confirmVerify the deletion code and anonymize retained mess ledger records.
EXAMPLE REQUEST
POST /api/mess/meals
Authorization: Bearer <session-token>
Content-Type: application/json
{
"messId": 7,
"consumerId": 24,
"yearMonth": "2026-08",
"day": 12,
"count": 2
}The backend scopes the write to the requested mess after checking that the authenticated user belongs to it with an appropriate role.
Use separate environment configuration for the mobile client and API. The documentation project itself needs neither at runtime.
Set EXPO_PUBLIC_API_URL and EXPO_PUBLIC_GOOGLE_WEB_CLIENT_ID in the EAS build profile. A native development or production build is required for Google Sign-In.
Configure PORT, DATABASE_URL, SESSION_SECRET, email delivery values and a comma-separated GOOGLE_CLIENT_IDS allowlist containing the web client ID.
Register Android clients in Google Cloud using package com.melager.mobile plus each signing SHA-1. Keep one for EAS development and add a second one for Google Play App Signing.