FeaturedSaaSFull-StackOperationsProduct

MenuJan — Digital menus and café operations

A Persian-first café platform I built end-to-end: branded QR menus, guest ordering, kitchen workflows, recipe inventory, settlement, customer loyalty, and subscription operations.

Year

2026

Role

Founder / Full-stack

Stack

Next.js • TypeScript • PostgreSQL

Live

Context

MenuJan connects the menu a guest sees with the work a café team actually performs. I built the product across the guest experience, staff workspace, backend, database, access control, and deployment so ordering, preparation, stock, and settlement follow one consistent model.

What needed to work

01Keep printed table and wall QR codes usable through appearance changes, table archival, and access resets.
02Protect venue boundaries and staff permissions on every server-side operation, including financial exports and order corrections.
03Keep pricing, tax, recipe consumption, settlement, and loyalty consistent when requests are repeated or happen concurrently.
04Provide Persian mobile-first menus and staff tools, recoverable account access, and a clear boundary between offline reading and connected operations.

What I built

A shared menu and appearance system with seven layouts, permanent QR identities, print tools, guest checkout, and signed active-order tracking.

Transactional PostgreSQL workflows for kitchen status, POS, stock recipes, invoice snapshots, cashier settlement, discounts, and customer rewards.

Permission-scoped dashboards, rotating sessions, consent-aware SMS, private subscription receipts, PWA entry points, and a Docker delivery pipeline.

My role

I own the product’s full-stack implementation: interface and workflow design, domain rules, PostgreSQL schema and migrations, authentication, browser and integration verification, deployment, and ongoing iteration. The detailed report below explains the decisions and the limits of the implementation.

The result

A working product that connects public digital menus to the café’s daily service, inventory, financial history, and customer relationships.
Explicit safeguards for repeated checkout, concurrent state changes, historical prices and tax, stock consumption, and session revocation.
A Persian-first responsive experience with configurable branding, permanent print identities, installable entry points, and internal CSV/XLSX reporting.

Inside MenuJan: product and engineering report

A closer look at how I connected a guest-facing digital menu to the operational work behind a café: service, preparation, stock, payments, customer relationships, and subscription management.

Product and source reviewed on October 23, 2026. Public screenshots show the live site; dashboard captures use a separate local demo café with synthetic data. Results below describe implemented behavior, without inventing adoption, revenue, or performance measurements.

One connected service journey

1
Scan a permanent QR
2
Browse and receive a quote
3
Submit an order
4
Prepare and consume stock
5
Serve and settle
6
Report and reward

01 — The product problem and my responsibility

A digital menu solves only the first part of a café visit. Once a guest chooses a drink, the team still has to identify the table, prepare the right items, account for ingredients, collect payment, and understand the day’s sales. When these steps live in separate tools, the same order has to be interpreted repeatedly.

I built MenuJan as a Persian-first café and restaurant operations product, taking responsibility across interface design, frontend, server-side workflows, relational data modeling, authentication, deployment, and iteration. The central design decision was to make the guest menu and the staff workspace share one authoritative operational model.

The product serves several distinct users: guests browsing or ordering from their phones; waiters managing tables and requests; kitchen staff preparing tickets; cashiers confirming settlement; owners managing the business; and platform administrators handling subscription and account operations. Each surface exposes the work appropriate to that user.

Guests open a public venue URL or scan a table QR without installing an application. The menu supports category navigation, search, item descriptions and images, prices, availability, and item details. A venue-information dialog brings together the address, contact details, hours, map, website, and supported social links when the owner has supplied them.

The appearance editor supports seven layouts: grid, list, accordion, editorial, compact, tiles, and mosaic. Each layout retains its own image ratio, containment or crop behavior, focal point, and image background. Owners can adjust branding, palette, banner framing, description density, corners, spacing, category icons, and whether visitors may change layouts. Preview and published menus use shared item-rendering components, reducing visual drift.

The category strip follows the visible category and scrolls horizontally to keep the active choice in view. The toolbar responds to scroll direction while retaining access for focused controls. Welcome messages and scheduled bars, cards, or modals provide venue-specific communication, with reduced-motion behavior. Optional per-person entrance notices are disclosed separately rather than silently added to each food order.

03 — Permanent QR codes and a practical print studio

