Scope
One job, done properly
Agreed the data contract with EatChoice first: which fields, how often, what happens on conflict.
EatChoice: a POS connector that keeps a dietary-needs dining app accurate.
EatChoice helps diners with allergies and dietary needs find what they can eat. Menus had to come straight from restaurant point-of-sale systems, or the data would go stale.
- Tevalis
- POS integrated
- Scheduled
- menu sync
- Zero
- changes to the app
The problem
Menus and allergen data living in two places, drifting apart.
Restaurants maintain their menus in Tevalis. EatChoice needed that menu and allergen data in its own database, normalised and current, without asking venues to enter anything twice or touching the existing app.
What we built
- Standalone connector service that pulls menus and allergen data from Tevalis
- Normalises items and allergens into EatChoice's model
- Upserts into EatChoice's database on a schedule
- Full local test harness that simulates EatChoice's side
- No changes required to the EatChoice app
Technology
What it runs on.
Node.js / TypeScript
AWS EC2
Knex
MySQL
node-cron
Tevalis POS API
How we worked
A tight integration build, tested end to end before it touched production.
Build
Connector plus harness
Built the service alongside a simulator of EatChoice's database, so every path could be tested locally.
Run
Scheduled and monitored
Deployed to AWS, running on a schedule, with logging so failures surface before venues notice.
Where it is now
Live and syncing.
The connector runs on schedule and keeps menus accurate in the EatChoice app.
View EatChoice on the App StoreNeed two systems to talk to each other, reliably?
Start with a Blueprint: 3 to 5 days, and a plain go or no-go call at the end.