Choose a guest journey before choosing a combined cart
Observe how a guest chooses counters and collects food today. Decide whether the first product supports separate vendor requests from one shared menu experience, or whether a genuinely combined cart is necessary. A shared screen does not require a single acceptance decision, pickup promise or payment flow. Map the staff action behind each displayed state before estimating the product. Begin with two counters and one complete guest visit; retain an understandable way to finish when only one counter accepts its request.
Use Coffict’s documented mobile work as the reference
The published Coffict case covers Gel-Al order-ahead, rewards through loyalty cards and local café campaigns in a React Native app. Next.js is part of its web stack. The project is recorded in Türkiye and connects recurring customer tasks in one mobile experience. That establishes mobile-product delivery, not a US food hall marketplace. Vendor-specific order records, staff permissions, POS connections, coordinated pickup and payment responsibilities described here belong to the new scope. We do not infer an unpublished backend stack or multi-vendor checkout from the case.
Use a vendor identifier, menu item and selected options together rather than treating the food hall name as the only order context. Two counters can use the same item label or have different availability at the same time. Agree who publishes each menu, how unavailable choices are explained and when a selection stops being editable. Vendor onboarding, menu administration and a source for availability need their own scope. Review a guest switching counters with an unfinished selection, and a menu change before submission.
Model vendor acceptance and partial changes explicitly
Give each vendor request an identity and define what submission, acceptance, requested change and cancellation mean in the operator’s process. If one counter accepts and another cannot prepare an item, show those separate decisions and the guest’s available next step. Do not silently replace an item or treat a notification as acceptance. Decide whether the remaining request can proceed and which person approves a correction. A repeated or interrupted submission should return to the intended request instead of ambiguously creating another order.
Show readiness and collection by counter
A ready drink does not make the meal ready. Agree how staff confirms readiness, what pickup information the guest sees and whether collection is separate for each counter or coordinated through an approved central point. A shared progress view should preserve the individual vendor states. Review the difference between accepted, being prepared, ready and collected with the people running the floor. Keep any estimated time separate from a confirmed state. Kitchen timers, queue displays and staff-device notifications are additional features to scope, not automatic consequences of a mobile interface.
Walk through four counter exceptions before combining orders
Use two fictional vendor menus and sample request IDs for this proposed worksheet. Have an operator and counter staff name the responsible person, authoritative record, guest message and recovery step for each case. Record the rule your team approves before implementing it. Coffict supplies adjacent mobile order-ahead evidence; these multi-counter operating rules are new scope. The worksheet has no answer fields or storage and does not determine payment or refund actions.
Food hall exception worksheet: four proposed guest visits
1. Only one counter accepts
- Ask
- What does the guest see if counter A accepts and counter B cannot prepare its item? Can A's request proceed?
- Evidence to request
- Two vendor request IDs, their separate responses, the approved guest next step and a staff owner for B's unresolved request.
- Tradeoff to record
- One accepted request should not make the whole visit look accepted. Decide whether the guest can continue with A while resolving B.
2. A counter proposes a different item
- Ask
- Who approves the changed selection, and which version will staff prepare if the guest has not responded?
- Evidence to request
- The original and proposed item choices attached to the same vendor request, the guest decision and the staff review owner.
- Tradeoff to record
- A proposed replacement is not an approved selection. An unanswered proposal needs an explicit operating rule, not a silent substitution.
3. One counter is ready first
- Ask
- Can the guest collect from A now, and how are B's pending state and pickup instructions shown?
- Evidence to request
- A's readiness and collection records, B's independent state and the instructions for each pickup point.
- Tradeoff to record
- Collecting from one counter does not close the other request. Keep estimated times distinguishable from confirmed readiness.
4. Submission confirmation is missing
- Ask
- What happens when the guest returns after an interrupted submission and receipt cannot yet be confirmed?
- Evidence to request
- The agreed request identity, any received or accepted record, a clear unresolved state and the person who checks the source record.
- Tradeoff to record
- Check for the intended request before creating another. Missing confirmation does not by itself establish rejection or acceptance.
Keep staff access and integrations within the intended boundary
Decide which orders a counter worker, food hall operator and support role can read or change. A shared administration screen should enforce the approved vendor boundary in backend actions as well as its visual filters. Start with a maintained staff workflow if that satisfies the first release. If a POS or kitchen system owns acceptance or readiness, inspect its documented interface and the permitted actions before estimating a connection. No particular POS integration is claimed by the Coffict case, and none is assumed here.
Scope payment and loyalty responsibilities separately
Identify who owns each sale and the system that confirms any payment, cancellation or refund action. A combined display total does not prove a supported combined checkout. Agree payment-state handoff and failure behavior with the responsible operators and their existing providers before including checkout in scope. Do not infer settlement, processor support or payment compliance from Coffict’s ordering capability. Similarly, a food hall-wide loyalty program needs its own participating-vendor and redemption rules; Coffict’s loyalty cards do not establish a delivered shared reward ledger across independent vendors.
Choose web or native around repeat use
Decide whether the intended first guest journey should open from a food hall link or belong in an installed application. Coffict demonstrates React Native delivery and Next.js in its web stack; it does not establish that every food hall needs a native app. Review menu selection, returning to an order and pickup instructions on the agreed devices. If both web and native clients are included, give them the same agreed vendor and order-state contract. Push notifications, store publication and offline behavior require explicit requirements.
Review one guest visit with two independently confirmed vendor orders
For a new engagement, bring two approved vendor menus, staff responsibilities and the guest pickup procedure. Proposed acceptance examples: each item retains its vendor; one vendor can accept while another requests a change; ready status for one counter does not mark the other ready; and collection records identify the intended vendor order. Include an unavailable counter, an interrupted submission and a staff member assigned to only one vendor. These are proposed food hall checks, not claims about Coffict’s historical multi-vendor routing, staff tools, POS integrations or payment handling.
Work with a US company and an Ankara-led engineering team
Curiosive LLC is a US company, with engineering led from Ankara, Türkiye. Monthly AI-accelerated development starts from $2,000, with scope, capacity and operating responsibilities confirmed in writing. Bring two approved menus, staff roles, acceptance rules and the pickup process that your vendors actually operate. Agree US review windows and a bounded first release. Your team owns menu content, food-service operations and commercial policies; engineers implement the approved interfaces and integrations through reviewed releases.
