Zaki Gouizi
Français

Co-founder & CTO · September 2024–present

Enka

A food-delivery app in Montpellier, built around a shared aim: a fairer arrangement for couriers and restaurants.

My role
Co-founder & CTO
Location
Montpellier, France
Involved since
September 2024
Product
Android & iOS

Why I joined

Enka started with a friend's idea. I brought the engineering skills to help make it possible, and I shared the aim behind it: giving delivery workers more say over their work and building a fairer arrangement for couriers and restaurants. It connected with why I became an engineer—to be able to build solutions for myself and the people around me.

From choosing a meal to receiving it

Enka is available on Android and iOS. Its current offer is food delivery in Montpellier at restaurant takeaway prices, with no restaurant commission. Customers choose a restaurant, build a basket, pay by card or select cash on delivery, and follow preparation and delivery. The app also offers guest ordering and messaging with the courier.

Those screens sit on top of a service involving restaurants, couriers and the team handling day-to-day operations. That connection was the engineering problem I worked on: making the information and actions across the service fit together.

One order, three connected interfaces

As CTO, I worked on the application and its technical foundations: restaurant information, ordering, courier workflows and administration. A customer placing an order, a courier collecting it and an operator resolving an exception all need a consistent view of what is happening.

The application documentation separates these into customer, courier and administrator roles. My work connected the interfaces with their shared data and state changes. The stack includes Next.js/React, Supabase/Postgres and Mapbox.

A simplified view of the application’s three roles

  1. Customer — Browse restaurants, build a basket, place and follow an order.
  2. Courier — Accept a job, collect the order and update its progress.
  3. Operations — Maintain restaurant information and handle order exceptions.
Workflow summary based on the application documentation; not a deployment architecture diagram.

Make restaurant information usable

Alongside the application, I built tools to collect and compare restaurant menu information. The same dish can have a different name, appear in another section or use a different price format across sources. Collecting pages is only the first part of the problem.

I kept collection separate from matching and comparison. That made it possible to revise section-aware fuzzy matching and inspect the comparison output without repeating the entire collection process. A recorded benchmark covered ten restaurant URLs with different page structures and tracked timing, observed prices and failures. The aim was to understand the limits of the data as well as obtain it.

From source menus to a reviewable comparison

  1. Collect — Capture menu structure, dish names and prices from each source.
  2. Match — Compare dishes within their sections and handle naming differences.
  3. Review — Inspect the comparison and revisit ambiguous matches.
Supporting engineering work documented in UltimateScrapeV1; benchmark sample: ten restaurant URLs.

Understand the delivery system around the app

The team’s business plan explores a cargo-bike relay model for Montpellier: collect orders inside the pedestrian centre, transfer them at collection points and let couriers handle the onward delivery. It is useful context for the coordination problem behind the software.

The plan presents an AnyLogic simulation of that approach. It reports faster delivery for 60% of simulated orders, equivalent times for 29% and delays for 11%. Within the delayed group, 5% of all simulated orders were more than five minutes late. The figures show both the potential benefit and the cases that still need attention.

Faster delivery
60%
Equivalent time
29%
Other delays
6%
Delay over five minutes
5%

Working with the visual team

I also contributed to application UX/UI and took part in visual discussions: offering ideas, requesting revisions and working through how the application and its presentation should relate. Design was collaborative. Amandine Basset contributed UX/UI work, and Rouge Studio developed identity and communication work.

The studio’s documents explore three directions: interlocking parts, bicycle culture and movement. The movement concept connects the courier, bicycle wheels and the relationships between the people using the service. The strategic dossier carries the same concern into its creative brief: make the people behind a delivery visible while keeping the experience simple.

Where it stands, and what I take from it

The app is publicly available, and the team is working toward the traction needed for its first pre-seed funding. I remain involved, with less day-to-day coding during this phase.

The project expanded the scope of my engineering work. A screen, an order status and a courier's next action all have to make sense together. Building the product meant thinking about those connections and working with people whose expertise went beyond my own.

Links