A food delivery script is not just a download. The licence decides how many installations you can run, whether you can charge clients to use it, whether you can resell it, and what happens when you hire an agency. Most buyers read the feature list and skip this page. Then the project grows and the licence becomes the constraint.
This is a practical buyer's guide, not legal advice. Licence terms vary by vendor and marketplace; read the actual agreement and ask the vendor to confirm your use case in writing.
| Use case | Typical licence | What to confirm |
|---|---|---|
| One delivery business, one domain | Regular | Production + staging, subdomains, app bundle IDs |
| Agency builds for one client | Regular or extended | Whether the client or agency holds the licence |
| Multiple client deployments | Extended / reseller | Number of installations, domains and support |
| SaaS sold to restaurants | Extended / commercial | Right to host for third parties |
| Reselling the code itself | Usually prohibited | Redistribution and derivative-work terms |
Regular vs extended, in practice
A regular licence usually covers one end product for one business. An extended licence usually adds the right to charge end users or deploy for a client. The exact boundary is set by the licence, not by the price label. One marketplace may treat a client project as regular use; another may require extended.
If you are an agency, do not assume that buying a regular licence and installing it for a client is allowed. Ask specifically: “Can my client own and operate this deployment, and can I charge them for the build?”
Domains, staging and subdomains
Most licences count a production installation. A staging copy, a demo subdomain and a white-label domain may each count separately. Confirm before you build a sales demo on the same codebase. If the vendor requires a separate licence for each domain, budget for it.
Also check the app bundle identifiers. Apple and Google treat each bundle ID as an app; a licence that covers “one installation” may not cover three branded app listings.
Client work and handover
When an agency builds for a client, decide who holds the licence, who owns the repository and who can request changes after handover. The cleanest structure is usually: the client buys the licence in their name, the agency builds under a services contract, and the client owns the deployment. That avoids a future argument if the relationship ends.
If the agency holds the licence, the client is effectively renting access. Put that in writing, including what happens if the agency closes or the client wants to move.
Redistribution, SaaS and “white label”
White-label does not automatically mean resale. It usually means you can remove the vendor's branding; it does not mean you can sell the software as your own product. Hosting for multiple restaurants as a paid service is a different right, often requiring an extended or commercial licence.
Read the clauses on derivative works, sublicensing and hosted services. If the business model is “I run the platform and restaurants pay me”, confirm that the licence permits it.
A five-minute licence checklist
- How many production installations are allowed?
- Are staging, demo and subdomains included?
- Can I charge clients for implementation?
- Can I host for third-party restaurants?
- Can I modify the code and keep changes private?
- What happens on upgrade or vendor shutdown?
- Is support included, and for how long?
See the CodeCanyon buyer guide, the agency delivery model, or Foodomaa's $299 licence.
Client work and rebranding are covered in more detail in the white-label food delivery app guide.