# Why Horcrux — built for Bangladesh commerce

Why Horcrux starts with Bangladesh-first commerce, clear money boundaries, portable records and honest product limits.

## The product thesis

### Start with the market that is real

**Bangladesh is not a footnote.**

Horcrux begins with the way commerce actually moves here: BDT prices, Bangladesh addresses, cash on delivery, local delivery decisions and the operating rhythm of Asia/Dhaka. The first release is deliberately Bangladesh-first. Other countries can be configured, but selling, checkout, payments, shipping and orders remain closed outside the supported commerce market.

### Make the whole path visible

**A storefront is only the first handoff.**

A product becomes useful when the thread survives the handoffs: storefront to cart, checkout to order, order to stock, and order to fulfilment evidence. Horcrux puts those working surfaces in one merchant workspace instead of asking a growing business to reconstruct the truth across disconnected tools.

### Keep the money boundary clear

**COD is a first-class path, not a temporary compromise.**

A Bangladesh merchant can start on COD without waiting for a payment-provider setup. Optional online checkout uses the merchant's own verified SSLCommerz connection and settles directly to that merchant. Horcrux does not become the custodian of shopper funds, and it charges 0% transaction fee on both current plans.

### Earn trust by naming the edge

**A useful platform says what it does not do yet.**

That means Starter and Essential are the active plans, not a legacy catalogue. It means courier-provider release is separate from adapter code and plan capacity. It means custom storefront builds, Meta features and a merchant public API are not quietly presented as available. Limits are part of the product's honesty.

### Leave with your working record

**A platform should not need captivity to be valuable.**

Authorized staff can export merchant records and original media as a portable archive. Export is not a restore button, and it does not include credentials or platform secrets. That distinction is intentional: portability belongs to the merchant workflow; internal disaster recovery remains a separate platform responsibility.

## Canonical sources

[Horcrux public knowledge index](https://horcrux.app/llms.txt)
[Horcrux machine-readable manifest](https://horcrux.app/.well-known/horcrux.json)
