Frie
Diners get food recommendations and diet plans inside a social delivery app
Frie is an Uber Eats style app that joins social food discovery with ordering and delivery, plus a driver app. We built the back end and apps, kept scope visible while designs changed, and added machine learning for dish recommendations and diet plans.
Real Estate & HospitalitySocial food ordering appsBuilt from zero
The challenge
Frie needed a social network for food and a full ordering service to work as one product, while its designs kept changing between versions.
What we did
We built one documented API for the customer and driver apps, added recommendations and diet plans, and compared every changed screen to keep scope visible.
The outcome
Frie received a working back end, an Android app with full ordering and a driver app, with a written status for every feature.
- What shipped
- Django back end, Android customer app, driver app
- For diners
- Dish recommendations and personal diet plans
- Social and ordering
- Food albums, feeds, reviews, recurring orders, rewards
- Scope control
- Screen by screen design change reports
The starting point
Frie is a U.S. food app startup. Its product joins a social network for food lovers with restaurant delivery and pickup, plus a driver app that fulfills orders.
What had to change
Social discovery and ordering had to work as one product, with one back end serving the customer apps and the driver app. Frie's designers produced the screens and kept refining them.
What could not break
- Designs kept changing between Zeplin and Figma versions, with no change notices
- Android, iOS and driver apps all run on one back end and one API
- Social features and ordering share one diner account and profile
The calls we made
We treated changing designs as a scope problem to make visible, not a reason to stop building.
- 01
Separate tracks on one API
We split the work into a Django back end, native Android and iOS customer apps and a driver app, so each track could move in sprints against one documented API.
- 02
Compare every design version
When designs changed, we compared each screen across Zeplin and Figma versions and documented the differences, and listed flows that still had no design, so Frie could see what a change meant for scope.
- 03
Estimate the driver app in full
We made a new, more complete estimate for the driver app and compared it with an earlier, shorter one before setting its timeline.
Ruled outCarrying over a previous developer's shorter estimate.
- 04
A written status by feature
We kept a feature list marking each item as complete, in progress or pending, so the founder always knew what was ready.
How the system fits together
What we built
Food recommendations
Machine learning recommends dishes to each diner inside the app, next to search, dietary filters and friends' food albums.
Diet plans
Diners get diet plans built into the same app they order from, so what they plan and what they order stay in one place.
Social and ordering back end
Profiles with privacy levels, follow and block, reporting, bookmarks, search with filters, restaurant profiles, events, food albums, a filtered news feed, reviews, one time and recurring orders, promo codes, card payment, rewards and dietary data, with Redis caching on the home screen.
Android customer app
Search and filters, bookmarks, album details, restaurant feeds and profiles, full order placement with new addresses and payment methods, followers, and review posting and reporting.
How it works
Discover
A diner browses friends' food albums, restaurant feeds and reviews, or searches with dietary filters.
Order
The diner places a delivery or pickup order, one time or recurring, with a promo code if they have one.
Pay
The order is paid by card and earns rewards.
Deliver
A driver in the matching delivery area picks up the order in the driver app.
What changed
Frie received a working back end, an Android customer app with full ordering and a driver app, with a clear list of what was complete and what was still to come. Design changes were documented screen by screen instead of surfacing as surprises.
Under the hood
- Datics role
- Product built by Datics
- Back end
- Django REST API documented in Swagger, with Celery job queues on RabbitMQ and Redis caching.
- Deployment
- Django behind Gunicorn on an Ubuntu server, deployed by pulling the latest commit and restarting.
- Integrations
- Card payments and Google Maps, with Twilio SMS planned for order confirmations and password resets.
Data and retrieval
Apps and APIs
Also in the stack
How it shipped
Data science first
Before the app build, we worked with the same founder on machine learning scoring and recommendation systems.
Back end and Android
We built the Django back end and the Android customer app first, from profiles and food albums to full order placement.
iOS and driver app
An iOS team joined on the same API, and we estimated and started the driver app for sign up, profiles, delivery areas and activities.
Design changes and depth
We compared the new Figma screens with the Zeplin versions, then added recurring orders, Google Maps and home screen caching.
Documents
We wrote architecture, API and deployment documents, with Swagger API docs, for whoever runs the system next.
Sprints in Redmine
Every task was tracked in sprints in Redmine, with a feature by feature status the founder could review at any time.
Documents for the next owner
We handed over architecture, API and deployment documents, with Swagger API docs, so whoever runs the system next can pick it up.
What this unlocked
Group orders, reservations, SMS notifications, gift cards and wallet payments were the next items on the feature list.
Related work
Have a product with the same kind of constraints?
Tell us what already exists and what you want it to do. We will tell you what it takes.