Self-hosted Laravel digital commerce · Your server · Your customer dataView plans →

Package your module for review

We rebuild every accepted module ourselves, so it does not need to be perfect. A clear layout and README make the review faster and the offer better.

Folder layout

Zip one folder named after your module. Keep the same paths as the Kit, so we can see where each file goes.

birthday_vouchers/
  module.json
  README.md
  app/Http/Controllers/Admin/BirthdayVoucherController.php
  app/Services/BirthdayVouchers.php
  database/migrations/2026_10_20_000100_create_birthday_vouchers.php
  resources/views/admin/birthday-vouchers/index.blade.php
  routes/birthday-vouchers.php
  patches.md          (only if you changed a Kit file)

module.json

Optional, but it fills in our review screen for you.

{
  "slug": "birthday_vouchers",
  "name": "Birthday Vouchers",
  "category": "Marketing",
  "version": "1.0.0",
  "description": "Sends each customer a voucher on their birthday.",
  "features": ["Auto voucher", "Email + WhatsApp", "Per-tier amounts"],
  "requires": [],
  "kit_version": "1.4.8"
}

Rules

  • Laravel 13 and PHP 8.3, the same as the Kit. No new Composer packages unless you explain why in the README.
  • No eval, exec, shell_exec, system, proc_open or similar. Most stores run on shared hosting where these are switched off anyway.
  • No encoded, minified or obfuscated PHP. We reject code we cannot read.
  • Migrations check before they create: if (!Schema::hasTable(...)).
  • Do not edit routes/web.php. Put routes in their own file and say where it should be loaded.
  • If you had to change a Kit file, describe the change in patches.md instead of sending the whole file.
  • Calls to outside services are fine when the README names the service and what is sent.
  • Screens work on a phone first. Admin pages use the existing admin layout.
  • No customer data, real API keys or .env files in the zip.

What we check automatically

When you upload, we read the zip without running anything:

  • It is a real zip, up to 5 MB, at most 400 files, not password protected.
  • No unsafe paths (like ../) and only normal file types: PHP, Blade, JS, CSS, JSON, Markdown, images and fonts.
  • No .env, .htaccess or php.ini files.
  • Risky functions and long encoded strings are flagged for a person to look at. A flag does not reject your module.

A good README answers

  1. What the module does, in two sentences a store owner understands.
  2. How to install it, step by step.
  3. Which settings it adds, and what they do.
  4. What it changes for customers at checkout, if anything.
  5. Anything it sends outside the store.

How the price is decided

We look at how many stores would use it, how much rebuilding it needs and what similar modules sell for. Store credit is worth 20% more than cash. Ideas with many votes on the Ideas board get built sooner.