Noureddine RAMDI / Enatega multi-vendor delivery platform: open-source frontends backed by proprietary API

Created Sat, 23 May 2026 20:41:14 +0000 Modified Sat, 23 May 2026 20:41:27 +0000
945 Words
github-stars react-native react nextjs graphql nodejs mongodb

enatega/food-delivery-multivendor

Enatega is a multi-vendor delivery management platform that combines several frontend applications—mobile apps for customers, riders, and stores, a web app for customers, and an admin dashboard—built with React Native, React, and Next.js. The catch is that while all these client applications are open source, the backend API server that powers them is proprietary and requires a paid license. This creates a split between open-source frontends and a closed backend API, a common open-core business model.

multi-platform delivery management platform with separate frontends and a proprietary backend

The Enatega repo hosts multiple client modules targeting different users in the delivery ecosystem. The mobile apps for customers, riders, and stores are built using Expo with React Native, enabling cross-platform development for iOS and Android. The customer-facing web app is built with React, and the admin dashboard uses Next.js, a React framework optimized for server-side rendering and admin interfaces.

Under the hood, these frontend clients communicate with a backend API built with Node.js, Express, and MongoDB. Communication is handled through Apollo GraphQL, which provides a strongly typed and flexible API layer for the clients to query and mutate data.

Authentication and push notifications are handled via Firebase, integrating seamlessly with the mobile and web clients. The system also integrates Amplitude for analytics tracking and Sentry for error monitoring, providing operational insights and stability.

The architecture effectively separates concerns: multiple client apps tailored for different user roles, a GraphQL API server for data and business logic, and third-party services for authentication and telemetry. However, the backend API server is closed source and requires a paid license, restricting the full-stack deployment to customers who purchase the backend.

open-source frontends with proprietary backend: tradeoffs and code quality

The split between open client modules and a proprietary backend is a clear tradeoff. On one hand, the open-source frontends allow developers and businesses to customize the user experience, inspect the client logic, and integrate with other systems. On the other hand, the core business logic, data storage, and API remain behind a paywall, which limits the ability to self-host or extend the backend fully.

From a code quality perspective, the frontend codebases follow common patterns for React and React Native projects, using Apollo Client for GraphQL queries and mutations. The structure aligns with typical multi-platform projects, separating concerns by platform and user role.

Unfortunately, the documentation is minimal regarding technical depth. Setup instructions mainly repeat npm install commands without details on build, run, or deployment processes. There are no benchmarks or performance metrics, so it’s unclear how the platform performs under load or in production scenarios.

This lack of backend source code and detailed documentation is a limitation for developers looking to audit, extend, or self-host the full solution. The tradeoff is transparent: the repo provides scaffolding for paid API usage rather than a full open-source delivery platform.

quick start: setting up the admin dashboard and client modules

The README provides some guidance on setting up the modules, emphasizing the need for Node.js (version 16 to 20) and various credentials for third-party services and the backend API.

For the admin dashboard built with Next.js, the setup commands are straightforward, though repetitive:

npm install
npm install
npm install
npm install
npm install

Credentials for Firebase, MongoDB, email, and API endpoints need to be set in various config files such as helpers/config.js, helpers/credentials.js, and src/index.js for the admin dashboard.

The README mentions that the email provider has only been tested with Gmail accounts, which is a useful note for developers planning integration.

The instructions are sparse and somewhat redundant but reflect the reality of dealing with multi-module projects that require coordination of environment variables and keys across components.

verdict: useful open-source frontends but limited backend access

Enatega’s repo offers a practical example of a multi-platform delivery management system with open-source client applications and an admin dashboard that integrate with a proprietary backend API.

The architecture aligns with common patterns in delivery and logistics software: role-specific clients, GraphQL API, MongoDB persistence, and third-party services for authentication and analytics.

That said, the closed-source backend is a significant limitation if you want a fully open-source, self-hostable solution. The frontend code is mostly scaffolding to consume the paid API rather than a standalone product.

Documentation is minimal and could benefit from clearer build and run instructions, as well as more details about deployment and operational considerations.

If you are a developer or company considering multi-vendor delivery systems and want to customize frontends or build on top of a stable API, this repo offers a solid starting point. However, if you require full control over backend logic and data storage, this solution may not meet your needs without purchasing the backend license.

Overall, Enatega illustrates the open-core model in practice, with transparent tradeoffs between open client modules and proprietary backend business logic.

→ GitHub Repo: enatega/food-delivery-multivendor ⭐ 1,248 · JavaScript