How I Built a White-Label Food Delivery Platform with AI Assistance (and What I Learned)

I'm Angel Dos Santos, an independent developer (Nexoweb) based in Albacete, Spain. I built a white-label food delivery platform with the help of an AI coding assistant, Claude Code, and I reviewed the code myself. This post covers why I built it, how it's put together, how the AI collaboration went, and what is not finished.

One thing up front: it has no users and no revenue. It's a complete codebase, not a running business.

Why I built it

Food delivery is a problem with plenty of moving parts: customers, restaurants, orders, payments, maps and several client apps. That makes it a good test of whether one developer plus an AI assistant can produce something coherent and well tested across a full stack.

I wanted a white-label base: a platform where the brand can change and several businesses can share one backend safely.

Architecture and technical decisions

Backend. The API is NestJS with TypeScript, on PostgreSQL with PostGIS for location queries. The admin panel is Next.js.

Multi-tenancy with row-level security. Isolation between tenants is enforced in the database, not only in application code. PostgreSQL row-level security (RLS) policies decide which rows each tenant can see. The project has 14 migrations and 90 RLS policies. I chose RLS because a forgotten WHERE tenant_id = ... in the app layer can leak data across tenants, while a policy in the database still applies.

API-first with OpenAPI 3.1. The API is described in an OpenAPI 3.1 spec with 43 operations, and the clients are generated from it. A single contract keeps the backend, the admin panel and the mobile apps in step.

Clients.

• An Android app in Kotlin with Jetpack Compose.
• iOS business logic in Swift. There are no SwiftUI screens (more on that below).
• The Next.js admin panel.

Payments. Stripe is integrated in test mode only. Stripe Connect is not implemented.

Tests and CI. The test suite has 163 API tests, 207 Android unit tests and 68 iOS logic tests. CI runs on GitHub Actions.

How I worked with AI

What worked. The assistant was most useful for work that is well specified and repetitive. That includes scaffolding modules, writing migrations and policies from a clear description, generating test cases and keeping code consistent across layers. An OpenAPI contract helps a lot here, because it gives both of us an unambiguous source of truth.

What needed my review. AI-generated code can look right and still be wrong, so I treated it like a pull request from a fast junior colleague. Security-sensitive areas need extra attention: tenant isolation, authorization rules and payment flows. I reviewed the code myself and used the tests as a safety net, not as a substitute for reading.

The limits. The assistant doesn't know your business constraints unless you state them. It follows the structure you give it, so architecture decisions still have to come from a person. And "tests pass" only means the tests you have pass.

What is not done. I'd rather be clear about this than let anyone assume otherwise:

• iOS has logic but no screens. The Swift business logic is there, with 68 tests, but there are no SwiftUI views.
• Stripe Connect is not implemented. Payments run in Stripe test mode only, so there is no marketplace payout flow.
• No production usage. There are no users, so none of this has been proven under real-world load or real customer behavior.

Lessons learned

1. Write the contract first. With OpenAPI as the starting point, the AI's output stayed consistent across the backend and the clients.
2. Put security in the database. RLS made multi-tenancy something I could test and reason about, instead of something I had to remember to do.
3. Tests make AI-assisted development workable. With a large test suite you can accept or reject changes with more confidence. Tests don't replace review.
4. Review is the job. AI speeds up writing code. It doesn't remove the need to understand it, and I'd be uneasy shipping code I couldn't explain.
5. Be honest about scope. Writing down what is missing (iOS screens, Stripe Connect) made the project easier to describe and easier to plan around.

Closing

The platform is for sale: source code and documentation, without the brand. If you're an agency or a team looking for a starting point for a delivery or marketplace product, you can see the demo here: https://plataforma-delivery-demo.netlify.app/en/

You can reach me at [e-mail]. I'm also happy to answer technical questions about the architecture in the comments.