---
title: Myntra Clone Features
description: "Explore Myntra Clone features for buyers, brands, delivery agents and admins, including variant inventory, payments, returns, commissions and analytics."
url: https://miracuves.com/myntra-clone/features
date_modified: 2026-08-24
author: miracuves
language: en_US
---

Myntra Clone · Features
          
# Myntra Clone Features: Every Size Is Its Own Product

          
Fashion is a variant problem before it is anything else, and a returns problem immediately after. A medium selling out must not take the listing down with it, a discount on one colour must not leak onto another, and a large share of what ships is going to come back. Here is what ships, grouped by who touches it.

          [Request a Live Demo →](https://miracuves.com/schedule-consultation/)[See Pricing](/myntra-clone/development-cost/)
          
            **SKU-level** price and stock per variant
            **Returns** are core, not an exception
            **6 days** to deploy
          
        
        
          MediumSold out, listing stays
          
            How a Garment Comes Back
            
              01Buyer picks a colour and a size
              02That exact SKU moves, not the style
              03Return opened with reason and photos
              04Its own status machine, settles once
              05Commission reverses automatically
              06Loyalty reverses, stock returns to SKU
            
          
        
      
    
  

  
    
      
        SKULevel Price and Stock
        131Normalized MySQL Tables
        9Order Statuses, Per-Line State
        4Append-Only Ledgers
      
    
  

  
    
      
        By Role
        
## Feature Set by Role

        
Six surfaces on one REST API. In fashion the seller is usually a brand rather than a shopkeeper, so the panel is built for someone merchandising a label rather than listing stock.

      
      
        
          B
          
### Buyer

          
- Shop by brand as well as by category, through a brand directory
- Product page carrying the full colour and size matrix
- Photo reviews showing the garment on real people
- Wishlist and save-for-later that persist between sessions
- One bag spanning several brands at once
- Guest bag tracked by session and merged on login
- Coupon, wallet credit and loyalty points applied together
- Return opened with a reason and evidence, tracked to settlement

        
        
          L
          
### Brand

          
- Registers with KYC, approved and suspendable by an operator
- Variant matrix collapsing colour and size into SKU rows
- Per-SKU price and quantity, so one size can be discounted alone
- Multi-image galleries and video on a listing
- Bulk import and export for a seasonal drop
- AI-assisted descriptions, SEO titles and image alt text
- Order queue, refund responses and replies on any review
- Commission visible on the wallet, reversed automatically on a return

        
        
          D
          
### Delivery Agent

          
- First-class identity with KYC, approval and zone assignment
- Assignment feed with accept and reject
- Navigation to the brand for pickup, then to the buyer
- Live location broadcast while in transit
- Status checkpoints from picked up through to delivered
- One-time code verified at the door before handover
- Earnings held separately from cash collected on COD
- Payout request flow from the app

        
        
          O
          
### Operator

          
- Refund queue as a standing daily workload, not an occasional task
- Catalog moderation with bulk approve and reject
- Control of the category, brand and attribute libraries
- Cross-brand orders with a status timeline and edit history
- Commission set globally, per category, per brand or per product
- Seasonal deals, banners and featured placement
- Every module behind its own permission
- Eight report types over any date range, to Excel, CSV or PDF

        
      
      
The brand directory is not cosmetic. Modelling a label as an entity in its own right - merchandisable, followable, filterable - is what separates a fashion marketplace from a general catalog with clothes in it.

    
  

  
    
      
        Compare
        
## Myntra vs Miracuves Clone vs Building From Scratch

        
The same capability, three different paths. The rows that separate them are variant rows and return rows, because those are the two things fashion breaks on.

      
      
        
| Capability | Original Myntra | Miracuves Clone | Generic commerce script |
| --- | --- | --- | --- |
| Colour and size | Yes, at enormous catalog scale | Every combination resolves to a SKU row with its own price and quantity - a sold-out medium never takes the listing down | Variants as options on one stock number |
| Discounting one variant | Yes, routinely | Per-SKU price, so a discount on one colour cannot leak onto another | One price for the style, or a manual workaround |
| Returns | Yes, heavily industrialised | A request with reason and evidence walking its own status machine, reversing commission and loyalty along with the money | A status flag and a manual refund |
| Photo reviews | Yes, and central to conversion | Image upload on reviews, with brand replies on any review | Star ratings and text |
| Wishlist across sessions | Yes | Wishlist and save-for-later that persist, because fashion buying is rarely one session | A session cart that empties |
| Brand as an entity | Yes, brands are the navigation | A brand directory alongside the seller model, so a label can be merchandised in its own right | A text field on a product |
| Partial shipment | Yes | A delivery status per line, so one brand can ship while another has not | One status for the whole order |
| Source code | Not available | Complete Laravel 12 backend and all three Flutter projects, unobfuscated, no licence callback | Often encrypted files or a licence check |
| Time to live | Not applicable | Six working days | Weeks, then months on variants and returns |

      
      
The first two rows are the ones to test. Ask any provider to sell out a single size and then discount a single colour. A platform that cannot do both was built for products, not for garments.

    
  

  
    
      
        End to End
        
## How It Works, End to End

        
One bag, one size chosen, one garment returned - traced through every state it passes and every balance it moves.

      
      
        
          01
          
            
### The buyer picks a variant, not a product

            
Colour, size and any custom attribute resolve to a specific SKU row. That row carries its own price and its own quantity, so what the buyer adds to the bag is a real sellable unit rather than an option on a shared stock number.

          
        
        
          02
          
            
### The photo reviews do most of the selling

            
Reviews carry image upload, so the garment is seen on real people rather than on a model. In fashion this is the single most effective thing on a product page, it costs nothing to run, and brands can reply to any review from their panel.

          
        
        
          03
          
            
### The bag waits, because fashion buying is rarely one session

            
Items move to a wishlist or save-for-later and stay there. A guest bag is tracked by session and merged into the account on login. The return visit, not the first one, is the conversion that matters in this category.

          
        
        
          04
          
            
### Checkout stacks the discounts and guards the submit

            
A coupon, wallet credit and loyalty points can all apply to the same order, with tax from the zone rules and shipping picked per brand. Placement is guarded by an idempotency check, so a flaky connection and an impatient tap do not become two orders.

          
        
        
          05
          
            
### The brand packs that exact SKU

            
The order lands in a brand queue with accept and reject, from the web panel or the Android app. Stock moves on the specific SKU, low-stock thresholds fire on that variant alone, and commission is visible on the brand wallet from the moment the line is accepted.

          
        
        
          06
          
            
### The garment comes back, and this is the part that matters

            
A return opens with a reason and evidence, then walks a status machine of its own - which is what prevents a refund settling twice. It resolves as immediate wallet credit or back down the rail that took the payment. Commission on that line reverses automatically, loyalty points earned on it reverse with it, and stock returns to the specific SKU rather than to the style.

          
        
        
          07
          
            
### The reported number stays honest

            
Every balance movement across all four wallets pairs with an append-only history row written in the same database transaction. Eight report types run over any date range and export to Excel, CSV or PDF - which in a category with fashion's return rates is the difference between a number you report and a number you later restate.

          
        
      
      
Nine statuses carry the order from pending payment to delivered, with cancelled, returned and failed ending it, and a delivery status per line so one brand shipping early does not misrepresent the rest of the bag.

    
  

  
    
      
        Deliberate
        
## Every Feature Earns Its Place

        
Feature lists are cheap. These are the ones that exist because a specific thing goes wrong in multi-brand fashion without them.

      
      
        
| Capability | Why it is not optional |
| --- | --- |
| SKU rows with their own quantity | Because a medium selling out should not delist a style that still has smalls and larges on the shelf. On a shared stock number it does, and you lose the sale and the search position together. |
| Per-SKU price | Because end-of-season clearance in fashion is variant-level. One colour moves and another does not, and a discount that leaks across the whole style gives away margin you did not need to. |
| A return with its own status machine | Because apparel returns at rates no other category tolerates, and a refund handled as a flag settles twice eventually. At fashion volumes that is not a rounding error. |
| Automatic commission reversal | Because commission that does not reverse is revenue you will restate later. In a high-return category the gap between gross and kept is large enough that the reported number becomes fiction within a quarter. |
| Loyalty reversal on refund | Because points earned on goods that came back are a liability issued against revenue you did not keep, and in fashion the volume of returns makes that balance material quickly. |
| Stock returned to the SKU | Because a returned medium is a medium. Returning it to a style-level count means the size that is actually back in stock is invisible to the buyer looking for it. |
| Photo reviews | Because a garment on a model tells a buyer almost nothing about how it fits, and a garment on a real person tells them most of what they wanted to know. It is the cheapest conversion lever in the category. |
| Persistent wishlist | Because the second session is where fashion converts. A basket that empties between visits treats every buyer as a first-time buyer forever. |
| Brand as a first-class entity | Because buyers shop by label, and a brand you cannot merchandise, filter or follow is a text field rather than a reason for that brand to list with you. |
| A delivery status per line | Because a bag from three brands does not ship at once, and forcing one status onto it means the buyer is told something untrue about most of their order. |

      
      
None of these are exotic. They are the ten places where a marketplace demoed with a catalog of products stops working the moment the products are garments.

    
  

  
    
      
        Stack
        
## The Technology Behind the Features

        
Deliberately ordinary choices, because the developers who maintain this after handover should already know all of it.

      
      
        **Backend**Laravel 12 on PHP 8.2, organised into nWidart modules so AI, Blog and Tax are separable rather than tangled through the core.
        **Data**131 normalized MySQL tables with reversible migrations, soft deletes on customer, brand, agent and product rows, composite indexes on the hot paths, and append-only wallet histories.
        **API**One REST API in versions v1, v2 and v3 serving the storefront, the brand panel, the operator console and all three Flutter clients. Six surfaces, one contract.
        **Mobile**Three Flutter Android projects - buyer, brand and delivery agent - transferred into your repository unobfuscated. The projects compile for iOS; store builds are quoted separately.
        **Media**Multi-image galleries and video on a listing, plus image upload on reviews. In fashion the media layer is doing commercial work, not decoration, so it is part of the core rather than a plugin.
        **Payments**Eleven gateways integrated, plus operator-defined offline methods and cash on delivery, with settlement records held per gateway and per currency.
      
      
        
### Why the variant model is a schema decision, not a feature

        
Collapsing colour and size into SKU rows that each carry their own price and quantity is a choice made in the data model, and it is not one you can retrofit onto a live catalog with orders and returns already in it. A platform that models variants as options on a shared stock number will demo perfectly and then fail the first time you want to clear one colour or the first time a single size sells out. It is the reason a fashion marketplace is a different product from a commerce script, rather than a skin on one.

        
          **Laravel 12**PHP 8.2, nWidart modules
          **131**Normalized MySQL tables
          **Redis 7**Cache, queue, session
          **v1 / v2 / v3**REST API versions shipped
        
      
      
Everything above transfers into your repository. There are no encrypted files and no licence callback of any kind.

    
  

  
    
      
        Honest Readiness
        
## What Is Not Included in the Base Package

        
Everything above is in the base build and demonstrable in the live demo. These are not, and the hub names them as scoped work rather than implying them away.

      
      
        
### Scoped separately, or yours to own

        
- **A sizing layer**Named on the hub as scoped work. Size charts per brand, fit guidance, a size recommender - none of that ships. In fashion it is the single most requested addition and the one most likely to reduce your return rate, so price it deliberately rather than assuming it.
- **Exchanges rather than refunds**Also scoped. The base build handles a return as a refund, settling to wallet credit or back down the original rail. A true exchange - same style, different size, without money leaving the business - is a different flow and a separate quote.
- **Returns-logistics integration**The refund pipeline reconciles the money. Booking a reverse pickup with a courier, tracking the garment back and gating the refund on its arrival is an integration, and it is quoted separately.
- **iOS applications**Three Android builds ship. The Flutter projects compile for iOS, quoted as an add-on with signing and store submission.
- **Gateway credentials**Eleven gateways are integrated; each needs your own merchant account and its own approval.
- **SMS and email provider**Integration-required - your accounts, your sender reputation, your deliverability.
- **Firebase project**Push notifications across all three Android apps run through your own Firebase project.
- **OpenAI key**The AI module generates descriptions, SEO copy and alt text against your key, with per-feature token quotas and a per-call cost log.
- **Catalog data and photography**Products, imagery and brand recruitment are the business, and they are yours. In fashion the photography budget is frequently larger than the platform.
- **ISO 27001 and SOC 2**Neither certificate is held and neither is claimed. The platform is ready for the evidence gathering; certification is a separate programme.

      
      
The first three are the fashion-specific ones and they are related: a sizing layer reduces returns, exchanges keep the money inside the business when a return happens anyway, and returns-logistics closes the physical loop. Any serious apparel operator should scope all three at the start.

    
  

  
    
      
        
          Development Company
          
### See how Miracuves compares to agencies and freelancers

          
The deployment process, two modelled reference deployments, and how to test the variant model and the returns pipeline before you hire anyone - on the Development Company page.

        
        [See the comparison →](/myntra-clone/development-company/)
      
    
  

  
    
      
        FAQ
        
## Frequently Asked Questions

      
      
        
          
            What happens when one size sells out?
            Only that size becomes unavailable. Colour, size and any custom attribute resolve to SKU-level rows carrying their own price and quantity, so a sold-out medium never takes the listing down with it. The style keeps its search position and the smalls and larges keep selling.
          
          
            Can I discount one colour without discounting the style?
            Yes, and it is one of the main reasons to pick this over a general commerce script. Price sits on the SKU row, so an end-of-season markdown on one colour cannot leak onto another. On a shared stock number the usual workaround is to split the listing, which costs you the reviews and the ranking on it.
          
          
            How are returns handled?
            As core rather than as an exception, because apparel returns at rates no other category tolerates. A request carries a reason and evidence and walks its own status machine, which is what prevents a refund settling twice. It resolves as wallet credit or back down the original rail, commission on that line reverses automatically, loyalty points reverse with it, and stock returns to the specific SKU rather than to the style.
          
        
        
          
            Are exchanges supported?
            Not in the base build, and the hub says so plainly. A return settles as a refund - wallet credit or back down the rail that took the payment. A true exchange, where a buyer swaps a size without money leaving the business, is a different flow and is scoped and quoted separately, typically inside the two-to-eight week band. It is worth asking for early if your category runs on fit.
          
          
            Is there a size chart or size recommender?
            No. A sizing layer is named on the hub as scoped work rather than implied as included. Custom attributes will carry size as a variant dimension, but size charts per brand, fit guidance and any recommendation logic are an addition. It is the add-on most likely to pay for itself in a high-return category, so scope it at the start.
          
          
            Can buyers upload photos in reviews?
            Yes, image upload on reviews ships in the base build, and brands can reply to any review from their panel. In fashion this is the single most effective thing on a product page - a garment on a real person answers the fit question that a model shot cannot - and it costs you nothing to run.
          
        
      
    
  

  
    
    
      
        
## Sell out one size, then discount one colour

That is the demo worth asking for. Then return a garment and watch the commission and the loyalty points reverse with the money.

        [See Pricing](/myntra-clone/development-cost/)[Full Overview](/myntra-clone/)
      
    
  

  
  
    
      Explore
## Explore the Myntra Clone

Five pages on this product. You are on Features.

      
        [Overview
### The product page

Back to overview→](/myntra-clone/)
        You are here
### Features

What is included, by role.

        [Development Cost$2,799
### Fixed price

See exact pricing→](/myntra-clone/development-cost/)
        [Development Company
### Who should build it

Compare options→](/myntra-clone/development-company/)
        [Business Model
### How it earns

See the playbook→](/myntra-clone/business-model/)
      
    
  

  
    
    
      
        
## Ready to launch a multi-brand fashion marketplace?

        
Deploy in six days with the storefront, brand panel, delivery fleet and operator console included, SKU-level pricing and stock, a returns pipeline that reconciles, and full Laravel 12 source on infrastructure you own.

        [Talk to Us →](https://miracuves.com/schedule-consultation/)
      
      
        
          **Written by the Miracuves Product Team**·
          Reviewed for accuracy·
          Last updated **August 21, 2026**
        
        
          Miracuves · Myntra Clone Solution
          Feature set and scoped add-ons cross-verified against the live hub, 2026-08-21
        
      
    
  

				
				
				
				
						
					
			
						
				
					

  
    
      
        Disclaimer
        
Miracuves is an independent software development company. We are not affiliated with, connected to, sponsored by, or endorsed by **Myntra**.

        
          
            Why this name
            
“**Myntra** Clone” is used descriptively. It is how the software industry refers to building a platform with functionality similar to Myntra, and how clients search for it.

          
          
            Who built this
            
The entire design and codebase is built by our own team. The product contains no code, design, graphics, or content originating from the Myntra website or applications.

          
          
            Trademarks
            
**Myntra** and all other third-party names and marks are the property of their respective owners, referenced here solely to describe the category of software offered.

          
        
        [Read our full Legal Notice & Disclaimer →](/disclaimer/)
