30-Day satisfaction guarantee — and the fine print, in plain English

If, within 30 days of delivery, you make a good-faith launch attempt with a MIKODES product and the deliverable has a structural failure that prevents it from earning, we will either rebuild it free of charge or refund the full purchase price. You choose.

To claim a refund, you need to demonstrate three things:

• Deployment evidence. A live URL, deployment screenshot, or build artifact showing you successfully ran the product in your environment within the 30-day window.
• Monetization attempt. Proof that you wired up at least one revenue path documented in our materials — e.g. Stripe keys plumbed through, swap-fee routing enabled, PRO tier configured. Screenshots, configuration files, or a short Loom of your admin panel are all fine.
• Specific structural failure. A clear description of what broke that we are responsible for: a documented monetization layer that does not function as advertised, an integration that is broken from our side, a feature missing despite being promised in the product page.

The bar is intentionally not zero — it’s “good faith”. We are not asking you to prove you became profitable. We are asking that you actually shipped and tried.

• “I changed my mind.” Source code is digital and not returnable in the traditional sense — but we offer a free 15-min strategy call before any purchase precisely to prevent this.
• “I never deployed.” If you didn’t ship, we can’t evaluate whether the product earns. Deployment is the entry condition.
• “I couldn’t figure it out.” Within the 90-day support window, we will help you ship — that is what the support is for. Use the chat or your strategy call before requesting a refund.
• “Didn’t get enough users.” Marketing, traffic, audience-fit are your work. Earnings projections in our marketing copy and ROI calculator are estimates, not guarantees of your outcomes.
• Custom builds after delivery acceptance. Custom is bespoke. Once you sign off on delivery, the build is yours and the engagement is closed. Issues found after acceptance are scoped as new work.
• Refunds requested after the 30-day window. The window is firm. Beyond day 30, we offer rebuild help under support, not refunds.

When a refund request qualifies, you choose which path you want:

• Path A — Rebuild. We schedule a working session, find the structural issue, and ship a fix at no extra cost. A new 30-day window starts from the rebuild delivery date. Your purchase remains active.
• Path B — Cash refund. Full purchase price refunded to the original payment method (Stripe), within 14 calendar days of approval. License terminates upon refund — you remove the product from your systems within 30 days of refund clearance.

We default to suggesting Path A first because most issues are fixable — but the choice is yours.

The flow:

• Email refunds@mikodes.com or message Telegram @mikodescom with subject line: “Refund: [Order ID] — [Product Name]”.
• Attach: order receipt, deployment evidence, monetization-attempt evidence, structural-failure description.
• We reply within 2 business days with one of: approval, request for additional evidence, denial with reason.
• If approved, you choose Path A or Path B and we proceed.
• If denied, you may dispute via Section 06 below.

If your refund is denied and you genuinely disagree with our reasoning, the path is:

• Step 1 — Reopen with new evidence. Most denials happen because the deployment-or-attempt evidence wasn’t sufficient. Send a clearer demo or a Loom walkthrough.
• Step 2 — Founder-level review. Email founders@mikodes.com with the original request and the denial reasoning. We will personally re-evaluate.
• Step 3 — Stripe chargeback rights. You retain whatever consumer chargeback rights are granted by your payment provider (Stripe). We will not retaliate against legitimate chargebacks. We may, however, dispute a chargeback if we have evidence the refund standard was not met.

We have not yet had a refund request that wasn’t resolvable through Step 1 or 2.

Some buyer scenarios worth calling out explicitly so there’s no surprise:

• Buying multiple products on the same order: each product is evaluated independently — you can refund one and keep another, even if both came from the same checkout.
• Bundle products: the 30-day window starts from the delivery date of the last bundled item, not the order date.
• Partial refunds: not offered. Either the deliverable failed structurally and you receive full refund or rebuild — or it didn’t and the license stands.
• Multiple refunds across multiple purchases: we reserve the right to decline future sales to a buyer who has refunded more than 50 % of their purchases — bad faith on the customer side breaks the model.

Most code marketplaces don’t offer refunds because their incentive is to ship files and disappear. Ours is different: we make most of our revenue from buyers who come back for the next product, the next bundle, the next custom build. A buyer who shipped, earned, and trusts us is worth far more than a buyer who got files and ghosted.

So the refund policy is a forcing function: it makes us care that the deliverable actually earns for you. If it doesn’t, we lose. Aligned incentives — that’s the whole pitch.