Feature Requests & Pricing.
How we approach development decisions and why we price the way we do.
Who This Is For
Reward Loyalty is for:
- Store owners who want a loyalty program, stamp cards, or vouchers for their business
- Agencies who want to offer loyalty programs to multiple clients from one installation
- Developers who want a self-hosted platform they can extend and customize
Whether you're a coffee shop running a simple stamp card or an agency managing loyalty for 50 clients, the platform works for you. See business models for detailed use cases.
Your customer data stays on your server, in your jurisdiction, under your control.
Please review the demo carefully before purchasing.
Buy What Exists
When you purchase Reward Loyalty, you're buying the product as it exists today. The feature set on the demo site is exactly what you get.
We release updates, and those updates are included with your purchase. The mindset that leads to satisfaction: expect nothing beyond what you see today. If the current feature set solves your problem, buy it. If it doesn't, don't buy it hoping we'll add what you need.
Every update we ship is a bonus, not a fulfilled promise.
Why Feature Requests Don't Drive Our Roadmap
We read every suggestion we receive. Some are good ideas. But we don't build features on demand.
Nothing Is Simple
A feature that sounds like "just add a button" involves:
- Designing how it fits within the existing architecture
- UI changes across admin, partner, staff, and customer interfaces
- Documentation updates
- Translation strings for all supported languages
- Testing across different hosting environments
- Edge cases that only surface after release
- Supporting it forever
What looks like a toggle on a settings page might touch dozens of files and require weeks of careful implementation.
Features Have Dependencies
Building software is sequential. Feature X often requires Features A and B first. The visible feature is the tip of an iceberg.
We build features top-down. The first iteration ships with core functionality, then gets refined over subsequent releases. What you see now is the current state, not the final state. But "later" might mean six months or longer depending on priorities.
No Published Roadmap
Publishing a roadmap creates expectations we can't meet. When priorities shift because reality demanded it, we'd spend more time explaining why the roadmap changed than building software.
We know the general direction. We don't pretend to know every step of the journey.
We Have a Vision
Reward Loyalty is designed to be a clean, reliable loyalty system that does core mechanics well. We're not building a points economy platform or a gamification engine.
When someone suggests a feature that doesn't fit this vision, the answer is no. It's the wrong idea for this product. We'd rather do fewer things well than many things at half quality.
The Scale of This Project
Reward Loyalty represents thousands of hours of development. This is a complete multi-tenant loyalty platform with loyalty cards, stamp cards, vouchers, membership tiers, email campaigns, staff management, customer segmentation, analytics, PWA support, and multiple languages.
When someone suggests we "just add" something, they're often not seeing the full scope of what exists or what their request actually entails.
Our Priorities
We develop new features, but we don't promise them. Our priorities, in order:
-
Bugs that break core functionality. If points aren't calculating or cards aren't displaying, that's urgent.
-
Security issues. Anything that could compromise data or system integrity.
-
Stability improvements. Making existing features work better across more environments.
-
Quality of life improvements. Small refinements that make daily use smoother.
-
New features. We build these regularly, but only ship them when they're ready.
A lot of development work is invisible. You don't see "fixed edge case where stamp card failed to increment under specific database conditions" in a changelog and think "great update." That work is what keeps the product reliable.
Pricing
Reward Loyalty costs $69 for a Regular license and $399 for an Extended license. These are one-time payments. Updates included. The code is yours to run forever.
Already at the Floor
After marketplace fees, payment processing, and taxes, we retain about 30% of each sale. At current volumes, revenue does not yet cover ongoing development and support costs. This is an investment in a product we believe in.
We don't offer individual discounts. The price reflects the value and the cost.
Compare to Alternatives
Hosted loyalty platforms like Smile.io or LoyaltyLion charge $50–$500+ per month. Reward Loyalty costs less than two months of their basic tier, and you own it forever.
With hosted platforms, your customer data lives on their servers. If they change pricing, get acquired, or shut down, your loyalty program goes with them. With Reward Loyalty, you own everything.
You Have the Source Code
Every license includes complete, unencrypted source code. If you need a feature we don't provide:
- Build it yourself, AI coding tools mean you no longer need to be a developer to do this
- Hire a developer to build it
- Commission an agency to extend the platform
The codebase is Laravel, one of the most widely documented PHP frameworks. Any competent PHP developer can work with it.
Custom Work
We are available for custom development work. This is priced at agency rates.
Building a production-ready feature involves design, implementation, testing, and ongoing maintenance. A "simple" feature request often represents $2,000–$10,000+ of development work.
If you need something custom, contact us to discuss scope and pricing. Just understand this is separate from the license purchase and priced accordingly.
Providing Useful Feedback
For bugs:
- What happened?
- What did you expect?
- Steps to reproduce
- Your environment: PHP version, database type, hosting provider
- Error messages from
storage/logs/laravel.log
For suggestions:
- The problem you're trying to solve, not just the feature you want
- How you're currently working around it
- Whether you've checked the demo and docs first
We read everything. We respond to bugs. We seldom respond to feature requests beyond acknowledgment, because there's seldom anything actionable to say.
For detailed guidance, see Getting Support.
Setting Expectations
You're purchasing thousands of hours of development work for about the cost of three hours of paid developer time. The price doesn't reflect the investment. It reflects our bet on volume.
We're a small operation. Support responses can take four or more working days. If your business depends on same-day responses, you need a platform with enterprise pricing and enterprise support. That's not us.
Your bug reports make the product better for everyone. Your feature requests are read but rarely implemented. Understanding this makes for a better experience on both sides.
Summary
- Buy the product for what it is today
- Feature requests are read but rarely implemented
- We prioritize stability over feature count
- Pricing is at the minimum sustainable level
- You have full source code to extend as needed
We'd rather have customers who understand these tradeoffs than customers who expect something we can't deliver.
For more on why product teams say no to good ideas, see Intercom's Product strategy means saying no.