Ali Alshehri
عربيHire me
All projects

Case study · 2026

FitFork

A Riyadh meal-plan kitchen, run from an iPhone app.

Client
FitFork, meal-plan kitchen, Riyadh
Role
Sole developer: design to database
Timeline
About six weeks
Status
Site live · app launching on the App Store
Visit fitfork.store

Meal plans on subscription.

FitFork sells meal plans, not meals. A customer sets goals, picks a package (one or two mains a day, chicken or varied, 20 or 24 days) and lists what they won't eat. Then the kitchen cooks for the month, Saturday to Thursday, and delivers across Riyadh.

The product has four parts: an iPhone app where customers subscribe and manage their plan, a website for people who haven't installed it yet, an admin dashboard where the kitchen runs orders and the menu, and one PostgreSQL database behind all three.

The iPhone app

The welcome screen.

The first screen customers see: get a plan built around their goal, or pick up the one they already have. Language and support sit one tap away in the corner.

  • Get a plan, or continue yours
  • Support one tap away
FitFork iPhone app welcome screen: “Get your own plan”, with meals ready for you, designed for you, delivery included, and buttons to continue your plan or start over

App Store screenshots

The app, screen by screen.

The six screenshots for the App Store listing, in Arabic.

  1. “Your healthy food, your way”: the app's Arabic welcome screen with Start your plan01Start a plan
  2. “Meals that make you hungry”: dishes from FitFork's menu next to the app02The menu
  3. “Your plan, sized to your day”: choosing the meal type and package, chicken only, one meal a day, 20 days03Build the package
  4. “Know what you need each day”: weight, height and age give a daily target of 2,200 calories, 150 g protein, 210 g carbs, 70 g fat04Daily calories and macros
  5. “Your portion, the way you like it”: 150 g protein and 150 g carbs, next to a chicken pesto pasta meal05Choose your portions
  6. “Your subscription at a glance”: the next delivery being prepared and the plan's progress, day 0 of 606Subscription and next delivery

How it's built.

The technical decisions behind the app, the API and the admin.

  1. 01

    The app is the only checkout.

    Accounts, subscriptions and payments live in the iPhone app. The website explains, calculates and links out, and says so plainly.

    Result

    One payment flow to secure, one answer to “is this customer active?”

  2. 02

    Prices have one owner: the API.

    Packages live in the database and come out of GET /plans. The app renders that list; the admin edits it.

    Result

    The app and the admin can never disagree on what a plan costs.

What shipped.

  • 01iPhone app

    Goals and macro targets, packages and portion sizes, exclusions and allergies, checkout, pauses, upcoming meals, progress.

  • 02Website

    Arabic and English, a package picker with per-day prices, the macro calculator, FAQ, privacy, terms and account deletion.

  • 03Admin dashboard

    Customers, orders, products and the menu, and the plan list the app sells from.

  • 04API

    Sign-in, ordering and payments, notifications, and GET /plans.

  • 05Database

    PostgreSQL, through Prisma.

On the screen.

  • FitFork package picker: 999 SAR for two chicken meals a day, 24 days
  • FitFork macro calculator, computed in the browser
  • The FitFork iPhone app section: plans, pauses and progress
  • How FitFork works, in Arabic

Have a product like this in mind?

Packages & pricesWhatsApp