Printed table cards are physical infrastructure: replacing them after an ordinary settings change is expensive and confusing. MenuJan separates the identity printed in a QR from the shorter-lived access it grants. Table and wall print keys remain stable, with database protections against changing those identifiers after creation.

Archiving and restoring tables preserves their links and historical identity. An access reset revokes earlier guest sessions while retaining the printed destination. A wall or entrance QR opens the venue menu without falsely assigning a table. Table-specific ordering and waiter requests require the appropriate signed context; a normal menu visit does not let a customer invent a table number.

The studio provides colors, supported module styles, optional venue branding, captions, PNG/SVG downloads, and A4 layouts for stickers, cards, and signs. Print preparation waits for the bundled Persian font and embedded QR artwork before opening the browser’s print or Save as PDF flow. The QR renderer protects function modules and readable ink contrast. Permanent links still depend on domain continuity and retained database records; a shared photograph of a valid table QR remains a bearer credential.

04 — Authoritative checkout and order tracking

The browser submits item identifiers, quantities, and order context. The server resolves the venue catalog, availability, current pricing, discounts, and tax settings. A quote hash supports explicit reconfirmation after a price or tax change. Client-supplied totals are not treated as financial authority.

An idempotency key, canonical request hash, and transactional locking make a repeated submission return the existing order, while a changed request using the same key is rejected. Order lines retain the charged item name, price, tax, and recipe snapshots so later catalog edits do not rewrite the historical sale. Invoice numbering is allocated per venue in the transaction.

After anonymous checkout, a signed capability grants access to that order’s active receipt and status. Guests can reopen active orders after reload and acknowledge a ready notice that persists across tabs. Status polling runs while the page is visible; settlement or cancellation closes server access to the active details. The browser retains only a bounded local summary. Public checkout can require a phone number when the venue chooses, while basic ordering and club verification remain separate concerns.

05 — The staff workspace: tables, POS, kitchen, cashier

The staff dashboard combines table management, waiter calls, point-of-sale order entry, a kitchen board, history, and settlement. A staff member starts in a workspace selected from their actual permissions, so a kitchen user is not dropped into an owner’s management overview.

The kitchen board orders tickets for preparation and exposes the next permitted actions directly on each ticket. It checks a compact venue-scoped revision every five seconds, refreshes changed information, pauses in hidden tabs, and shows connection failures. This is server-authoritative polling; the interface does not claim websocket delivery or present a disconnected submission as successful.

An explicit transition graph and scoped row locks serialize preparation, serving, settlement, edits, and deletion. Early-stage orders can be corrected with revision checks and audit snapshots. Separate permissions protect editing, deletion, and settlement. A cashier confirms a served order with the payment method actually received; the payment row, paid timestamp, loyalty updates, and notification enqueue commit together. This workflow records settlement rather than processing an online payment.

06 — Recipes, consumption, and inventory history

Menu items can reference ingredient recipes with quantities and units. Preparing an order consumes its snapshotted recipe once, with ingredients updated in stable order and sufficient-stock conditions. If any ingredient is insufficient, the preparation transaction rolls back rather than leaving a partially consumed order.

The distinction between waste and correction is deliberate. Cancelling food that has already entered preparation preserves its ingredient consumption as waste. Removing an explicitly mistaken or test order follows a separately authorized correction path, restoring the relevant stock and removing that order’s financial and loyalty effects while retaining the deletion audit. These actions are not interchangeable.

The inventory workspace exposes balances, low-stock thresholds, opening stock, adjustments, and order consumption. Movements retain ingredient and unit details, actor context, order references, and resulting balances. Usage reports group compatible units rather than summing unrelated quantities. Historical recipe relationships also constrain destructive ingredient changes.

07 — Financial history, VAT snapshots, and usable exports

MenuJan stores whole-toman monetary amounts and integer tax basis points. Venue defaults can be overridden by category or item. Inclusive and exclusive pricing, exempt and zero-rated lines, and unseparated legacy sales remain distinct. VAT is calculated after line discounts with integer arithmetic and deterministic line rounding; invoice totals sum those stored lines.

The invoice snapshots the seller and charged financial values. Existing invoices retain their original interpretation after a venue changes tax settings or product prices. Payment-time sales reports and creation-time order history use explicitly labeled date bases, with Persian date inputs translated into inclusive-start, exclusive-end instants around Tehran business days.

