TL;DR
- 7-day, no-questions-asked refund on every React Native template, processed within 2 business days.
- Industry standard in premium mobile templates is "all sales final."
- Six-month refund rate: 3.8% of paid orders at a $79 price point.
- Blended cost: roughly 4% of gross revenue.
- Zero public complaints, zero chargebacks, and the highest-signal product feedback we get.
When we launched Applighter, we picked a refund policy that made two separate advisors tell us we were making a mistake: 7 days, no questions asked, processed in under 48 hours. The industry standard for premium mobile app templates is closer to "no refunds, all sales final."
This post is the honest accounting: what the policy says, what our refund rate turned out to be, what it cost in real dollars, and why we would ship the same policy again on day one.
What "no questions asked" actually means
Most refund policies for digital source code are written like a legal minefield. Ours fits on a single screen:
- You buy a template. You get source code repo access instantly.
- Within 7 days from the receipt date, you email support with the word "refund" and your order ID.
- We process within 2 business days. Stripe takes another 5–10 for the money to land. That part is out of our hands.
- We do not ask why. No survey. No "wait, let us fix it" retention flow. The template is refunded and access is revoked.
The one thing we do not refund is third-party API spend. If you already used the template with your OpenAI key and burned $12 of credits, that money is gone at OpenAI, not with us. We can't refund cash we never received.
That is the whole policy. There is no "unless you have downloaded the code" clause, because of course you have downloaded the code. That is what you paid for.
The industry standard is nothing like this
| Vendor | Refund Window | Conditions |
|---|---|---|
| Applighter | 7 days | None. No questions. |
| Instamobile | Case-by-case | No refunds on bundles. You lose rights to the code. |
| Typical CodeCanyon author | 14 days | "Not as described"; Envato adjudicates |
| Typical Gumroad seller | Author-defined | Ranges from "none" to "30 days no-questions" |
| Typical premium boilerplate | 0 days | All sales final |
The most common posture is "no refunds." The second most common is "refund only if the code does not match the demo," which is unfalsifiable in practice because the demo can always be reframed to match whatever ships.
We picked 7-day no-questions anyway.
Why we did it
We sell to indie developers and small teams who have been burned by AI-generated boilerplate and want a foundation a senior engineer would ship. That buyer is not shopping on price. They are shopping on trust.
1. The buyer cannot inspect the product before buying. With a physical product you pick it up. With SaaS you start a trial. With a source-code template you get a demo video, a feature list, and a screenshot. You have no way to know until you clone the repo whether the code is production-grade or the same AI-shaped mess you were trying to escape. A generous refund policy is the only way we can honestly say "check for yourself" in a market where that check requires purchase.
2. Every objection works in our favor if we're right about the product. If the template is what we claim (layered architecture, RLS reviewed, Expo current, designer-vetted UI) the refund rate should be low. If it isn't, the refund rate tells us so quickly and painfully, and we fix the product. The only universe where the generous policy hurts us is the one where our product is bad, and in that universe we deserve to hurt.
3. Refund friction is negative marketing. Every "we don't do refunds" post from a template vendor generates a Reddit thread within 24 hours. We had no interest in being on the other side of that conversation.
What the refund rate actually was
Here is the number nobody wants to publish. Over the first six months, our refund rate against paid orders sat at 3.8%. That includes every request, valid or otherwise.
The most common reason (inferred from the handful of buyers who added a note despite us not asking) was "wrong template, meant to buy a different one." Second was "changed my mind before starting the project." Actual code-quality complaints were rare enough to count on one hand.
At a $79 price point that's roughly $3 lost per paid order before Stripe fees. Stripe does not refund its fixed per-transaction fee, so the effective cost is closer to $3.30. We treat it as a marketing line item. For every $30 spent on Google Ads, one refund costs the equivalent of ten click-throughs.
There's a known data point in the digital-products community: a Dev.to writeup from last year reports ~40% refund rates at $29 and ~4% at $79 for a comparable template. Our number lines up almost exactly with that curve.
The right customer for a premium template is not price sensitive but time sensitive, and price signals seriousness. Cheap templates get impulse buys and impulse refunds; a $79 sticker filters for the buyer who has actually decided to ship something.
What it actually cost us
Refunded revenue. At 3.8% and an AOV of $79, roughly $3 per paid order. Over six months this was a four-figure number. Not nothing, but small compared to ad spend.
Stripe fees. Stripe keeps the fixed 30¢ per transaction on refunded orders and refunds the percentage portion. Small but real.
Support time. Five-minute email round trip plus one click in the Stripe dashboard. No self-serve refund flow. Maybe 90 minutes per month total.
Opportunity cost. The biggest hidden cost is the buyer who would have accepted store credit but took the cash and vanished. We do not push back. If the policy says "no questions," offering a store-credit alternative violates the spirit of it.
What it did not cost: brand trust, negative reviews, or Reddit threads. Six months, zero public complaints about the refund process, every request resolved inside the promised window.
Total blended cost: roughly 4% of gross revenue.
The counter-intuitive benefits
Refund requests are the highest-signal feedback you get. Nobody who is happy tells you why. Refund requests come with implicit information even without a question attached. Which template was refunded, whether the buyer opened the docs, whether they cloned the repo. When we saw two refunds in one week from buyers who never opened the setup docs, we knew the docs were too easy to miss, and we fixed the onboarding email.
A generous policy pre-qualifies your buyer. The buyer who thinks "seven days, that's plenty of time to know" is exactly who you want. The buyer who thinks "seven days isn't enough" is telling you they plan to sit on the code for months before evaluating it, which means they are not going to ship, which means they end up unhappy regardless.
The support inbox gets easier. When "I want a refund" is a two-word conversation instead of a negotiation, the emotional temperature drops. Zero hostile emails in six months. Vendors with strict policies routinely deal with disputes and chargebacks, and chargebacks are worse than refunds by every metric: Stripe fees, dispute time, reputational damage.
When a generous refund policy is wrong
We would not recommend this in every context.
Under $30. Cheap products attract impulse buyers who refund at rates approaching 40%. The math does not work. Raise the price or tighten the policy. We chose the former.
Significant marginal cost per sale. Digital source code is essentially zero marginal cost, which is why we can absorb the rate. A vendor shipping physical hardware could not.
When the buyer consumes full value inside the window. Course sellers offering 30-day refunds have to build anti-abuse (watching >50% voids it) or the rate approaches 100%. Source code is different. Value is realized over months of shipping the actual app, not in the first week of reading it.
When you can't hit the turnaround. A 7-day policy that takes 30 days to process is worse than no policy. We commit to 2 business days because we know we can hit it every time.
The policy only works because of the product
Refund policy is not the first line of defense. It is the last. Everything else is designed to reduce the need for it: full TypeScript source you can inspect, a Supabase backend with reviewed Row Level Security policies instead of leaving access rules as an exercise for the buyer, and Expo kept on the current stable release rather than pinned to a version from two years ago. You can see how that shakes out across the template catalog.
A generous refund policy without a product to back it up would bleed us dry. A great product without a generous refund policy would push part of the market to competitors who trust their buyers more. Neither alone is enough.
FAQ
Do you refund if I already deployed to production?
Yes. No clause tied to deployment. Within 7 days, you can refund. We ask that you stop using the code, but there is no technical mechanism forcing it.
Refunds after the 7-day window?
No, and this is the one place we hold the line. Extending case-by-case erodes the policy for everyone.
Do you refund third-party costs?
No. If you spent $50 on your OpenAI key, that money is at OpenAI, not with us.
Does refunding once block me from buying again?
No penalty. Each purchase is independent.
The bottom line
The policy costs roughly 4% of gross revenue. In exchange: a filter that pre-qualifies serious buyers, feedback signal we would not otherwise receive, a support inbox that stays calm, and a story we can tell publicly without flinching. We were told this policy was reckless. Six months in, it is one of the operational decisions we would change least.
If you sell a digital product: pick the most generous policy your unit economics can survive, publish it in plain language, and honor it without exception.
What's your refund policy, and what has it actually cost you? Drop the number in the comments. Almost nobody publishes theirs, and I'd genuinely like to see how 3.8% compares.
Top comments (0)