Tomato Coupons Laravel Package

Product Decisions This Supports

• MVP scope: does promotions ship in v1, and how deep? This package supports a staged decision: admin-managed coupon CRUD first, then checkout redemption, then eligibility rules, then gift card ledgers, then reporting/fraud controls. It lets you commit to "simple code-based discounts" for a first release without committing to a rules-based promotion engine.

• Build vs. buy vs. fork. A concrete, MIT-licensed Laravel/TomatoPHP reference for coupons, offers, and gift cards. The licence permits forking and owning the code, so the real decision is not "vendor vs. build" but "accelerate with this schema and admin UI vs. write the tables in a day." Given 2 stars, 0 dependents, and a May 2024 last release, it should be positioned as an accelerator or reference implementation, never a supported product dependency.

• Gift cards as a growth and monetization feature. Enables decisions on prepaid gift cards for acquisition, retention, seasonal campaigns, partner promotions, refunds, and store credit. If gift cards become financially material, this pulls in finance and legal early — balances create liability, expiry, breakage, and reconciliation obligations that are product decisions, not admin screens.

• Back-office and support requirements. Adopting it forces explicit requirements for support and finance workflows: issue, void, reissue, balance adjustment, expiration, usage audit, and customer-service exceptions. These needs exist whether or not you use the package, but the package's Filament resources give you a tangible starting point to react to.

• Campaign experimentation at low cost. Lets growth run launch offers, referral codes, partner codes, and limited-time discounts without a third-party promotions SaaS contract or the procurement cycle that comes with it.

• Roadmap sequencing and effort sizing. Makes the work visible: the package saves the schema and admin screens, not the semantics. Budget roughly 2–3 weeks of engineering for production-grade coupons plus gift cards on top of it — discount math, eligibility, atomic redemption, and gift card ledgers are all yours.

When to Consider This Package

Consider it when:

• You are building on the TomatoPHP e-commerce stack, or a Laravel app already following TomatoPHP/Filament admin conventions. The package's value is concentrated in the Filament resources; outside that context the schema is portable but the advantage is thin.
• You need an MVP coupon, offer, or gift card admin module and want an existing data model and CRUD surface to evaluate rather than a blank page.
• Promotion requirements are genuinely simple: percentage and fixed-amount discounts, code-based offers, validity windows, usage limits, and manually managed gift cards.
• You are willing to pin the exact version, review the migrations and models, write your own tests, and potentially fork. The loose Composer constraints mean an unplanned composer update can pull an untested Filament major and break the admin resource.
• You want to avoid a SaaS commitment for early promotion features and accept ownership of maintenance, security review, and checkout integration.

Look elsewhere when:

• You are not on Laravel/TomatoPHP, or you need a framework-agnostic promotions engine.
• You need advanced promotion logic: stackable rules, BOGO, tiered discounts, customer segmentation, multi-currency, tax-aware gift cards, or high-volume redemption.
• You require active maintenance, security patching, SLAs, or a supported vendor relationship. This is community-only support — GitHub issues and the TomatoPHP Discord — with no dependents and no release in over a year.
• Gift cards are regulated or financially material, requiring audit-grade ledgers, reconciliation, fraud controls, and compliance review.
• You cannot fund the engineering time to inspect authorization, validation, and concurrency handling, and to build the checkout integration yourself.

Critical caveat for any go decision: the package does not perform discount math or eligibility enforcement — no stacking, no minimum-spend check, no per-customer limit enforced at the database level, no tax handling. It is a back-office CRUD layer, not a pricing engine. Concurrency is the sharpest edge: parallel redemptions of a single-use coupon, or parallel gift card debits, will both succeed silently without row locking or conditional updates.

How to Pitch It (Stakeholders)

For executives: This is a low-cost, MIT-licensed starting point for coupons, offers, and gift cards in a Laravel/TomatoPHP environment. It can shorten time-to-market for basic promotional features and their back-office management, and it avoids a SaaS contract. But it has very low community validation — 2 stars, zero dependent projects, no release since May 2024, community-only support. Treat it as a prototype or reference implementation: adopt only with engineering review, a pinned version, and an explicit plan to own the code. The upside is faster launch of promotions and prepaid gift cards; the risk is maintenance and compliance overhead once gift cards carry real financial liability.

For engineering: Evaluate it as a Laravel module, not a dependency. Read the config, migrations, models, and Filament resources first; then review authorization, validation, and checkout hooks; add tests; then decide whether to vendor, fork, or extract the patterns. Do not assume it provides hardened checkout redemption — budget for custom code around eligibility, discount calculation, atomic redemption with lockForUpdate(), and gift card balance safety via an append-only ledger rather than the package's counters. Run parallel-process tests against a real database before enabling redemption in production, and add a CI matrix against your target Laravel/Filament versions so a Filament major surfaces as a red build rather than an incident.

For product and growth: Use it to accelerate experiments with coupon codes, seasonal offers, and gift cards, but define requirements up front for abuse prevention, redemption limits, expiration, customer-support adjustments, and reporting. Sequence the rollout: coupon CRUD, then checkout redemption, then eligibility rules, then the gift card ledger with balance checks, then analytics and fraud controls. Be explicit about what v1 will not do — no stacking, no tiered or segmented offers — so the first release ships with understood limits rather than a promotions engine nobody scoped.