Insilicoffee

Role

Designed and built the customer and barista React PWAs and their Strapi API: orders reach the bar live over server-sent events, and the brewing parameters come from the model built by its ML developers.

In numbers

apps: customer, barista and CMS

3

weeks for all three

6

API routes, three streaming live

25+

Problem

Turn a coffee’s taste, or its chemistry, into a drink: customers order from their phones, baristas work a live queue, and a machine-learning model proposes the brewing parameters.

Constraints

• The model comes from the team’s ML developers, as a separate Flask service
• Orders have to reach the bar the moment they are placed

Decisions

• Three apps on one Strapi API: a phone app for customers, a tablet app for baristas, and the CMS.

  Each role gets a screen shaped for its device and its job: ordering on the phone for customers, a high-contrast live queue on a tablet for baristas, Strapi for administration.

  Not chosen: One responsive app that switches by role.

• Live order status over server-sent events, with polling as the fallback.

  Order status reaches the barista’s tablet and the customer’s phone the moment it changes, with polling as a fallback on weak networks.

  Not chosen: Polling alone, with a delay on every change.

• Two ways for baristas to create a coffee: Simple, from its aroma and taste, and Expert, from chemical concentrations.

  Simple describes a coffee the way a barista tastes it. Expert lets researchers enter the exact compound concentrations the model works from.

Outcome

Three connected apps in six weeks, with the brewing model from the team’s ML developers wired into the café’s orders.

Disciplines

• Design, yes
• Front end, yes
• Back end, yes
• Integration, yes
• CMS, yes
• Deploy, yes
• Motion, yes
• Sound, no

Stack

teamReactVitePWAStrapiTypeScriptSQLiteWebSocket

Links

• Watch it in the showreel, 0:42

Screens

Contact