One platform. Every part of the sale.
Storefront, catalogue, checkout, fulfilment, point of sale and analytics — designed as one system, not six plugins glued together with webhooks.
Six pillars
Every pillar, one map.
Storefront & builder
Catalogue & inventory
Checkout & payments
Fulfilment & couriers
POS & omnichannel
Analytics & API
One product, many surfaces
The unified data model.
Most Bangladeshi merchants we've spoken with run at least three tools that each think they own the product record: a storefront theme, a spreadsheet for stock, and a courier panel for order status. Framique treats a product as one row with fan-out, not three rows kept in sync by hand.
A product has a canonical ID. Everything else — its storefront listing, its POS button, its stock ledger entry, its analytics dimension, its order line item — reads and writes against that same ID. There is no import job, no CSV round-trip, no "sync in progress" spinner between your shop and your counter.
| What updates automatically when you edit one field | What updates without a second click |
|---|---|
| Price in the builder | Storefront price, POS price, API price, cart already open on a customer's phone (on next fetch) |
| Stock count at checkout | Available-to-sell number on storefront, POS, and low-stock alerts |
| Bangla product name | Storefront (bn locale), receipt printed at POS, order confirmation SMS |
| Variant options (size/colour) | SKU generation, per-variant stock, per-variant price, courier weight used for rate lookup |
| Order status from courier webhook | Order timeline, customer tracking page, analytics fulfilment-time metric |
Assume a merchant sells a printed panjabi in three sizes and two colours — six SKUs from one product. A customer orders the medium, white variant from the storefront at 9:40pm. At 9:41pm the merchant sells the last medium, white unit in person at a physical counter using POS. Framique decrements the same stock ledger row twice, in order, and the storefront listing shows "out of stock — this size" before a third buyer can add it to cart. No separate stock file, no evening reconciliation.
The builder is where the shop becomes yours.
Drag sections, edit design tokens, publish a version — with instant rollback if a change hurts conversion. Every publish is a snapshot, not an overwrite.
Every publish is a version. Every version can be restored.| The builder is where the shop becomes yours. — capability table | What it does | Who uses it |
|---|---|---|
| Section library | Hero, product grid, testimonial-free trust bands, FAQ, footer — drag to reorder | Store owner, no developer |
| Token editor | Colour, type scale, spacing per store, inherited by every section | Store owner or designer |
| Version history | Every publish snapshotted; rollback in one click | Store owner |
| Custom domain | Point your own domain, TLS issued automatically | Store owner |
| Draft/preview links | Share an unpublished version before go-live | Store owner, agency |
| Mobile-first canvas | Every section authored mobile-first, desktop is the enhancement | Builder engine |
How a merchant actually uses this on a Tuesday
It's Eid-collection week. The merchant wants to swap the homepage hero for a festive banner without touching the rest of the site. She opens the builder, drags the existing hero section down one slot, drops in a new hero pointed at the Eid collection, and previews it on a draft link she sends to her business partner over WhatsApp. Her partner replies "the button colour is too dark to read" — she opens the token editor, nudges the CTA fill token, and the change propagates to every section using that token, not just the hero. She publishes. Forty minutes later a return customer complains the homepage looks different and she preferred the old layout — she opens version history and rolls back to the version from three days ago in one click, then re-applies just the button-colour fix on top of it.
Catalogue that speaks Bangla natively.
Options and variants generate real SKUs, each with its own stock and price. Bangla names and descriptions live on the same product record — not a translated mirror site.
One SKU, two languages, one stock number.| Catalogue that speaks Bangla natively. — capability table | What it does |
|---|---|
| Options & variants | Up to 3 option dimensions (e.g. size, colour, material) auto-generate SKUs |
| Per-variant stock | Each SKU carries its own available-to-sell count, reserved count, and reorder threshold |
| Bilingual fields | Name, description and search tags stored per-locale on one product record |
| Bulk import/export | CSV round-trip for merchants migrating an existing catalogue |
| Low-stock alerts | Threshold per SKU, notification to owner and to any staff role with catalogue access |
| Category tree | Nested categories with per-category storefront sort order |
How a merchant actually uses this on a Tuesday
A saree wholesaler restocks 40 units of a print across four colourways. She uploads a CSV with the new stock counts against existing SKU codes rather than recreating products from scratch. Before publishing the import, the system flags three rows where the SKU code doesn't match anything in the catalogue — likely a typo — so she fixes them in the CSV rather than silently creating four duplicate products. Stock updates instantly on the storefront and at the counter. That afternoon a customer messages in Bangla asking whether the maroon colourway is available in the largest size; the staff member checks the same product page, reads the Bangla name and description, and can answer from the same screen without switching to a translated mirror site.
Checkout built around cash on delivery.
COD is a first-class method, not a fallback: it carries its own fraud rules, its own return path and its own reconciliation, alongside bKash, Nagad, Rocket, Upay and card.
COD returns land back on the order, automatically.| Checkout built around cash on delivery. — capability table | Reconciliation | Typical use |
|---|---|---|
| Cash on delivery (COD) | Matched against courier remittance report per order | Majority of first-time and rural buyers |
| bKash | Matched against bKash merchant statement, per transaction ID | Repeat urban buyers, small-ticket |
| Nagad | Matched against Nagad settlement report | Repeat urban buyers |
| Rocket | Matched against Rocket statement | Legacy mobile-money customers |
| Upay | Matched against Upay settlement | Growing segment, telecom-linked wallets |
| Card (Visa/Mastercard via gateway) | Matched against gateway settlement batch | Higher-ticket, urban, B2B |
How a merchant actually uses this on a Tuesday
A customer in Rangpur adds three items to cart and chooses COD, because they've never paid this shop before and don't want to send money to an unfamiliar bKash number first. The order is created immediately with a fraud score computed from the customer's phone number, delivery area and order value — this one clears. The merchant's staff hand it to the courier that afternoon. Two days later the customer refuses one item at the door. The courier logs a partial return; Framique receives that status and updates the order to reflect the returned item and the adjusted amount actually collected, without the merchant needing to manually edit the order total or issue a separate refund record.
Labels, pickups and delivery status inside the order.
Book a courier, print a label and watch delivery status update on the order timeline — no separate courier dashboard open in another tab.
One order. One timeline. Every courier update lands on it.| Labels, pickups and delivery status inside the order. — capability table | Booking | Rate lookup | Status webhook |
|---|---|---|---|
| SteadFast | In-order booking | By weight + area | Live |
| Pathao Courier | In-order booking | By weight + area | Live |
| RedX | In-order booking | By weight + area | Live |
| Paperfly | In-order booking | By weight + area | Live |
| Manual/own rider | Manual status entry | N/A | Manual update |
How a merchant actually uses this on a Tuesday
Ten orders came in overnight. The merchant opens the order queue, filters to "ready to ship," and books all ten with one courier in a single batch action rather than opening each order separately. Labels print as a single PDF batch. Two hours later, one parcel is marked "failed delivery attempt" by the courier's webhook; that status appears on the order timeline automatically and the order moves into a "needs follow-up" view without anyone refreshing a courier's own tracking page. The merchant calls the customer, reschedules, and re-books the same label rather than creating a duplicate order.
Same product, same stock, counter and web.
Ring up a sale at a physical counter and the storefront stock count moves in the same instant — because it's the same row, not a synced copy.
The counter and the storefront read the same stock ledger.| Same product, same stock, counter and web. — capability table | What it does |
|---|---|
| Counter sale flow | Barcode/search product, take payment (cash, bKash, card), print or SMS receipt |
| Shared stock ledger | Same availability number online and at counter, decremented at time of sale |
| Offline queue | Counter can take sales during a connectivity drop; syncs when back online |
| Staff shift log | Each POS sale is attributed to the logged-in staff account |
| Returns at counter | Refund or exchange against the original order, whether it was placed online or in person |
How a merchant actually uses this on a Tuesday
A shop has a small storefront and a physical counter in the same neighbourhood. A walk-in buys the last unit of a scarf that's also listed online. The staff member rings it up at POS; the online listing shows out-of-stock before the next online visitor can add it to cart. Later that day the shop's internet drops for twenty minutes during a routine outage — the counter keeps taking sales locally and queues them, syncing the stock decrements the moment connectivity returns, rather than freezing the till or trusting an outdated printed stock sheet.
Analytics you can defend in a meeting.
Every number traces to rows you can export. No modelled estimates, no rounded vanity metrics — and a REST API when you need the number somewhere else.
Every metric has a query behind it.| Analytics you can defend in a meeting. — capability table | What it does |
|---|---|
| Live revenue dashboard | Orders, revenue, average order value, updated per new order |
| Rail mix report | Share of revenue by payment method (COD/bKash/Nagad/Rocket/Upay/card) |
| Return-rate report | Returns by product, by rail, by delivery area |
| CSV export | Any report exports to CSV with the underlying row-level data |
| REST API | Products, orders, inventory, customers — read and write, token-scoped |
| Webhook events | Order created, order status changed, payment settled, stock threshold crossed |
How a merchant actually uses this on a Tuesday
At the end of the month, a merchant's accountant asks for the COD-versus-digital-payment split for a bank loan application. Rather than estimating, the merchant opens the rail-mix report, filters to the month, and exports the CSV — the accountant can trace every row back to an order ID if the bank asks for backup. Separately, the merchant's developer has built a small internal tool that emails a daily summary to the owner's phone; it polls the REST API for the previous day's orders rather than scraping the dashboard, because the numbers in the API and the numbers on screen are guaranteed to be the same query.
Integrations
Every rail, every courier — one checkout.
Payment rails and couriers
Reduced motion stops the track and falls back to a static wrapped list.
The five official themes — and when each fits
Framique ships five official themes today. Each is a starting point you can still edit token-by-token in the builder — choosing a theme is not a lock-in decision.
Classic
Modern
Landing
Supershop
B2B
If the catalogue is under 30 SKUs and centred on one collection, start with Landing. If it's a wide multi-category shop with daily repeat buyers, start with Supershop. If pricing depends on the buyer's account (trade, wholesale), start with B2B — its checkout flow assumes a login before price is shown. Everything else starts with Classic or Modern depending on whether the aesthetic priority is breadth (Classic) or image-led minimalism (Modern).
Multi-language, Bangla-first
Bangla is not a translated skin.
Product fields, storefront copy, receipts, SMS notifications and staff-facing labels are stored per-locale from the schema up. Type never clips a matra: Bangla display type keeps a 1.35+ line-height box and drops inherited Latin negative tracking to zero. A product page is one record, two reading experiences — editing the Bangla name field fills a locale slot on the same SKU, so stock, price and variant logic stay singular even when the storefront is bilingual.
English
Printed panjabi — size M
বাংলা
প্রিন্টেড পাঞ্জাবি — সাইজ এম
| Bangla support by surface | Bangla support today |
|---|---|
| Storefront (customer-facing) | Full: product, cart, checkout, order-status page |
| POS (staff-facing) | Full: search, product labels, receipt |
| Order confirmation SMS | Full, per-store default language setting |
| Analytics dashboard | English only today (see honesty band) |
| Admin/builder UI | English only today (see honesty band) |
Roles & permissions
Scoped by role, not by trust.
A shop is rarely run by one person. Framique scopes access by role rather than giving every logged-in staff member full owner access.
| Roles and permissions | Can see | Can do |
|---|---|---|
| Owner | Everything | Everything, including billing and staff management |
| Manager | Orders, catalogue, analytics | Edit catalogue, process orders and returns, cannot change billing |
| Catalogue staff | Products, stock | Add/edit products and stock, cannot see revenue reports |
| Counter/POS staff | Products, stock, POS sales | Ring up sales, process counter returns, no storefront/builder access |
| Fulfilment staff | Orders, courier status | Book couriers, print labels, update manual delivery status |
| Read-only/accountant | Analytics, exports | View and export reports, no edit access anywhere |
A shop owner hires a part-time counter assistant for Eid week. She's given the Counter/POS role — she can ring up sales and see stock, but cannot see the store's overall revenue report or change any product's price. When the temporary hire's contract ends, the owner deactivates the role in one action rather than needing to change a shared password everyone knew.
Automation & webhooks
The escape hatch for technical buyers.
Not every workflow fits inside the dashboard. Webhooks and the REST API let a merchant or their developer react to events the moment they happen.
| Webhook events and typical automations | Typical automation built on it |
|---|---|
order.created | Send a custom WhatsApp confirmation via a third-party messaging tool |
order.status_changed | Trigger an SMS when a courier marks a parcel out for delivery |
payment.settled | Push a row into an external accounting spreadsheet or tool |
inventory.threshold_crossed | Notify a supplier's messaging channel to trigger a reorder |
customer.created | Add the customer to an email or SMS marketing list |
A merchant's supplier only accepts reorders by a specific spreadsheet format sent over email. Rather than checking stock manually every few days, the merchant's developer subscribes to inventory.threshold_crossed, and a small script formats the affected SKUs into the supplier's expected spreadsheet and emails it automatically the moment stock crosses the reorder line — turning a recurring manual check into a one-time integration.
Read the webhook referencePerformance budget
A budget, not a vague "fast."
Storefronts are judged on load time by both customers on mid-range Android phones over 3G/4G and by search engines. Framique enforces a performance budget at the platform level rather than leaving it to each theme's discretion.
| Platform performance budget | Budget | Why it matters here |
|---|---|---|
| Largest Contentful Paint | ≤ 2.5s on a simulated mid-tier Android + 4G profile | Majority of storefront traffic in this market is mobile, not desktop |
| Total JS shipped per storefront page | ≤ 170KB gzipped | Keeps parse/execute time low on lower-end CPUs |
| Image delivery | Responsive srcset, WebP/AVIF with fallback, lazy below the fold | Product photography is heavy; this keeps it from dominating load time |
| Time to first byte | ≤ 400ms from a Bangladesh-region edge | Checkout abandonment correlates strongly with delay at this exact step |
What we do not do yet
Framique is not everything. Being direct about the edges of the current product saves an evaluating merchant time and avoids a bad-fit sale.
- No native marketplace listing sync (Daraz, Facebook Shop) yet — orders from those channels still need manual entry or a third-party connector.
- No built-in accounting/VAT filing — analytics exports the row-level data; a bookkeeper or an external accounting tool still does the filing.
- No multi-warehouse routing logic yet — stock is per-store today; a merchant with two physical warehouses currently manages them as one pooled stock number, not an automatic nearest-warehouse split.
- No built-in email marketing composer — webhooks and the API can feed an external tool, but there is no native campaign builder inside Framique yet.
- Admin/builder UI is English-only today — Bangla covers every customer-facing and staff-facing surface, but the merchant-side settings screens are not yet localised.
- No offline-first storefront — the POS has an offline sale queue; the customer-facing storefront requires connectivity to load and checkout.
One platform vs. stitching separate tools
| One platform vs. stitching separate tools | Stitched tools (typical setup) | Framique |
|---|---|---|
| Storefront | One theme platform (often foreign hosting, foreign payment defaults) | Built in, Bangladesh-first payment defaults |
| Payments | Separate gateway integration per rail, manual reconciliation spreadsheet | bKash/Nagad/Rocket/Upay/card/COD reconciled against orders natively |
| Inventory sync between web and counter | Manual recount or a third-party sync plugin, often lagging by hours | Same stock ledger, same instant |
| Courier booking | Log into each courier's own panel separately, copy tracking numbers back into orders by hand | Booked from the order, status returns automatically |
| Bilingual catalogue | Duplicate product records in two languages, kept in sync manually | One product, two locale fields |
| Reporting | Export from each tool, reconcile in a spreadsheet before a meeting | One dashboard, exportable, one query per metric |
| Staff access | Shared logins or no access control at all | Role-scoped accounts per staff function |
| Point of integration failure | Each sync job is a place data can silently drift | One data model — nothing to keep "in sync" because there's one record |
Frequently asked
Does Framique support bKash, Nagad, Rocket and Upay at checkout, or only card payments?
Can I keep cash on delivery as my main payment method?
Which couriers can I book directly from an order?
Is the storefront actually bilingual, or is Bangla just a translated overlay?
How many storefront themes are available, and can I customise them?
Do the physical counter and the online storefront share the same stock count?
Can I limit what my staff can see and do?
Is there an API if I need to connect Framique to another tool?
What doesn't Framique do today that I should know before switching?
How fast does the storefront load on an average customer's phone?
See it against your own catalogue.
Import your products, connect one payment rail and one courier, and judge the whole system on real data — not a demo store.