Dhaka, Bangladesh

Built in Dhaka, for the way Bangladesh actually sells.

Cash on delivery, mobile wallets and Bangla storefronts aren't edge cases we patched in. They're the starting assumption of every table in our database.

Read the origin thesis See open roles

The origin thesis

Most commerce software wasn't built for this market.

A Bangladeshi merchant packing an order in her shop — The merchants the platform is built around.

Most commerce software sold into Bangladesh was designed somewhere a credit card is the default payment method, a national address system is machine-parseable, and the storefront's primary language uses a single case and no conjunct consonants. None of that describes this market. When that software arrives here, "localisation" means a currency symbol, a translated button label, and a cash-on-delivery module maintained as a bolt-on plugin, usually by a third party, usually behind on updates.

That gap doesn't stay theoretical. It shows up as a merchant reconciling COD collections against courier remittance in a spreadsheet at midnight because the platform's ledger assumes every order clears through a payment gateway the moment it's placed. It shows up as a Bangla product title clipped mid-word because the theme's line-height was tuned for Latin ascenders and descenders, not for matras that need vertical room. It shows up as an SMS-OTP checkout flow built for a market where every customer has a stable email address and a laptop, in a market where the phone number *is* the identity and the checkout happens on a mid-range Android device over 3G.

We didn't start Framique to add a "Bangladesh mode" to an existing platform. We started it because the mismatch is structural — it lives in the data model, not the UI chrome — and structural mismatches can't be fixed with a translation file.

What imported commerce platforms assume, what the Bangladesh market actually does, what breaks, and Framique's structural answer
What imported commerce platforms assume, what the Bangladesh market actually does, what breaks, and Framique's structural answer	What the market actually does	What breaks	Framique's structural answer
Payment clears at checkout via card/gateway	The large majority of ecommerce orders in this market are cash on delivery, settled by the courier days later	Order status, revenue recognition and refund logic all assume a payment event that hasn't happened yet	Order state machine has a first-class cod_pending_settlement state; revenue and payout ledgers reconcile against courier remittance, not a gateway webhook
"Payment method" = card or PayPal	Mobile financial services — bKash, Nagad, Rocket — are the dominant digital rail	MFS bolted on as an unmaintained plugin; webhook retries and partial-capture edge cases silently drop	bKash/Nagad/Rocket are core payment adapters behind the same idempotent charge/refund/payout contract as cards — not a plugin tier
Address = street, city, state, ZIP, machine-geocoded	Many delivery addresses are landmark-based ("beside X mosque, 2nd lane") and courier-zone-based, not GPS-precise	Checkout forces invalid ZIP formats or silently mis-routes to the wrong courier hub	Address model captures courier zone + landmark field as first-class, not a "notes" afterthought
One script, one case, fixed line-height tuned for Latin	Bangla script: no case, conjuncts, matras that extend above/below the baseline	Bangla headlines clip descenders; negative letter-spacing (right for Latin) breaks legibility	A bangla-display typography token: zero letter-spacing, 1.35+ line-box, applied automatically to any lang="bn" subtree
Fulfilment = one integrated carrier API	Merchants route between Pathao, Steadfast, RedX, Sundarban and others by zone, cost and reliability, often per order	Single-carrier integrations force merchants into a courier's economics, not their own	Courier layer is a multi-provider abstraction merchants configure and switch without replatforming
Merchant support = ticket queue in a time zone 10+ hours away	Merchants need same-business-day answers in Bangla during BST hours, often about a stuck COD parcel	A long ticket SLA on a problem that's costing a merchant sales today	Support operates in BST, in Bangla and English, with COD/courier issues treated as P1
Tax/VAT logic assumes one national scheme, English-only invoices	Bangladesh VAT rules and invoice formatting change by legal year and require Bangla-legible receipts	Manual invoice patching every fiscal year	VAT computation versioned per legal year in the ledger, invoices render Bangla by default

Every row in that table is a decision we made once, in the schema or the type system, so it doesn't have to be re-decided — or worked around — by every merchant, every day. That's the thesis: commerce infrastructure that fits this market has to be built from the transaction outward, not from a Western storefront inward with a translation layer stapled on.

Operating principles

Principles paired with a forbidden behaviour and a real decision.

1. Ship what's true

Forbidspublishing a metric, a customer count or a feature name before it is queryable in production.Producedthis site has no "trusted by X merchants" banner until that number is pulled from a live query, not typed by marketing.

2. The merchant owns the data