CSV and styled XLSX exports cover every matching result, independent of the visible page. Accounting workbooks include invoices, lines, payments, VAT groups, status events, and separately authorized audit data. Exports use batched iteration and a repeatable-read transaction; a private temporary file is completed before delivery. Formula neutralization, explicit toman/rial columns, text identifiers, and Persian-readable dates make the files more useful to downstream operators. These are internal accounting exports, not certified tax-system submissions.

08 — Customer club, discounts, and consent-aware messaging

Customer contact, authenticated identity, and marketing consent are different concepts. A phone entered at checkout may associate a contact with an order; it does not prove ownership of that number or grant promotional consent. Paid orders drive visit, spend, and points updates rather than abandoned carts or uncollected tickets.

The customer-club flow uses verified phone ownership for sensitive membership and reward operations. Reward codes have a lifecycle and transactional redemption rules. Discount eligibility and charged amounts are resolved on the server and recorded with the order so simultaneous redemptions and historical interpretation can be handled consistently.

Campaigns use venue-scoped customer segments and require verified numbers plus consent for promotional sending. Approved SMS patterns, scheduling, provider outcomes, retry handling, and opt-out behavior belong to the messaging workflow. An outbox separates a committed business change from the external delivery attempt, avoiding the assumption that a provider timeout means a message was never accepted.

09 — Tenant isolation and permission boundaries

The permission vocabulary, staff presets, route registry, and dashboard navigation share one policy. Protected pages, APIs, and server actions request the required permission through the server access layer. Queries also constrain the target records to the authorized venue; a hidden control or selected-venue cookie never substitutes for authorization.

Each protected request reloads the current account and checks active status, session validity, current credential version, and current venue access. An owner can delegate only the relevant capabilities to a waiter, kitchen operator, or cashier. Financial export, audit access, order correction, and subscription administration have distinct boundaries.

Guest ordering, table requests, order receipts, and customer proofs use signed, purpose-specific capabilities rather than accepting arbitrary record identifiers. Platform administration uses its own session namespace. The current staff model assigns a staff account to one venue; supporting shared staff across multiple venues would require a membership model rather than stretching that assumption.

10 — Authentication that can recover from SMS downtime

Account access supports phone OTP and password-based sign-in, with recovery flows and session-bound phone linking. Recovery codes are shown privately when established or rotated. Password changes and successful recovery revoke earlier sessions, and sensitive identity changes require the appropriate fresh proof.

Dashboard access uses a short-lived encrypted HttpOnly access cookie plus a separate opaque refresh credential. PostgreSQL retains refresh hashes and session families. Rotation is serialized, overlapping requests receive a limited concurrency grace, and later replay of a spent credential revokes the family. Ordinary session reads do not become an indefinite access extension.

Users can inspect their own active sessions and terminate one device or the other sessions. Revocation is checked by protected requests rather than waiting only for an access cookie to expire. Tokens are not published in session JSON or stored in localStorage. Device descriptions are derived from browser-reported metadata, with trusted-ingress handling for IP information.

11 — Subscription operations with private payment evidence

Subscription periods and commercial settings are database-managed. The owner chooses a period for a specific venue; payment instructions and the commercial terms are snapshotted before receipt submission. The transfer workflow uses manual bank reconciliation and an administrator’s decision rather than claiming that an uploaded image proves payment.

Receipt images are private evidence with authenticated, non-cacheable delivery. Approval locks the relevant records, extends access by the snapshotted period, and records the decision atomically so a retry cannot grant time twice. Administrative adjustments require reasons and concurrency checks, while rejected receipts can be corrected through a linked purchase lineage.

The operational guard evaluates active access at the server boundary. New unpaid venues are unpublished; expiry can preserve read-only public menus while disabling operational writes, and suspension has its own behavior. Renewal and account recovery remain reachable. Admin analytics distinguish confirmed transfers from pending evidence and manual grants rather than presenting those values as invented recurring revenue.

12 — Application architecture and data responsibilities

The application uses Next.js 16.4 and React 19 with TypeScript, Prisma, and PostgreSQL. Server-rendered public pages handle crawlable content; interactive menu, editor, cart, and dashboard components handle local interaction. Zod validates server inputs, Zustand holds scoped client state, and shared domain modules encode money, permissions, dates, menu presentation, QR identity, and order rules.

