NomNom Safe

Screenshots

Overview

NomNom Safe is a collaborative full-stack menu management platform that treats allergen information as safety-critical structured data rather than free-text description. Restaurant staff can manage menu items with explicit allergen attributes; diners can query the menu with confidence that allergen data reflects actual ingredient composition, not editorial notes.

The project was developed collaboratively, and my primary contributions were data modeling, access control architecture, and architectural alignment with IEEE/ISO-inspired standards for traceability.

Problem

Most restaurant menu systems store allergen information as unstructured text — a notes field that says "contains nuts" or "gluten-free option available." This approach has two fundamental problems: the data is not machine-queryable in a reliable way, and it conflates accurate allergen disclosure with marketing language.

For people with severe food allergies, this is not a UX inconvenience — it is a safety issue. NomNom Safe was designed from the premise that allergen data is safety-critical and should be modeled accordingly: as structured attributes with controlled mutation, not free text that anyone can overwrite.

Approach

The data model represents each allergen as an explicit boolean attribute on each menu item, rather than a text field. This makes allergen queries both reliable and simple: "show me all items without peanuts" is a straightforward database filter, not a text search with uncertain results.

Role-based access controls ensure that only users with the appropriate role (menu manager or above) can modify allergen attributes. Ordinary staff can update pricing and descriptions, but allergen data mutations require elevated permission. This mirrors how safety-critical data is handled in regulated industries: controlled access, audit trail, clear ownership.

I refactored the MVP architecture to isolate non-core features (promotional content, special offer logic) from the core allergen management system, reducing coupling and ensuring that changes to peripheral features could not inadvertently affect allergen data integrity.

Tech Stack

Key Decisions & Tradeoffs

Explicit allergen attributes vs. a flexible tagging system. A tagging approach would be more flexible but harder to query reliably and easier to corrupt with inconsistent tag names. Explicit boolean attributes are more rigid but produce unambiguous, machine-readable data. Given the safety context, rigidity was the right call — a false "allergen-free" claim is far more dangerous than a missing custom tag.

Role-based access at the database layer, not just the application layer. Firebase security rules enforce role membership checks before any allergen mutation reaches storage. Application-layer checks can be bypassed by malformed requests; database-layer rules cannot. This defense-in-depth approach ensures data integrity even if the application layer has a bug.

Architectural alignment with IEEE/ISO standards. Documenting requirements and architectural decisions against structured engineering standards added overhead to development but produced a significantly more traceable codebase. Each major architectural choice can be traced to a documented requirement, which would have been valuable in a production context where changes need justification.

What I Learned

• The choice of data model is an architectural decision with long-term consequences. Modeling allergens as structured attributes rather than text required upfront work but eliminated an entire category of data integrity bugs.
• Collaborative development surfaces assumptions that solo development never does. Architecture discussions with teammates revealed implicit assumptions in my mental model that I had to make explicit in the data model and access control design.
• Applying engineering standards documentation to a student project felt like overhead at first. In retrospect, it clarified thinking and produced a codebase that was easier to reason about and extend.