Connect Infrastructure
Connect is a modern restaurant ordering and operations platform—built in Flutter with a Python + SQL backend—to replace legacy POS workflows with a faster, cleaner mobile experience. Guests can browse, customize, and checkout seamlessly, while staff tools and integrations are designed to scale. The roadmap adds AI-driven forecasting, anomaly detection, and operational insights to keep decisions proactive, not reactive.
Jose Dominguez
Feb. 23, 2026, 9:31 p.m. · Read Time ~ 15 minutes
Guest App
Staff App
Server API
SQL Database
Connect
Guest-first ordering experience built in Flutter, backed by a Python API and SQL data layer. Designed for speed, clarity, and extensibility.
Active surface: Guest App Checkout: Stripe-ready Roadmap: AI + Analytics
Role: CTO / Lead Dev
Status: Active build
Guest Experience KPIs
Flow
Browse → Cart → Pay
Optimized ordering path with minimal steps and predictable navigation.
Reliability
Retry-safe
Clear error UX and safe retries for network and checkout interruptions.
Performance
Mobile-native
Fast rendering, minimal layout shift, and responsive UI patterns.
Extensibility
Role-ready
Architecture supports future role-based screens and telemetry.
root@connect :~ $ run guest_app --demo ✓ Menu load + modifiers✓ Cart pricing + totals~ Payment confirm hooks (webhooks)
Guest App Stack
Client runtime and integration touchpoints.
Mobile Client (Flutter)
Active
Guest ordering experience with clean state patterns and resilient navigation.
Checkout integration points + webhook reconciliation strategy.
Planned assistant for ops prompts, forecasting, and anomaly alerts.
Staff App
Operational tooling: order monitoring, fulfillment visibility, menu updates, and support workflows. (Planned/expanding)
Queue Visibility
Kitchen-ready
Active orders + state transitions with low-latency refresh patterns.
Admin Controls
Menu edits
Update items, prices, availability windows, and modifiers with audit trails.
root@connect :~ $ run staff_app --plan ~ role-based screens~ order queue + fulfillment actions~ reporting exports
Server API (Python)
Domain-driven endpoints for menu, orders, admin actions, and payment reconciliation.
Validation, auth boundaries, idempotent ordering flows, and structured logging.
Webhook Reconciliation
Ready
Provider-confirmed state updates only—prevents ghost-paid orders.
Event Hooks for AI
Design
Emit order events for forecasting/anomaly detection pipelines later.
root@connect :~ $ curl /health && curl /orders/active ✓ ok
SQL Database
Operational source of truth: menu, modifiers, orders, users/roles, and payment references.
Supports OLTP ordering flows + future reporting views without chaos.
Audit + Reporting
Expanding
Prepared for dashboards, exports, and AI training signals later.
root@connect :~ $ select count(*) from orders where created_at > now()-interval '24 hours';
The guest experience is designed for speed: clear menu browsing, consistent modifier selection, and a checkout path that is safe under retries.
Key Screens
Menu browsing (categories, item details, availability)
Modifier selection (sizes, add-ons, substitutions)
Cart review (pricing transparency, totals)
Checkout confirmation + order status
Engineering Controls
Predictable state + navigation patterns
DTO validation and typed payload handling
Graceful offline/network failure UX
Instrumentation-ready (events for analytics/AI later)
Next: role-based UI (guest vs staff), caching for menu data, and stronger telemetry.
API endpoints are organized around the ordering domain: menu entities, order lifecycle, admin actions, and payment confirmation.
Responsibilities
Menu + item endpoints with modifiers and availability windows
Order lifecycle management (create, update, status transitions)
Auth boundaries (roles/permissions for staff/admin)
Audit events for state transitions and reconciliation
Reliability Patterns
Idempotent order creation and safe retries
Webhook verification (signature validation)
Structured logging and consistent error envelopes
Versionable endpoints for client iteration
AI integration point: emit order events into a future inference pipeline (forecasting + anomaly detection).
The database is the operational source of truth—designed for transactional ordering while keeping reporting feasible.
Schema Domains
Menu: categories, items, modifiers, prices, availability
Orders: headers, line items, selections, status history
Users/Roles: staff permissions and admin capabilities
Payments: transaction references, reconciliation fields
Performance + Governance
Indexing for active queues and order lookup
Constraints for referential integrity
Audit timestamps + event logs
Prepared for analytics views/materialized reports
Next: reporting layer for dashboards and AI forecasting inputs.
Payments (Stripe / PayPal)
Close
Payments are treated as first-class events: create intent → confirm → webhook reconcile → mark order paid. This stays safe under retries.
Flow
Server creates payment intent/session
Client completes provider checkout UI
Server verifies webhook + finalizes state
Order updates only on verified provider events
Controls
Signature verification + idempotent handlers
Reconciliation fields for reporting/support
Refund workflow hooks for admin tooling
Error logging + replay capability
Outcome: auditable checkout with fewer edge-case failures.
AI Roadmap (Ops Assistant)
Close
AI is planned as an operator: forecasting, anomaly flags, and staff prompts—explainable, reversible, and logged.
Planned Capabilities
Demand forecasting (daypart + item velocity)
Anomaly detection (spikes, refund patterns, payment fails)
Prep prompts (“what to make more of”)
Operational summaries for managers
Data Inputs
Order events + item trends
Time-series seasonality
Fulfillment durations
Payment outcomes and disputes
Rule: suggestions must have “why” + allow override; store feedback for continuous improvement.