PostgreSQL is the source of truth for tenants, menus, orders, lines, payments, stock movements, memberships, subscriptions, sessions, and audit records. Transactions and focused locks protect the points where concurrency changes the result. Atomic database rate counters share limits between app replicas without requiring a separate Redis service.

Public media uses persistent storage or optional private S3 behind the application image route. Uploads are signature-checked, decoded in bounded workers, oriented, stripped of metadata, and normalized to WebP with use-specific size limits. Venue-owned upload records establish attachment ownership. Subscription receipt evidence follows a separate private storage and access path.

13 — Installable experiences with honest offline boundaries

Staff and venue menus expose contextual PWA entry points. A staff install opens the role-aware dashboard start route; a venue install carries that venue’s menu identity. Mobile layout work includes Persian typography, right-to-left navigation, readable numbers and dates, responsive operational tables, and accessible touch controls.

The service worker saves an offline shell, versioned static assets, and a bounded set of token-free public menu snapshots. A disconnected guest can read a timestamped saved menu with provisional price and availability. Dashboard HTML, authentication, private receipts, customer data, mutation requests, and active order details are excluded from the offline cache.

Orders, settlement, and status checks still require a connection. Updates wait for the user’s action before activation and reload, helping avoid interrupted forms or checkout. There is no background order replay or claim that a cached staff dashboard reflects current business state.

14 — Public discovery, onboarding, and services

The public site explains the product through an original café composition, feature pages, a practical digital-menu guide, subscription information, tutorials, and contact paths. The services flow connects photography, social content, initial menu setup, migration, and QR handoff to a brief that can be discussed directly.

Marketing SEO and venue-menu SEO have different publication rules. Homepage showcase placement and search indexing require separate administrator approval. Eligible menu metadata and structured data follow visible venue details; private table/token URLs remain non-indexable and point toward the clean menu identity. Empty or unapproved menus are not advertised as public search inventory.

This makes onboarding part of the product rather than an afterthought: an owner can understand the offer, create a venue and menu, establish a consistent presentation, print table cards, and use the same system during service. Optional setup and content services support that adoption path without pretending the software alone supplies a venue’s photography or business information.

15 — Deployment, verification, and operational ownership

The delivery setup packages a standalone Next.js server in a non-root Node 24 Docker image. Deployment applies migrations before serving, retains persistent uploads, and runs the scheduled worker separately. Bundled fonts avoid a build-time font download dependency. Backup jobs and deployment documentation cover database and media recovery responsibilities.

The repository contains domain, integration, HTTP, and browser suites for the critical boundaries: authoritative pricing, tenant denial, concurrent checkout and settlement, QR recovery, stock shortage rollback, session rotation and revocation, OTP abuse limits, VAT, rewards, discounts, private billing evidence, and exports. Browser scenarios also exercise responsive layouts, print workflows, PWA behavior, crawlable metadata, keyboard use, and reduced motion.

These tests use explicitly isolated test databases and simulated messaging for workflows that should not send real SMS. The portfolio captures are visual documentation, not a benchmark result. HTTPS, correct proxy configuration, provider approval, persistent storage permissions, and tested off-host recovery remain deployment responsibilities that source code cannot prove on its own.

16 — What the work demonstrates and where it can grow

MenuJan demonstrates end-to-end ownership of a working hospitality product: the guest interface, staff operations, financial and stock consistency, access control, account recovery, subscription review, and the delivery system behind them. The public menu and operational workspace are connected by explicit rules rather than loosely related screens.

The strongest engineering choices are the ones tied to a concrete operational failure: stable print identity prevents unnecessary reprinting; idempotency handles repeated taps; invoice snapshots protect history; permission checks apply after staff changes; waste stays distinct from a mistaken ticket; and offline menu reading never masquerades as accepted ordering.

Future scaling can follow observed needs: multi-venue staff memberships, permission-scoped asynchronous export jobs for larger datasets, measured polling capacity or an event transport, and a compensating refund ledger. Those are extension points, not features claimed as shipped. This report does not infer customer counts, sales growth, uptime percentages, or measured speed improvements from implementation alone.

A closer look

Captured Oct 23, 2026

menujan.ir/

Homepage 1 / 12

Visit this page

Public pages were captured from the live MenuJan site. Dashboard screens were captured locally with a fictional café and synthetic records; they contain no live customer, staff, or payment data. The product may change after capture.

Working on a similar challenge?

Introduce your idea or current product so we can discuss the work you need.

Discuss your product View services