White-labeldelivery

Source code and documentation · multi-tenant

White-label delivery platform,without starting from scratch.

Source code and documentation of a delivery platform ready to adapt to your brand: backend, admin panel and an Android customer app. For delivery operators, franchises and entrepreneurs who want to launch their own service.

Get in touchSee the app in action
  • Source code
  • White-label platform
  • Documentation
  • Scope with no fine print

“Aurea” is the working name of the demo. The brand is not part of the sale: you bring your own.

Forno Aurelio menu with the general allergen notice
Real screenshots from an Android emulator, with demo data.
  • 163API tests, unit and integration
  • 207Android app unit tests
  • 68iOS logic tests
  • 43operations in the OpenAPI contract
Figures from the repository documentation as of 6 October 2026. All demo data is fictional.

The opportunity

Launch your delivery app without starting from zero

Building the backend, tenant isolation, payments, an allergen-aware menu, an admin panel and a mobile app from scratch is a long project. This platform hands you that core already built and tested, so you can spend your effort on what is really yours: your brand, your restaurants and your operation.

The core, solved

Orders with a state machine in the database, idempotency, payments captured on delivery, and brand isolation enforced by PostgreSQL itself.

Your brand, not ours

Each tenant configures its brand, languages, currency, taxes and fleet model without touching code. The demo tenant is only an example.

You know what you are buying

Every piece ships with its verified status and its documented gaps. What does not exist is stated, further down.

What's included

A complete product at its core

A monorepo with everything needed to run locally in about 30 minutes and keep developing.

Backend and API

NestJS, PostgreSQL with PostGIS and an outbox worker. Per-tenant OIDC login, with mandatory MFA for staff.

43 OpenAPI operations

Admin panel

Overview, orders, venues and menus with allergens, a brand editor with live WCAG contrast, settings and modules.

Next.js

Android customer app

Login, restaurants, allergen-aware menu, cart, address, checkout and order tracking, in Spanish and English.

Kotlin · Compose

Stripe payments

PaymentIntent with manual capture on delivery, and payment sync in case the webhook is late. Tested against a mock of the SDK, not real Stripe. Stripe Connect is in the design, not implemented.

Test mode

Multi-tenant and white-label

Brand, domains, currency, taxes, zones, modules and fleet model (employees or independent fleet) are data. Two demo tenants included.

RLS in PostgreSQL

Tests and CI

API tests validated against the contract, oasdiff against breaking changes, gitleaks, OSV and a licence policy on every change.

GitHub Actions

iOS logic

Session, catalogue, cart, checkout, payment and orders ported from Android, tested on Linux against real API responses. No screens.

68 tests

Deployment and publishing guides

Buyer guide, deployment guide, Google Play and App Store publishing (written, not executed) and Stripe test mode.

In Spanish

What each piece is, and how far it goes, is in the “Scope” section. What is listed here works with demo data.

The app in action

This is the customer app

Screenshots from a real walkthrough recorded on an Android emulator, with the demo tenant and a simulated payment provider. Scroll and the screen changes.

  1. Demo app sign-in screen

    Sign in

    Login and sign-up against each brand's identity provider (OIDC). In the demo, against the development IdP.

  2. Restaurant list showing open or closed status

    Restaurants

    A list with “open” or “closed” written out in text, never colour alone.

  3. Forno Aurelio menu with the general allergen notice

    Menu and allergen notice

    Categories and dishes, with allergens in words and a fixed notice that the declaration comes from the restaurant.

  4. Margherita dish with size options, extras and allergens

    Dish, options and allergens

    Sizes and extras with minimums and maximums. “Contains” and “May contain” are visible before adding.

  5. Cart with two dishes and a subtotal

    Cart

    One restaurant at a time, per-dish notes and a subtotal. Switching restaurant asks you to confirm emptying the cart.

  6. Checkout screen with totals

    Checkout

    Totals calculated by the API. Before paying, price, allergens and withdrawn dishes are reconciled.

  7. Payment screen with a demo provider

    Payment

    In the demo, a simulated payment provider. Stripe PaymentSheet is integrated, not tested with a real card.

The platform in 38 seconds

A walkthrough of the customer app: sign-in, restaurants, an allergen-aware menu, customising a dish, cart, total and simulated payment.

Promotional video with the app recorded on an Android emulator, with fictional data and simulated payment. Not a real phone. It loads only when you play it. (1.6 MB)

Differentiator

Allergens and compliance, built into the design

Allergens are not an optional field: they are part of the data model and of the interface.

  • No declaration, no publishingThe API refuses to publish a dish or option without a complete allergen declaration (422 error).
  • Always in words“Contains” and “May contain” in text, never colour alone. If the names fail to load, codes are shown with a warning; the declaration is never hidden.
  • Reconciled at checkoutCheckout compares price, allergens and withdrawn dishes with the current menu, and the customer accepts the changes before paying.
  • Regime per tenantEach country's allergen regime is tenant configuration, not code.

The platform does not claim to comply with any regulation. It lets you configure these decisions; validating them with your advisers in each country where you operate is the operator's responsibility.

Margherita

€11.00

San Marzano tomato, fior di latte and basil

Contains: cereals containing gluten, milk

May contain: mustard

Allergen information is declared by the restaurant. If you have a severe allergy, check with the restaurant before ordering.

Illustration of how the app presents it, with a fictional demo dish.

Architecture and quality

Built so a buyer can audit it

A modular monolith with tenant isolation in the database itself and a chain of checks on every change.

