Mobile App 2022

Mealbox

Corporate meal ordering platform on Android and iOS, built at Prima IT Consulting.

Employee-facing Flutter app for a corporate meal ordering platform, backed by a GraphQL gateway I also built on NestJS and MongoDB.

#flutter#graphql#nestjs#mongodb#offline-cache#b2b

Mealbox is a corporate meal ordering platform for Android and iOS, built during my time at Prima IT Consulting. Employees sign in against their company, browse the day's menu by course, add items to a cart and manage their profile.

I worked both sides of the GraphQL gateway: schema and resolver work on a NestJS service backed by MongoDB through Mongoose, and the Flutter client that consumes it. Token-based sign-in, company search by name or device location, and menu queries served through Hive on a cache-and-network policy.

Key Features

Company sign-in

Token-based authentication scoped to the employee's company, so each user only ever sees their own organisation's menus and pricing.

Menu browsing by course

The daily menu is structured by course, letting employees build a complete order rather than picking single items from a flat list.

Company search

Employees find their organisation either by name or by device location, which removes the need to distribute per-company codes.

Cart and profile

Order assembly and profile management on the client, with order state held locally until submission.

Tech Stack

FlutterDartProviderGraphQLNestJSMongoDBMongooseHive

Architecture

The client talks to a single GraphQL gateway rather than a set of REST endpoints, so the app requests exactly the fields a screen needs instead of over-fetching a fixed payload. The gateway is a NestJS service; persistence is MongoDB accessed through Mongoose.

Menu queries run on a cache-and-network policy backed by Hive: the cached menu renders immediately while the network request resolves in the background. The app opens with yesterday's menu already on screen instead of a spinner, then reconciles.

Challenges & Solutions

The hard problems, and how I solved them.

Opening on a menu instead of a spinner

Menus change daily but the app is opened at predictable times, usually on a corporate network under load. Fetching on every launch meant a visible wait for content that was usually only a few hours stale. Serving from a Hive cache first and reconciling against the network afterwards made the first frame useful, at the cost of briefly showing a menu that may have changed.

Scoping every query to the right company

A single deployment serves multiple companies, so the wrong scope leaks one client's menu and pricing to another. Scoping was enforced at the gateway against the token rather than being passed as a client argument, so the client cannot ask for data outside its own organisation.

More Projects

Interested in working together?

I'm always open to discussing new projects and opportunities.

Get In Touch View All Projects