Case Study · 2025

LAMA

Digital Hospitality Platform

AI-Native Full-Stack · Product direction end to end

01 — Product Story

Case study
Full-stack product
Hospitality platform
Not a launched SaaS

What if a digital menu could be more than a copy of paper?

LAMA started with a simple question about digital menus — and evolved into a broader digital hospitality platform.

The core idea became a platform connecting food-service businesses with a modern, interactive customer experience: from discovering the menu to ordering and payment. Earlier versions were used by approximately 2–3 real customers — useful signal, not product-market fit.

02 — The Shift

It started with a menu. It didn't stay a menu.

The product moved from static information toward a digital experience, then toward a transactional one.

01
Static information
QR codes, PDFs, and static menus that only mirrored paper.
02
Digital experience
Interactive menus, branded mini websites, themes, and multilingual experiences.
03
Transactional experience
Ordering foundations and payment architecture designed for correctness.

03 — The Product

Two sides. One platform.

LAMA serves the business that configures the experience and the customer who moves through it.

Business side

Operational and brand control for food-service businesses across branches and menus.

Branches
Menus
Products
Visual identity
Configuration

Customer side

A guest-facing path from discovery to payment, shaped by each business identity.

Discover
Explore
Order
Pay

04 — Multi-tenancy

One platform. Different identities.

Tenant and business form the primary boundary.

The same underlying system can power independent businesses — each with its own identity, themes, and configuration — while resolving public and authenticated requests through tenant context.

LAMA multi-tenant business configuration

01 · Identity A

Shared platform. Independent brand surface.

02 · Identity B

Same system. Different visual language.

03 · Identity C

Configured experience, not a separate product.

05 — Under the Surface

Simple on the surface. Deliberate underneath.

Public and admin flows resolve tenant context first, then authorize, then execute business logic.

Tenant boundaries
Business is the primary isolation unit for both public and admin paths.
Permissions
Role-based access shapes what owners, admins, menu managers, and waiters can do.
Branch access
Operations can be constrained to the branches a role is allowed to touch.
API-driven architecture
Client experiences consume a deliberate API surface rather than ad-hoc page logic.

01
Request
Public host/subdomain or authenticated admin entry.
02
Tenant Resolution
Business/tenant context becomes the primary boundary.
03
Authorization
Membership, roles, and branch-level access are validated.
04
Business Logic
Menus, ordering, payments, and configuration operate inside that boundary.
05
Database
Persistence stays scoped to the resolved tenant world.

06 — Branding as Infrastructure

Branding isn't a layer on top. It's part of the system.

Theme and palette configuration feed a loader that maps into CSS variables — and then into a branded UI.

The same platform renders different businesses with different visual identities without forking the product.

01Menu

02Theme

03Palette

04CSS Variables

05Rendered Experience

Same system. Multiple outcomes.

Warm hospitality

Quiet modern

Bold local

07 — Localization

Localization changes more than language.

Persian/RTL and English/LTR affect layout, typography, direction, navigation, spacing, and component behavior.

RTL layout
Typography
Direction
Spacing
Navigation
Component behavior

English

Left-to-right reading flow and spacing.

LTR

Persian

Right-to-left structure and typographic behavior.

RTL

08 — From Cart to Payment

The moment a menu becomes a product.

Browse leads to cart, cart becomes order, and payment architecture sits on top of that transition.

Cash and online payment concepts exist in the backend. Online provider integration remains a stub — not a production gateway claim.

Browse
Cart
Order
Payment

Cart → order transition
Editing and submission give way to an explicit order conversion.
Capability-based access
Actions depend on what the current context is allowed to do.
Idempotency
Conversion and payment operations are designed to stay correct under retries.
Allocation-based payment
Partial payment behavior is modeled through allocation-based amount calculation — not participant bill splitting.

09 — Engineering Decisions

Judgment, not just features.

A few decisions that reveal how the system was shaped.

Explicit tenant context

Problem: Public and admin requests can arrive through different entry points.
Decision: Resolve tenant context before authorization and business logic.
Why: Boundaries stay clear when every meaningful path starts from the same conceptual sequence.

Separating Cart from Order

Problem: Editable shopping intent and committed purchases behave differently.
Decision: Keep cart and order as distinct stages with an explicit transition.
Why: Conversion, capability checks, and idempotent behavior become easier to reason about.

Server-side authorization

Problem: UI restrictions alone cannot protect tenant and branch boundaries.
Decision: Validate membership, roles, and branch access on the server.
Why: Permissions remain trustworthy even when clients are wrong or incomplete.

Idempotent payment operations

Problem: Retries, concurrency, and partial payment make money flows fragile.
Decision: Design payment handling around idempotency, allocation, state, and verification.
Why: Correctness matters more than pretending the provider integration is finished.

10 — Building with AI

AI accelerated the build. Judgment stayed human.

AI was part of the development workflow as an engineering multiplier — not the engineer.

Decisions, validation, and verification remained human responsibilities throughout the loop.

01Define
02Ask
03Challenge
04Implement
05Test
06Verify
07Refine

11 — What LAMA Changed

LAMA changed how I think about building software.

The work shifted attention from isolated screens toward the systems that make a product coherent.

ScreensInteractionsProduct behaviorSystemsArchitecture

I stopped thinking only about features — and started thinking about products.

12 — Current State

Transparent about where it stands.

LAMA is a serious case study project — not a launched, production-hardened SaaS.

Built

Core platform architecture
Multi-tenancy
Dashboard
Public menu
Themes
Ordering foundation
Payment architecture
Testing foundation

Incomplete / in progress

Online payment provider integration
Some operational flows
Production hardening

Direction

A broader digital hospitality platform for food-service businesses.

LAMA was never just about building a menu.

It was about learning how to build the system behind the experience.

What if a digital menu could be more than a copy of paper?

LAMA started with a simple question about digital menus — and evolved into a broader digital hospitality platform.

Simple on the surface. Deliberate underneath.

Public and admin flows resolve tenant context first, then authorize, then execute business logic.

Tenant boundaries

Business is the primary isolation unit for both public and admin paths.

Permissions

Role-based access shapes what owners, admins, menu managers, and waiters can do.

Branch access

Operations can be constrained to the branches a role is allowed to touch.

API-driven architecture

Client experiences consume a deliberate API surface rather than ad-hoc page logic.

The moment a menu becomes a product.

Browse leads to cart, cart becomes order, and payment architecture sits on top of that transition.

Cash and online payment concepts exist in the backend. Online provider integration remains a stub — not a production gateway claim.

Browse

Cart

Order

Payment

Cart → order transition

Editing and submission give way to an explicit order conversion.

Capability-based access

Actions depend on what the current context is allowed to do.

Idempotency

Conversion and payment operations are designed to stay correct under retries.

Allocation-based payment

Partial payment behavior is modeled through allocation-based amount calculation — not participant bill splitting.

LAMA

What if a digital menu could be more than a copy of paper?

It started with a menu. It didn't stay a menu.

Static information

Digital experience

Transactional experience