Forbidsany export flow that is throttled, paywalled, or missing fields present in the UI.Produceda full-account export (orders, customers, products, ledger) ships as a background job any merchant can trigger from settings, no support ticket required.

3. Local first, not local only

Forbidstreating BDT/COD/bKash support as a checkbox that blocks international growth.Producedcurrency is currency_code + amount_minor_int from day one, so a merchant selling in BDT today can add a USD price list without a schema migration.

4. Boring where it counts

Forbids"creative" solutions in money, auth or tenancy — the three places a clever shortcut becomes an incident.ProducedRedis runs noeviction on purpose. A dropped idempotency key would mean a customer gets double-charged; we would rather page an engineer at 3 a.m. than silently retry a charge.

5. Bangla is not a translation layer

Forbidsapplying Latin type rules (negative tracking, Latin line-height) to Bangla text and calling it "localised."Producedthe bangla-display token drops letter-spacing to zero and enforces a 1.35+ line box automatically on any lang="bn" subtree — a theme cannot ship a Bangla headline that clips a matra.

6. Cash is a payment method, not an exception

Forbidsmodelling COD as a workaround inside a payment system designed around instant gateway settlement.Producedcod_pending_settlement is a first-class order state with its own reconciliation view against courier remittance — not a manual spreadsheet a merchant keeps on the side.

7. Observability is a product feature, not an internal nicety

Forbidsshipping a feature merchants depend on without a metric, a log line and a trace a support engineer can use to answer "what happened to my order" in minutes, not days.Producedevery checkout, payout and webhook path is instrumented with withSpan before it ships — the same instrumentation we use to debug is the one the on-call engineer opens when a merchant reports a stuck order.

8. No lock-in, including ours

Forbidsarchitecture choices that only make sense if a merchant is stuck.Producedself-hostable stack (Supabase on plain Postgres, Redis with a Valkey swap path), exportable data, and no proprietary storefront markup that only renders inside our runtime.

Engineering philosophy

Infrastructure decisions we don't revisit per feature.

The product and engineering team reviewing work together — A small team shipping in short, reviewable slices.

Tenant isolation is enforced by the database, not remembered by developers

Every tenant table carries merchant_id; Postgres row-level security enforces isolation through security-definer helpers (is_merchant_member, has_merchant_role). Isolation is a test suite — negative assertions run on every release, not a code-review hope.

Zero vendor lock-in, by architecture rather than by promise

The application only ever reads SUPABASE_URL, SUPABASE_PUBLISHABLE_KEY, SUPABASE_SERVICE_ROLE_KEY and REDIS_URL — nothing in the codebase names a hosting provider. The same code path runs in a managed preview environment and on our own servers in production.

Self-hostable end to end

Postgres, Redis, payments aggregation, search and the full observability stack (Prometheus, Loki, Sentry, Grafana, Alertmanager) run as pinned, versioned services we operate ourselves — not managed SaaS with per-seat billing pressure on the tools we use to debug our own platform.

Every runtime dependency has a documented swap path

Supabase self-hosted is plain Postgres underneath — portable to bare Postgres and our own auth if ever required. Redis is noeviction-tuned but Valkey/KeyDB-compatible. Payments run through provider adapters behind one idempotent contract, so adding or removing a rail doesn't touch checkout code.

Merchant data is exportable in full, on demand

Not a CSV of the three most common tables — a full-account export (orders, customers, products, inventory movements, ledger entries) triggerable from account settings without a support request.

Observability is a product feature

Every checkout, payout and webhook path emits metrics, structured logs with trace_id/span_id, and traces through withSpan — a support engineer follows a merchant's stuck order from a Grafana panel to a Loki line to a Sentry trace in three clicks, because we designed the correlation, not because we happened to log enough.

Design philosophy

Bangla typography set the constraints. The five themes are what fit inside them.

Type systems built for Latin scripts assume every glyph sits between a baseline and a cap-height, with predictable ascenders and descenders. Bangla doesn't work that way: matras extend above the headline, and conjunct consonants stack vertically in ways that need genuine room, not a squeezed line-height borrowed from a Helvetica-tuned design system. Apply Latin negative tracking to Bangla — the aggressive, confident tracking that makes an English headline feel sharp — and Bangla text becomes harder to read, not sharper. Matras clip. Conjuncts collide.

