Lumi

Lumi is designed for restaurants, cafés, and their customers, especially small and medium-sized businesses that want to improve their service without investing in expensive digital infrastructure. In many restaurants, customers still depend on waiters for almost everything, from viewing the menu and asking about ingredients to getting recommendations and placing orders. During busy hours, this creates unnecessary waiting, puts pressure on staff, and increases the chances of miscommunication. Customers with dietary restrictions may struggle to get clear information, while those unfamiliar with the menu often have to make decisions without proper guidance. For restaurant owners, the challenge is not simply taking orders faster. It is providing consistent, personalized service while managing limited staff, operational costs, and customer expectations. Existing digital menus often solve only one part of this problem: they display food items but rarely help customers make informed choices. We saw an opportunity to make restaurant service more accessible, interactive, and efficient without requiring a screen at every table or completely changing how restaurants operate. The goal is to give smaller restaurants access to the kind of intelligent digital experience that is often associated with much larger businesses.

Preliminary score

61.5/ 100Promisingaverage of 2 judges
  • Value for the user16.5 / 25

    A specific problem and a clear outcome from solving it.

  • Prototype and use of AI20.5 / 30

    A working core scenario, and what AI actually contributes to the result.

  • Quality testing9.5 / 20

    Tests, examples of failures, and comparison with the current approach.

  • Feasibility10.0 / 15

    Data requirements, running costs and a clear next step.

  • Originality5.0 / 10

    A meaningful difference from common solutions.

What the judges wrote

  • Claude Opus 5.5Preliminary62/100
    Strengths
    Your architecture is well thought through: the LLM only handles menu import, constraint extraction and short explanations, while deterministic code handles prices, totals, allergens, availability and ETA, so the AI cannot invent dishes or prices. Treating unknown allergen data as unsafe and chaining Gemini, then Groq, then a rule-based fallback shows real attention to reliability. Your end-to-end flow (setup wizard, AZ/EN/RU guest chat, order, kitchen ticket with ETA, status back to the guest) is concrete and has a combined /demo view. Your README is unusually honest about known limits.
    To improve
    Your testing covers deterministic logic, but you note there is no evaluation of LLM quality yet. Build a small labelled set of multilingual guest requests (allergies, budgets, Azerbaijani phrasing) and report extraction accuracy and failure cases. The submission says 44 tests while the README says 21, so publish TEST_RESULTS.md and reconcile the numbers. Your adoption metrics (waiter time per order, order errors) are well chosen but unmeasured; even a timed mock comparison against a waiter taking orders by hand would strengthen both value and testing.
  • GPT-6 AstraPreliminary61/100
    Strengths
    Your guest-to-kitchen workflow targets a concrete staffing problem and names useful adoption metrics without claiming unmeasured savings. Your documented architecture uses AI for menu import and multilingual constraint extraction while keeping prices, availability, and order validation deterministic. Treating unknown allergen data as unsafe and providing a rule-based fallback are thoughtful safeguards.
    To improve
    Provide actual test outputs and reconcile the submission's 44 passing tests with the README's 21 deterministic tests. Add Azerbaijani, English, and Russian evaluations of constraint extraction—especially missed allergies and conflicting requirements—alongside reproducible failures and an end-to-end order trace. In your café pilot, compare waiter time and order errors with the current process and validate ETA accuracy. Before deployment, replace ephemeral JSON storage, add authentication, and estimate per-order operating costs beyond free tiers.

The team

  • Teymur Cəfərov

    developer

  • İsmət MəmmədovLead

    product