A product card must map to a real product.
SKU/barcode/catalog identity, culturally specific names, pricing, availability and shelf context matter. A pretty storefront that cannot reconcile to the store creates more work rather than less.
Layer 04 · Commerce · merchant execution
My Accra connects the customer screen to the real shelf and the real staff workflow.
My Accra International Market is the field-pressure layer in the IZZYAKOS system. The software has to deal with what a neighborhood grocery actually faces: customer search, culturally specific products, stock uncertainty, pickup promises, loyalty, receiving, shelf/aisle identity, staff roles, owner controls and payment truth. That makes it a practical test of whether the company’s evidence-and-workflow discipline survives outside a clean prototype.
Real merchant use caseCustomer + admin routesMobile operations stabilizationProduction activation gates remain
The merchant problem
An online storefront is useful only if it agrees with the physical store.
For a small grocery, the hardest problems are often the handoffs: customer intent to inventory, receiving to shelf, reservation to pickup and staff action to owner visibility.
A checkout cannot claim success when the service is not active.
The current release explicitly moved toward truthful pickup/payment behavior: fail closed or provide a real fallback instead of showing a fake paid/order-complete state.
On-hand, reserved and available are not the same number.
Inventory and order workflows need to preserve what is physically present, what is committed to a customer and what can still be sold.
Customer journey
Store discovery → product decision → account/cart → pickup and follow-up.
The repository contains a broader customer surface than the old IZZYAKOS summary implied, including account, loyalty, regional recipe/community content and mobile navigation work.
Find the store and understand the offer
Home/About, store contact, location/directions, mobile call/contact paths and category navigation give customers enough context to decide whether the store can meet the need.
Browse/search culturally specific products
Customers can move through categories and product information rather than relying on a generic one-page catalog. Search and product identity are part of the operational model, not decoration.
Use account and loyalty
The codebase includes account behavior and loyalty enrollment with birthday month/day and reward progress. The customer identity layer is therefore more than a simple cart session.
Use recipes/community as commerce context
Regional African/Caribbean recipe filters, downloads and community/Recipe Challenge paths help a customer understand how products are used and create a legitimate merchandising/education bridge.
Build cart / pickup intent
The customer chooses products and pickup behavior. The system must distinguish a reservation or intent state from an actually captured payment or confirmed fulfillment.
Receive truthful status and contact fallback
If backend/payment services are not active, the UI should not simulate success. Real store contact channels and operational fallbacks remain available so the customer is not trapped by the application.
Store operations
Inventory → receiving → aisle/location → scan/pick → order operations.
The repository contains dedicated admin routes for inventory, receiving, aisles, suppliers, scan-pick, orders, promotions, campaigns and role-based access concepts. This is substantially more than a storefront prototype.
Know what exists and what is available.
The operations model is designed to distinguish product identity and stock state so customer availability and staff actions can reconcile to the same record.
Move supplier deliveries into controlled stock state.
Receiving has a dedicated admin surface rather than being treated as a manual spreadsheet afterthought. Supplier/product identity and quantities must survive the handoff into inventory.
Connect digital products to physical locations.
Aisle/location administration supports the shelf-QR/barcode operating idea: a product should be findable by staff and ultimately by a mapped store workflow.
Use barcode identity during fulfillment.
The scan-pick route creates the operating bridge from an order or task to the exact physical product rather than relying only on product names.
Track fulfillment state rather than a single “order” object.
Owner/staff operations need to know what has been requested, reserved, picked, ready and completed. Payment capture and production webhook state must stay distinguishable from demo logic.
Merchandising sits on top of inventory truth.
Promotion and campaign surfaces exist, but they should not promise stock or discounts the underlying product/order state cannot support.
Authority and owner control
The store should not have one universal “admin.”
The architecture includes owner/admin login and RBAC concepts because receiving, picking, cashiering, management and owner decisions have different authority boundaries.
Business-level control
Owner access should see operational state and sensitive configuration without making every staff user an owner-equivalent administrator.
Do the job-specific action.
Receiver, picker, cashier and manager actions should be scoped to the workflow the person is responsible for. The model is aimed at least-privilege operations rather than shared passwords.
Know which role changed the state.
Role and audit concepts matter because stock, orders, pricing and receiving disputes cannot be resolved reliably if every action appears to come from the same generic admin identity.
Current truth boundary
The field case is real; the activation gates are real too.
The latest main-branch release explicitly describes mobile operations stabilization and truthful pickup checkout. That is a stronger engineering position than the old company page showed, but production backend and payment claims still require acceptance.
AreaCurrent evidenceRemaining gate
Customer surfaceHome/catalog/account/loyalty/recipes/community and pickup-oriented customer routes exist with mobile stabilization work.Real catalog completeness, live customer acceptance and production service monitoring.
OperationsInventory, receiving, aisles, suppliers, scan-pick, orders, promotions/campaigns and RBAC/admin routes exist.Production backend linkage, staff identity/RBAC acceptance and physical shelf/catalog validation.
PaymentsThe release is designed to avoid fake paid/order-success behavior when services are unavailable.Verified production payment provider/webhook configuration and live checkout acceptance.
Field validationA real merchant use case drives the workflow and product design.The full system should not be called “fully live retail SaaS” until store-side customer/staff acceptance and production integrations are complete.