So the type system doesn't have "a Bangla mode." It has a rule: any display token applied inside a lang="bn" subtree drops its letter-spacing to zero and enforces a 1.35+ line box, automatically, regardless of which theme a merchant has chosen. That single rule — decided once, in the type token layer — is why every storefront a merchant builds on Framique renders Bangla product names correctly without a merchant ever touching a CSS property.
From that constraint, and from the range of retail formats we saw merchants actually running — a boutique with five products and heavy storytelling, a 2,000-SKU wholesale catalogue, a B2B distributor quoting in bulk — five official themes emerged, not as marketing skins but as different answers to "how much room does this catalogue need, and how much of it is Bangla-first."

The five official themes: what each is built for, what it optimises, and its Bangla typography treatment
The five official themes: what each is built for, what it optimises, and its Bangla typography treatment	Built for	What its layout optimises	Bangla typography treatment
Classic	General retail, balanced catalogue size	Familiar grid, low cognitive load for first-time online shoppers	Bangla display at 1.4 line-box, product names never truncated mid-conjunct
Modern	Fashion, lifestyle, visual-first brands	Large imagery, minimal chrome, editorial pacing	Bangla headlines sit in oversized display slots with the same zero-tracking rule, no shrink-to-fit hacks
Landing	Single-product launches, campaign pages	One conversion path, no competing navigation	Bangla CTA copy set at button-token line-height so wallet names (bKash, Nagad) never wrap awkwardly
Supershop	High-SKU grocery/FMCG catalogues	Dense grid, fast filtering, price-forward cards	Tabular numerals for BDT prices sit flush against Bangla unit labels without baseline drift
B2B	Wholesale, bulk-order, quote-driven merchants	Tables, tiered pricing, MOQ logic front and centre	Bangla and English render at matched optical size in the same pricing table row — no language hierarchy

How we decide what to build

A public framework, not a black box.

Every roadmap request — from a merchant support ticket, a sales conversation, or an internal engineering proposal — is scored against the same four weighted criteria before it enters a sprint. The scoring is public internally and the outcome is traceable: any merchant can ask why a feature they requested ranked where it did.

The four weighted criteria every roadmap request is scored against
The four weighted criteria every roadmap request is scored against	Weight	What it measures	Example
Structural fit	35%	Does this fix a mismatch in the core data model, or does it patch a symptom?	A cod_pending_settlement reconciliation view scores high; a one-off CSV export for one merchant's edge case scores low
Reach	25%	How many merchants, across how many themes/tiers, does this unblock?	A courier-abstraction improvement affecting all five themes outranks a single-theme cosmetic request
Reversibility risk	20%	Can we ship it, learn, and adjust without breaking tenant isolation, money correctness or data portability?	A new storefront section block is fast to reverse; a ledger schema change is not, and is scoped accordingly
Time-to-merchant-value	20%	Does this reduce a merchant's cost or reconciliation time within one release cycle, or is the payoff distant?	Faster courier-status sync scores higher than a long-horizon bet with no proven demand yet

A request needs a combined score above the current sprint threshold to be scheduled; below-threshold requests stay logged and re-scored every planning cycle as reach or evidence changes — nothing is silently dropped. Money, tenancy and auth changes always carry an additional gate regardless of score: an audit trail, a rollback-tested migration, and a negative-assertion test suite before merge. This is also why the roadmap sometimes says no to a request that would be an easy "yes" for an imported platform with different constraints — structural fit outranks a fast yes.

How we make money

We make money when merchants sell more, not when they're stuck.

Support staff helping merchants over phone and chat — Revenue funds support, not the other way round.

We make money when merchants sell more, not when they're stuck.

মার্চেন্ট যখন বেশি বিক্রি করে, আমরা তখনই বেশি আয় করি — মার্চেন্ট আটকে থাকলে নয়। ডেটা এক্সপোর্টে কোনো চার্জ নেই, নিজস্ব অ্যানালিটিক্স আনলক করতে বাড়তি খরচ নেই।

Framique's revenue comes from subscription tiers and a small percentage on payments processed through our in-house payments aggregation layer — the same layer that handles bKash, Nagad, Rocket, card and BNPL. We do not charge for data export, do not charge extra to unlock a merchant's own analytics, and do not take a cut of COD collections settled directly between a merchant and their courier. See pricing.

That alignment matters for a structural reason: a platform that earns more when a merchant is confused, locked in, or paying for a feature they can't turn off has every incentive to keep the interface complicated and the exit expensive. A platform whose revenue tracks a merchant's actual sales volume has the opposite incentive — churn and stagnation cost us directly, so the roadmap is scored, in part, against whether it grows a merchant's revenue, not just our own feature count.

