Skip to content
Tim Borja
Apps

Campus Food-Ordering Platform

Four native apps, two web portals and a full serverless backend, live on the App Store and Google Play

Timothy Maersk M. Borja

App Store ↗Google Play ↗In production
campuses in production
9
campuses in production
orders processed
15,000+
orders processed
merchants onboarded
219
merchants onboarded
Platforms
iOS · Android · Web
Since
2022
Food & Drink

Preview

Live order tracking
Rider job offers
Merchant order queue

Drawn screens use made-up sample data. The client's and clinics' real data never appears on this site.

Architecture

Clients

Customer

Flutter · iOS/Android

Rider

Flutter · iOS/Android

Merchant

Flutter · mobile + web

Admin

web · internal iOS

API & identity

API Gateway

REST

AppSync

GraphQL · real-time

Cognito + IAM

custom auth challenges

Services

AWS Lambda · Node.js

dozens of services: payments, orders, dispatch, ads, messaging, identity

Data & events

DynamoDB

GSIs · conditional writes

EventBridge

schedules · sweeps

Step Functions

SNS · SQS · SES

S3 · CloudWatch

storage · alerts

External

Stripe Connect

+ 2 meal-plan processors

Twilio · FCM

masked calls · push

Google Maps

tiered cache

Slack

alerts

A campus marketplace connecting customers, merchants and riders, covering discovery, split-tender checkout, dispatch, live tracking and settlement, plus an internal admin layer for onboarding, financial policy and oversight. I designed, built, released and operate every part of it.

The system

A campus marketplace with four products:

  • Customer app (iOS, Android): discovery and maps, cart, promotions, split-tender checkout, live tracking, chat and rewards.
  • Rider app (iOS, Android): job offers with accept-rate scoring, navigation, proof of delivery, masked calling and earnings.
  • Merchant app and portal (iOS, Android, web): order queue, menu and inventory, hours, promotions, store ads and payouts.
  • Admin portal (web, internal iOS): vendor onboarding, financial policy, delivery oversight, rider suspension, ads and analytics.

The backend is the largest part of the project and entirely mine: I designed the data model, wrote every service, and run them in production on AWS Lambda behind API Gateway and AppSync GraphQL.

Selected engineering

  • Split-tender correctness. One checkout can draw on a meal plan, declining balance and a card. Fees are summed in integer cents, so the processor, the ledger and reconciliation agree to the penny.
  • A double-charge from retries. Retries were regenerating the idempotency key, which caused a double-charge in production. I traced and eliminated it.
  • Two riders, one order, the wrong card. Simultaneous rider deposits let a penalty hit the wrong card. A conditional-write lock now allows one hold per order, penalties charge only the cancelling rider, and suspension is enforced server-side on every clock-in, deposit and accept.
  • Server-driven checkout. Per-merchant policy decides what checkout shows: tax, tips, meal-plan coverage and second-tender rules. Missing settings default to enabled, so merchants need no migration and pricing stays on the server.
  • Live tracking on unreliable Wi-Fi. Subscription sockets could stay open but silent. A watchdog repairs them, and polling and push fallbacks keep tracking live.
  • Cloud cost. A tiered DynamoDB cache holds geocodes for 30 days and routes for 6 hours, inside Google’s caching terms. A spike of about 4 million promotion reads a day was traced to an app loop and fixed server-side.

Shipping safely

Releases go out roughly weekly. Unreleased features sit behind release locks that fail closed: a global setting, an environment allow-list and a per-campus switch, so a feature stays off unless every one says on. Stripe dispute handling (67 unit tests) and server-side rider auto-accept (38 unit tests) are built this way and piloting before launch.

An audit log of who changed which account or setting used to full-scan a ~64k-item table. It now reads from a sparse DynamoDB index that holds only audit-worthy rows.

About this page

The apps are live on the App Store and Google Play. The client’s code is private, so this page describes the system rather than linking to source. The full write-up is in the technical portfolio PDF.