Fancy Clone Features: The Front Page Is a Decision
On a curated shop nobody uses the search box. Buyers arrive to be shown something rather than to find something, so what surfaces has to be an editorial choice you make rather than a ranking an algorithm produces. That single difference changes the rails, the deals, the CMS and the way placement is sold. Here is what ships, grouped by who touches it.
Request a Live Demo →See PricingFeature Set by Role
Six surfaces on one REST API. On a curated shop the operator is a merchandiser rather than an administrator, so their column is the one that describes the actual product.
Buyer
- Arrives at a front page composed rather than generated
- Featured, most-demanded, best-selling and best-rated rails
- One daily deal and time-boxed flash events
- Editorial posts and CMS pages beside the products
- Product pages with galleries, video and photo reviews
- Wishlist and save-for-later that persist between sessions
- One basket spanning several sellers, shipping per seller
- Coupon, wallet credit and loyalty points applied together
Seller
- Registers with KYC, approved and suspendable by an operator
- Product CRUD with variants, stock and multi-image galleries
- Applies to join a flash event rather than assuming a slot
- Buys banners and sponsored positions on browse pages
- A plan tier that decides which rails they are eligible for
- AI-assisted descriptions, SEO titles and image alt text
- Order queue, refund responses and review replies
- Wallet with commission visible and a withdrawal request flow
Delivery Agent
- First-class identity with KYC, approval and zone assignment
- Assignment feed with accept and reject
- Navigation to the seller 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
Merchandiser
- Sets every rail by hand, plus per-product featured control
- Schedules the daily deal and time-boxed flash events
- Sets per-product discounts inside an event
- Publishes blog posts and CMS pages from the same console
- Sells and places banners and sponsored positions
- Approves which sellers join an event, and charges for it
- Moderates the catalog with approve, reject and bulk actions
- Eight report types over any date range, to Excel, CSV or PDF
We list the fourth role as merchandiser rather than operator deliberately. On this model the person composing the front page is doing commercial work every day, not configuration once a quarter, and a platform that treats that as an admin task has misunderstood the business.
Fancy vs Miracuves Clone vs Building From Scratch
The same capability, three different paths. Every row that separates them is a merchandising row, because on a curated shop that is the product.
| Capability | Original Fancy | Miracuves Clone | Generic commerce script |
|---|---|---|---|
| What surfaces on the front page | Curated, that was the whole proposition | Four rails set by you, plus per-product featured control - an editorial decision rather than an output | A newest-first grid, or a plugin's guess |
| Scheduled scarcity | Central to the model | One daily deal and time-boxed flash events with per-product discounts, both scheduled from the console | A sale price field |
| Editorial content | Story-led throughout | A Blog module and CMS pages on the same site as the products, not a marketing microsite | A separate blog nobody links to |
| Placement as a product | Yes | Paid banners, sponsored positions and an event participation fee - position you control and can therefore sell | Nothing to sell, because the algorithm gives it away |
| Who decides ranking | Editors | You do. There is no recommendation engine in the base build, stated plainly, and on an editorial shop that is the point | An opaque relevance score |
| Multi-seller catalog | Yes | Seller KYC and approval, moderation with bulk actions, commission at four levels, payouts on one ledger | Usually single-seller |
| Basket across sellers | Yes | One basket spanning several sellers, shipping estimated per seller, a delivery status per line | One seller per 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 merchandising |
The fifth row is the one people misread. Having no recommendation engine sounds like a gap until you remember what you are buying: on a shop where the front page is the product, an algorithm choosing it takes the business away from you and gives you nothing to sell.
How It Works, End to End
A product going from a seller's catalog onto a curated front page and out to a buyer - traced through every decision a person makes along the way.
A seller lists, and waits to be chosen
Registration with KYC and operator approval, then product CRUD with variants, stock and galleries. Listing is where a seller's control ends on this model - what happens next is your decision, and both sides understand that from the outset.
Moderation is an editorial filter, not a compliance check
The queue has approve, reject and bulk actions, and the operator keeps full editing rights over any listing. On a curated shop rejection is a normal outcome rather than an exception, because the standard is fit with the shop rather than merely being a legitimate product.
You compose the front page
Featured, most-demanded, best-selling and best-rated rails, plus per-product featured control. Some of those draw on real signal and some are entirely your choice, and the mix is itself an editorial position. Nothing appears because a relevance score put it there.
Scarcity and timing get scheduled
One daily deal, plus time-boxed flash events carrying per-product discounts. Curated commerce runs on scarcity and timing far more than on price, and both are scheduled from the console rather than improvised with a sale field.
The story ships next to the product
A Blog module and CMS pages are part of the platform, so the editorial around a drop lives on the same site as the thing it is about. On a shop where buyers arrive to be shown something, the writing is part of the merchandising rather than a marketing afterthought on another domain.
Sellers pay for the position you control
Paid banners, sponsored positions on browse pages, and a participation fee for joining an event. Because the front page is finite and curated, position is genuinely scarce, which is exactly why sellers will pay for it in a way they never pay for a search ranking.
The order settles like any marketplace order
One basket across several sellers, nine order statuses with a delivery status per line, a returns pipeline with its own status machine, commission taken on completion and reversed on refund, and four wallets each writing an append-only history row inside the same transaction as the balance move.
Steps three to six are the ones that do not exist on a conventional marketplace. Everything else on this list is the same commerce machinery underneath, which is deliberate - the curation is a layer on solid plumbing rather than a substitute for it.
Every Feature Earns Its Place
Feature lists are cheap. These are the ones that exist because a specific thing goes wrong on a curated shop without them.
| Capability | Why it is not optional |
|---|---|
| Rails set by hand | Because on a shop where nobody searches, the front page is the shop. A rail generated from a relevance score is a shop assembled by something you cannot question, argue with or sell a position on. |
| Per-product featured control | Because curation happens at the item level, not the category level. Without it your editorial choices are limited to whatever buckets someone else defined. |
| A scheduled daily deal | Because a reason to return today is the entire retention mechanism on an editorial shop. Scheduled means it happens whether or not anyone remembers to do it. |
| Time-boxed flash events | Because scarcity only works if it genuinely ends. An event with a start and an end that the platform enforces is a different commercial instrument from a discount someone forgets to remove. |
| Per-product discounts inside an event | Because a flat event discount either gives away margin on the items that would have sold anyway or fails to move the ones that needed help. |
| A blog and CMS on the same site | Because the story is part of what you are selling. Put it on a marketing microsite and it earns neither the sale nor the search position, and it stops being merchandising. |
| Paid banners and sponsored positions | Because position you control is inventory. A marketplace that hands ranking to an algorithm has given that inventory away for nothing and cannot get it back. |
| An event participation fee | Because being in the drop is worth money to a seller. Charging for it converts your editorial calendar into a revenue line without touching anyone's commission rate. |
| Plan tiers tied to rail eligibility | Because on this model a seller's tier is mostly about which rails they can appear in. That makes the upgrade argument concrete rather than a list of dashboard features. |
| Moderation with bulk actions | Because rejection is a normal outcome here, not an exception, and an editorial filter that can only be applied one row at a time becomes a bottleneck on your own standards. |
None of these are exotic. They are the ten places where a marketplace built for search-led shopping stops working on a shop where nobody searches.
The Technology Behind the Features
Deliberately ordinary choices, because the developers who maintain this after handover should already know all of it.
Why there is no recommendation engine, and why that is stated rather than hidden
Most marketplace platforms would list a recommendation engine as a headline feature and be vague about how good it is. This one says plainly that there is not one in the base build. For an editorial shop that is a positioning decision rather than a shortfall: the value you are selling is your judgement about what is worth showing, and an algorithm that overrides it is actively working against the proposition. If you later want a recommendation layer, placement bidding or rail analytics, all three are named on the hub as scoped work and quoted separately - which is a more honest arrangement than shipping a weak recommender and calling it included.
Everything above transfers into your repository. There are no encrypted files and no licence callback of any kind.
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 rather than implying them away.
Scoped separately, or yours to own
- A recommendation layerThere is no recommendation engine in the base build, and the hub states that plainly rather than burying it. On an editorial shop that is a deliberate position - your judgement is the product - but if you want algorithmic recommendation alongside the curated rails, it is scoped and quoted separately.
- Placement biddingBanners, sponsored positions and event participation fees all ship as things you price and sell. An auction where sellers bid against each other for a slot is a different mechanism, and it is scoped work.
- Rail analyticsThe eight standard report types ship. Measuring which rail converted, what a featured slot was worth and how a flash event performed against a baseline is scoped separately - and on this model it is the addition most likely to change how you merchandise.
- iOS applicationsThree Android builds ship. The Flutter projects compile for iOS, quoted as an add-on with signing and store submission.
- Gateway credentialsEleven gateways are integrated; each needs your own merchant account and its own approval.
- SMS and email providerIntegration-required - your accounts, your sender reputation, your deliverability.
- Firebase projectPush notifications across all three Android apps run through your own Firebase project. On a shop built around daily deals and drops, push is doing real commercial work.
- OpenAI keyThe 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 editorialProducts, imagery, seller recruitment and the writing itself are the business. The Blog module ships; the point of view does not.
- ISO 27001 and SOC 2Neither certificate is held and neither is claimed. The platform is ready for the evidence gathering; certification is a separate programme.
Rail analytics is the one worth scoping early if you can. Curating without measuring is possible - people did it for a century - but knowing what a featured slot is actually worth is what turns placement from a price you guessed into a price you can defend.
See how Miracuves compares to agencies and freelancers
The deployment process, two modelled reference deployments, and how to test the rails, the daily deal and a flash event before you hire anyone - on the Development Company page.
Frequently Asked Questions
Is there a recommendation engine?
How much of the front page can I actually control?
How do flash events work?
Is the blog part of the platform or separate?
Can I sell placement to sellers?
Is the commerce underneath a full marketplace?
Compose a front page in front of us
Set a rail, feature a product, schedule tomorrow's deal and open a flash event. Fifteen minutes, and you will know whether the merchandising is real.
Explore the Fancy Clone
Ready to launch a marketplace you curate?
Deploy in six days with operator-set rails, a scheduled daily deal, time-boxed flash events, a blog and CMS inside the platform, placement you can sell, and full Laravel 12 source on infrastructure you own.
Talk to Us →Miracuves is an independent software development company. We are not affiliated with, connected to, sponsored by, or endorsed by Fancy.
“Fancy Clone” is used descriptively. It is how the software industry refers to building a platform with functionality similar to Fancy, and how clients search for it.
The entire design and codebase is built by our own team. The product contains no code, design, graphics, or content originating from the Fancy website or applications.
Fancy 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.
