What Is Ricoya?
Ricoya is a food delivery platform built specifically for the Bay Islands of Honduras — Roatán, Utila, and Guanaja. It connects hungry customers with local restaurants, handles the entire ordering process, and coordinates delivery drivers to bring food to people's doors.
Think of it as a DoorDash or Uber Eats, but purpose-built for a small island community where the existing global platforms don't operate. Customers browse restaurant menus on the web, place orders, and choose between delivery or pickup. Restaurant managers receive those orders instantly on their phones and start preparing the food. Drivers pick it up and deliver it.
Payments are flexible: customers can pay online via PayPal, pay cash on delivery, or (coming soon) pay by credit/debit card through CyberSource. The platform is live and serving real orders at ricoya.net.
Who Uses It & Why
Customers
Residents and tourists on the Bay Islands who want food delivered or ready for pickup. They browse restaurants, build their cart, place orders, and track delivery status — all from a web browser on any device. No app install required.
Restaurant Managers
Restaurant owners and staff who receive incoming orders, confirm preparation times, and mark orders as ready. They use a dedicated Flutter mobile app (iOS and Android) that sends push notifications the moment a new order arrives, plus a web-based manager console for detailed order management.
Delivery Drivers
Local drivers who are assigned deliveries by the platform. They see pickup locations (the restaurant) and drop-off locations (the customer), navigate between the two, and mark deliveries as complete. The driver experience is integrated into the platform interface.
Platform Administrators
The team managing Ricoya itself. Admins onboard new restaurants, manage menu items and pricing, handle disputes, monitor order flow, and configure platform settings like delivery zones, fees, and payment methods.
How An Order Works
Here is the complete journey of an order, from the moment a customer opens the site to the food arriving at their door.
1
Customer browses restaurants
The customer visits ricoya.net, selects their location on the Bay Islands, and browses available restaurants. Each restaurant shows its menu, prices, ratings, and estimated delivery time.
↓
2
Customer builds cart and places order
They add items to their cart, choose delivery or pickup, and select a payment method: PayPal, cash on delivery, or card (coming soon). They confirm their delivery address and submit the order.
↓
3
Order hits the database and triggers notifications
The order is saved to the Supabase PostgreSQL database. The server immediately sends a push notification to the restaurant manager's phone via APNs (iOS) or FCM (Android). The manager app plays an alert sound.
↓
4
Restaurant manager accepts the order
The manager opens their app or the web console, reviews the order details, and accepts it. They can set a preparation time estimate so the customer knows when to expect their food.
↓
5
Driver is assigned
For delivery orders, a driver is assigned to the order. They receive the restaurant's address for pickup and the customer's address for drop-off.
↓
6
Food is prepared and picked up
The restaurant prepares the food and marks it as ready. The driver picks up the order from the restaurant. For pickup orders, the customer is notified that their food is ready to collect.
↓
7
Delivery and completion
The driver delivers the food to the customer's address. If paying cash, the driver collects payment. The order is marked as completed. Both the customer and the restaurant can see the final order status.
Main Components
Ricoya is made up of five main pieces that work together. Each one has a distinct job.
Customer Web App
The public-facing website at ricoya.net. Built with Next.js, it handles everything customers interact with: browsing restaurants, building carts, placing orders, managing accounts, and tracking delivery status. Works on any device with a browser — no install needed.
Manager Mobile App
A Flutter app for restaurant managers on iOS (via TestFlight) and Android (via direct APK download from images.ricoya.net). Receives push notifications for new orders, lets managers accept/reject orders, set prep times, and mark orders ready. Also includes a web console for more detailed management.
Server & API
The Next.js backend runs as a Node.js process managed by PM2 behind an nginx reverse proxy. It serves the web app, handles API requests (order creation, payments, auth), sends push notifications to APNs and FCM, and manages Twilio SMS/WhatsApp for OTP phone verification.
Database & Auth
Supabase provides the PostgreSQL database for all data (users, restaurants, orders, menus), authentication (email/password and phone OTP), row-level security policies, real-time subscriptions for live order updates, and file storage for images.
Notifications & Messaging
Push notifications reach restaurant managers instantly when orders come in. iOS notifications go through Apple's APNs using a server-side .p8 key. Android notifications go through Firebase Cloud Messaging (FCM). SMS and WhatsApp OTP messages are sent via Twilio for phone number verification.
Image & Asset Storage
Restaurant photos, menu item images, and downloadable APK files are stored on Cloudflare R2 and served through images.ricoya.net. This keeps large binary assets off the main server and delivers them quickly via Cloudflare's global CDN.
Technology Stack
| Technology |
What It Does |
Category |
| Next.js 16 (App Router) |
Full-stack web framework — renders the customer site, serves the API, handles server-side logic |
Frontend + Backend |
| Supabase |
PostgreSQL database, user authentication, row-level security, real-time subscriptions, file storage |
Database + Auth |
| Flutter |
Cross-platform framework for the restaurant manager mobile app (iOS + Android from one codebase) |
Mobile App |
| PayPal SDK |
Online payment processing — the primary live payment method for customers |
Payments |
| CyberSource |
Credit/debit card payment processing (integration in progress, not yet live) |
Payments (coming) |
| APNs + FCM |
Push notifications to iOS (Apple Push Notification service) and Android (Firebase Cloud Messaging) |
Notifications |
| Twilio |
SMS and WhatsApp messaging for OTP phone verification during signup/login |
Messaging |
| PM2 |
Node.js process manager — keeps the Next.js server running, handles restarts and logs |
Operations |
| nginx |
Reverse proxy — routes incoming HTTPS traffic to the correct PM2 process (staging vs. production) |
Operations |
| Cloudflare R2 |
Object storage for images and APK files, served via CDN at images.ricoya.net |
Storage |
Infrastructure
Both staging and production run on the same physical server but as separate PM2 processes with their own ports and environment files. The codebase is identical — the only difference is the .env.local file on each deployment, which points to a different Supabase project.
Environments
| Environment |
Domain |
Server Path |
PM2 Process |
Port |
| Staging |
staging.ricoya.net |
/opt/ricoya |
ricoya |
3000 |
| Production |
ricoya.net |
/opt/ricoya-live |
ricoya-live |
3001 |
Databases
| Environment |
Supabase Project |
Account |
| Dev / Staging |
elopzpfftytxncfyutju |
sean@omelasai.com |
| Production |
vxabwjsddplhnpqtnuef |
admin@ricoya.net |
Hosting
| Service |
Provider |
Details |
| Application server |
OVH (OVH3) |
15.204.11.95 — runs both staging and production via nginx |
| Database + Auth |
Supabase (hosted) |
Two separate projects, one per environment |
| Images + APKs |
Cloudflare R2 |
Bucket: ricoya-images, served at images.ricoya.net |
| DNS + CDN |
Cloudflare |
Proxied DNS for all ricoya.net subdomains |
Same codebase, different config
Deploying changes affects both environments because they share the same code. The only per-environment difference is the .env.local file, which sets the Supabase URL, API keys, and feature flags like NEXT_PUBLIC_CARD_PAYMENTS_ENABLED. Schema changes (new columns, RPC functions, RLS policies) must be applied to both Supabase projects separately.
Architecture Diagram
How the pieces connect. Customers interact with the web app, which talks to the Next.js server. The server coordinates everything: database queries, payment processing, and push notifications. Restaurant managers receive orders on their Flutter app, and drivers are assigned deliveries through the platform.
🌐
Customer Web App
Next.js • ricoya.net
📱
Manager App
Flutter • iOS + Android
🚚
Driver Interface
Web-based
↓
HTTPS requests + WebSocket
↓
→
⚡
Next.js Server
PM2 • API + SSR
🗄
Supabase
PostgreSQL + Auth + Realtime
💾
Cloudflare R2
Images + APKs
🔔
APNs + FCM
Push notifications
💬
Twilio
SMS + WhatsApp OTP
💳
PayPal
Online payments (live)
💳
CyberSource
Card payments (coming soon)
Detailed Documentation (Tier 2)
-
Database Schema & RLS Policies
— Tables, enums, indexes, row-level security, and Supabase RPC functions
-
API Routes
— All server-side endpoints, request/response formats, authentication requirements
-
Payment Integration
— PayPal flow, CyberSource integration, cash on delivery handling
-
Push Notifications
— APNs .p8 key setup, FCM configuration, notification channels, sound files
-
Manager Mobile App
— Flutter architecture, build process, TestFlight/APK distribution, app versioning
-
Authentication & Verification
— Supabase Auth, phone OTP via Twilio, session management, middleware
-
Deployment & Operations
— Deploy scripts, PM2 processes, nginx config, environment management