This is also why self-hosting and full data export aren't compliance checkboxes here — they are a commitment that a merchant's ability to leave stays real, which is the only thing that keeps a subscription-and-take-rate business honest over time.

Where things stand

Numbers, read live, not typed.

Payment rails wired end to end

The people building this.

We're a small team in Dhaka — engineering, merchant success and support — building infrastructure we'd want to run our own store on. Team profiles are going up here as people opt in to appear publicly. In the meantime, our careers section lists what we're hiring for, and our contact page reaches the team directly.

See open roles

We're hiring in Dhaka.

আমরা ঢাকায় নিয়োগ দিচ্ছি।

Engineering, merchant support and merchant success. Remote-friendly within Bangladesh; BST core hours.

ইঞ্জিনিয়ারিং, মার্চেন্ট সাপোর্ট এবং মার্চেন্ট সাকসেস টিমে। বাংলাদেশের ভেতরে রিমোট-ফ্রেন্ডলি।

Comfort with the structural constraints named in the origin thesis — this isn't a "port a Shopify clone" job.
Bangla writing and reading fluency for support, merchant success and content roles.
For engineering: willingness to work close to money, tenancy and auth with real rigor — this is not the team for "ship fast, fix later" on the ledger.

See open roles Send a speculative note

Commitments, not aspirations.

We will never sell or broker merchant customer data.

Analytics stay inside the merchant's own account; we don't monetize a second time on data collected for their storefront.

We will never lock storefront data into a format only our runtime can read.

Exports are structured, documented and importable elsewhere.

We will never make COD or MFS payments a paid add-on tier.

They are core payment rails, not premium features, because for this market they are not optional.

We will never publish a metric on this site that isn't backed by a live, queryable number.

See "Ship what's true."

We will never require a support ticket to export data or close an account.

Both are self-service.

We will never apply Latin typographic rules to Bangla text and call it localisation.

See Design Philosophy.

We will never take a cut of COD cash settled directly between a merchant and their courier.

See How We Make Money.

We will never ship a money, tenancy or auth change without an audit trail and negative-assertion tests.

No exceptions for deadline pressure.

আমরা কখনও মার্চেন্টের কাস্টমার ডেটা বিক্রি বা শেয়ার করব না। অ্যানালিটিক্স মার্চেন্টের নিজস্ব অ্যাকাউন্টের ভেতরেই থাকে।

Questions a skeptical buyer would ask.

Is Framique only for merchants selling in Bangladesh?

No. BDT and Bangla are the defaults, not a ceiling — see "Local first, not local only" in our principles. Merchants can add other currencies and languages as they expand; nothing about the core schema assumes BDT-only.

How is this different from installing a COD plugin on Shopify or WooCommerce?

A plugin adds a field to a payment flow designed around instant gateway settlement. Framique's order state machine has cod_pending_settlement as a native state from the schema up, so reconciliation against courier remittance is a built-in view, not a spreadsheet a merchant maintains separately.

Can I export all my data if I decide to leave?

Yes, in full, on demand, from account settings — orders, customers, products, inventory movements and ledger entries — with no support ticket and no throttling.

Is Framique open source or self-hostable?

The platform is built on a self-hostable stack: Postgres via self-hosted Supabase, Redis, an in-house payments aggregator, and a self-hosted observability stack.

Which couriers does Framique support?

Multiple providers behind a single abstraction merchants configure and switch between by zone, cost and reliability — see Engineering Philosophy.

Do I have to use one of the five official themes, or can I customize further?

The five themes (Classic, Modern, Landing, Supershop, B2B) are starting points tuned for different catalogue shapes; each is customizable within the shared token system.

How does Bangla typography actually work under the hood — is it just a font swap?

No — it's a token rule: any display type applied inside a lang="bn" subtree automatically zeroes letter-spacing and enforces a taller line box, regardless of theme.

What happens to my payout if bKash or a courier has an outage?

Idempotent charge/refund/payout contracts and a Redis noeviction policy mean a retry never becomes a duplicate transaction; if a dependency is down, we fail loudly and page an engineer rather than silently degrade correctness.

How do you decide what feature to build next — can I influence it?

Every request is scored against four public criteria (structural fit, reach, reversibility risk, time-to-merchant-value). Support and sales requests enter the same scoring queue as internal proposals — there isn't a separate, opaque list.

Who actually owns and operates Framique, and where is the company based?

Legal entity, address and incorporation details are published on our contact page and in this page's Organization structured data.

See it running before you take our word for it.

Walk through a live demo storefront and admin, or talk to the team about migrating from what you run today.

See open roles Talk to us