Apps and panelAndroid app · customeriOS logicAdmin panelREST API /v1NestJS · OpenAPI 3.1Worker + outboxPayments and expiriesPostgreSQL + PostGISPer-tenant RLS isolationOIDC IdP per tenantMFA for staffStripePaymentIntent · test mode
Simplified diagram of what exists today. External services run on the operator's own accounts.
  • 14 migrationsReversible, checked up, down and up again.
  • 90 RLS policiesTenant isolation lives in PostgreSQL and was tested against real PostGIS.
  • Contract as source of truthEvery test response is validated against the OpenAPI; oasdiff blocks breaking changes.
  • Generated clientsTypeScript, Kotlin and Swift, generated from the contract.
  • No secrets, no known vulnerabilitiesgitleaks over the whole history and OSV-Scanner in CI.
  • Licences under controlA licence policy enforced in CI, with a third-party inventory.

Transparency

What is not included

We say it before you ask. This is what does not exist and what has not been tested.

  • iOS without an interfaceOnly the logic exists (68 tests on Linux). No SwiftUI screens and not compiled with Xcode.
  • No restaurant or rider appsThe restaurant and rider apps do not exist.
  • No users and no revenueEverything was tested with demo data. There are no customers, real orders or billing.
  • No production deploymentNo deployed infrastructure, no infrastructure as code, no published apps, no store, Stripe or identity accounts.
  • Payments not tested for realNot with real Stripe, not with its webhook, not with a card in the payment sheet. Stripe Connect is not implemented.
  • Android not tried on a phoneIt builds and passes its tests and six flows on an emulator; nobody has used it on a real phone or with a screen reader.
  • No live tracking or notificationsThe apps poll the status every 20 seconds. No push, email or SMS.
  • No legal textsThe seed's documents are empty, and legal and labour decisions belong to the operator.

The full, detailed list is in the documentation you receive (operator summary and known gaps).

Roadmap and additional development

What comes next

These phases are pending. They are not part of the sale; they can be completed as additional development by agreement, with a separate quote.

  1. iOS app with a SwiftUI interface

    The logic is already built and tested (68 tests). The interface and building and testing in Xcode are missing.

    Logic done · interface pending

  2. Restaurant app

    Restaurant app (Partner), with real-time order reception.

    Pending

  3. Rider app

    Rider app (Rider), with order assignment and tracking, for both fleet models.

    Pending

  4. Live tracking and notifications

    Real-time location, push, email and SMS.

    Pending

  5. Finance dashboard

    A complete admin panel and finance.

    Pending

  6. Hardening

    Security, load testing, accessibility, observability and a complete demo.

    Pending

No dates or prices here: they are agreed case by case. Nothing in this section is included in the sale.

Ask about additional development

The handover

What the buyer receives

You receive

  • The complete monorepo: API, worker, panel, Android app, iOS logic, OpenAPI contract, generated clients, migrations and demo seed.
  • The documentation: architecture, design decisions, buyer guide, deployment guide, store publishing, Stripe test mode, known gaps and pending legal decisions.
  • The GitHub Actions CI, already written, with its quality and security checks.

You do not receive

  • The demo’s brand: it is only a working name and is not part of the sale.
  • Deployed infrastructure or accounts with any provider.
  • Published apps or Apple or Google accounts.
  • Legal texts or legal advice.
  • Users, revenue or contracts with restaurants.

How the handover works

The exact terms are settled in the sales contract: ownership and assignment of the code (including code produced with AI tools) and third-party licences. After that, the documented path is:

  1. Start the demo environment locally, about 30 minutes with Docker.
  2. Choose infrastructure and set up deployment following the guide.
  3. Create your accounts: Stripe, Apple Developer, Google Play and your identity provider.
  4. Write the legal texts with your advisers and validate the pending decisions.
  5. Create your tenant, adjust your brand and load your menu.
  6. Build, sign and test the apps, and make a real minimum-amount payment.

Frequently asked questions

What people usually ask

Does it already run with real customers?

No. There are no users, real orders or revenue. Everything was tested with demo data. It is the base for you to launch the service.

Can I go live tomorrow?

No. You need infrastructure, Stripe, Apple, Google and identity accounts, legal texts, and to test the apps with your own accounts. The buyer guide lists the steps.

What about iOS?

The iOS logic is built and tested on Linux (68 tests), but there are no SwiftUI screens and it has not been compiled with Xcode. Completing it is additional development.

Is the “Aurea” brand for sale?

No. “Aurea” is the working name of the demo and is not part of the sale. You receive the source code and documentation; you choose, check and register your own brand.

Can I change the brand?

Each tenant's brand (colours, name, typefaces) is edited in the panel, with WCAG contrast checked. The Android app does not read that brand yet: its colours, name and icon are changed by hand in the code.

Is it GDPR or labour-law compliant?

The platform does not claim to comply with any regulation. It lets you configure the decisions, and the operator must validate them with their advisers. In Spain and the EU, the independent fleet model carries a high risk of being reclassified as employment and requires prior legal advice.

What technologies does it use?

NestJS, PostgreSQL with PostGIS, Next.js, Kotlin with Jetpack Compose, Swift for the iOS logic and OpenAPI 3.1. All with permissive licences enforced in CI.

Can I commission what is missing?

Yes, as additional development by agreement and with a separate quote: iOS, restaurant and rider apps, live tracking, finance and hardening.

Contact

Let's talk

Tell us who you are and what you are looking for. We will reply with the exact scope and next steps. No commitment.

Ask about additional development

The form opens your mail app with the message prepared: this site does not send or store your data. The additional development button opens WhatsApp.

Also by phone or WhatsApp: +34 614 622 559