Design the storefront. Don't fight the theme.
Drag sections, edit tokens, ship a version — with instant rollback.
Same renderer, no surprises
The editor renders exactly what the storefront serves
Sections
Hero section
Product grid
Announcement bar
Testimonial strip
Live canvas
Tokens
Primary colour
Accent colour
Corner radius
Type scale
The same renderer draws the editor and the live store, so preview is not an approximation.
এডিটর ও লাইভ স্টোর একই রেন্ডারার ব্যবহার করে, তাই প্রিভিউ কোনো অনুমান নয়।
Most page builders run a simplified preview renderer that diverges from production CSS, web fonts, and JS at the margins — the classic "it looked right in the editor" complaint. Framique's editor iframe loads the identical theme bundle the storefront serves, so what you see in the canvas is pixel-identical to what a shopper on a Grameenphone 4G connection in Bogura sees.
The editing model
Sections, tokens, versions, sandboxing
Sections, not HTML
Sections, not a page of HTML.
Add a hero, a product grid, a testimonial strip, a Bangla-only announcement bar. Each section carries its own settings, its own Bangla copy, and its own visibility rules (device, audience segment, date window, A/B arm). Sections are drag-reordered on the rail; there is no way to "break the layout" by nesting divs incorrectly, because there are no divs to nest.
Per-section visibility by audience or experiment.Tokens, not scattered CSS
Tokens, not scattered CSS.
Colour, radius, type scale, and spacing live in one panel. Change the accent colour once and every button, badge, and link across every section updates together — no hunting through forty section-level colour pickers left over from a theme you customised eighteen months ago.
One token, every section.Versions, not fear
Versions, not fear.
Every publish is a version with an author and a timestamp. Compare two versions side by side, restore an older one, or roll back mid-campaign without opening a support ticket.
Rollback is one click, not a restore ticket.Custom code with a seatbelt
Custom code with a seatbelt.
Drop in HTML, a tracking pixel, or a third-party widget and it renders inside an isolated frame that cannot reach the DOM outside itself, so a broken script degrades gracefully instead of white-screening checkout.
Sandboxed widgets, isolated failures.Never ship by accident
Drafts, autosave, versioning, rollback, scheduled publish
Every keystroke in the builder writes to a draft, autosaved roughly every few seconds to a working copy that never touches the live store. Nothing you type in the canvas is visible to a shopper until you explicitly publish. This separation — draft vs. live — is the single most important safety property of the editing model.
| The publish lifecycle: stage, visibility, and reversibility | What happens | Who sees it | Reversible? |
|---|---|---|---|
| Draft | Autosaved continuously as you edit | Only you, in the builder | N/A — it is not shipped |
| Preview link | Shareable URL renders the draft outside the editor | Anyone with the link | Yes, expires or is revoked anytime |
| Scheduled publish | Draft is queued for a future timestamp | No one, until the clock hits | Yes, cancel before the scheduled time |
| Published (live version) | Draft becomes the numbered live version | All storefront visitors | Roll back to any prior version, one click |
| Rolled back | An earlier version is restored as current | All storefront visitors | Yes, roll forward again if needed |
Versions are numbered and immutable: version 14 always means exactly the sections, copy, and tokens it meant the day it went live, even after you publish version 15. If a Friday evening Eid promotion converts poorly, you can compare version 14 against version 13 side by side and roll back to 13 in one click, without a developer or a support ticket.
Scheduled publish decouples "when I finish the work" from "when the shopper sees it." A merchant working on a Ramadan sale page on a Tuesday night can queue it to go live at midnight, with zero manual action required at that hour.
Bounded choice
Five official themes, five business situations
Each is a complete section library, token set, and default layout — not a colour skin on top of one generic template.
Classic
Modern
Landing
Supershop
B2B
| Theme-choice decision table | Choose | Because |
|---|---|---|
| First store, moderate catalogue, strong photography | Classic | Safest default, smallest section library, image-forward |
| Small high-margin catalogue, strong brand identity | Modern | Editorial layout rewards fewer, better products |
| One hero product or campaign launch | Landing | Single-purchase-decision page, not a catalogue |
| Hundreds to thousands of SKUs, filter-driven browsing | Supershop | Density and filters over inspiration |
| Wholesale, quote-based, or account-gated pricing | B2B | Tiered pricing and MOQ built in, not bolted on |
| Unsure, catalogue will grow past 50 SKUs in a year | Classic → migrate later | Cleanest section model to extend |
Single source of truth
Design tokens and brand consistency
A token panel holds four families: colour (primary, accent, surface, text), radius (from sharp to fully rounded), type scale (a ratio-based ladder from caption to display), and spacing (a fixed step scale, not freeform pixel entry). Every section in every theme reads from these tokens rather than hard-coding its own values, so a brand refresh is a five-field edit, not a section-by-section rebuild.
A merchant rebranding from a teal to a maroon accent for Pohela Boishakh changes one colour token. That single change updates the "Add to cart" button, the sale badge, the active nav underline, and the checkout progress bar simultaneously — four surfaces, one edit, zero risk of shipping a mismatched button colour on launch day.
Token changes are draft-scoped like everything else: preview a full rebrand before publishing it, compare it against the live version, discard it without consequence if it doesn't work.One record, two languages
Bangla + English from one catalogue
একই ক্যাটালগ থেকে বাংলা ও ইংরেজি
Every product, section, and piece of storefront copy in Framique has one Bangla field and one English field living on the same record — not two parallel catalogues that must be kept in sync by hand. A shopper's browser or a manual language switch decides which one renders; the merchant edits both from the same product screen.
Framique-এর প্রতিটি পণ্য, সেকশন ও স্টোরফ্রন্ট কপির একটি বাংলা ও একটি ইংরেজি ফিল্ড একই রেকর্ডে থাকে — হাতে সিঙ্ক রাখা দুটি আলাদা ক্যাটালগ নয়।
A large share of Bangladeshi online shoppers convert better against Bangla product names, sizes, and care instructions even when they can read English, because purchase-stage cognitive load is lower in the first language. A storefront that only offers English at checkout reintroduces exactly the friction the bilingual catalogue was meant to remove.
Any token applied to a lang="bn" subtree drops letter-spacing to 0 (Bengali conjuncts and matras clip under Latin negative tracking), and Bangla display text keeps a minimum 1.35 line-height box — enforced by the renderer, not left to merchant discipline.Friction as feature
Custom fonts and custom code, with guardrails
Custom fonts — licence attestation and weight budget
Uploading a custom font requires an explicit licence attestation: the merchant confirms they hold a web-embedding licence for the exact weights being uploaded, logged with a timestamp against the account. Framique does not verify licence terms with the foundry — this is a legal attestation step, not a rights-management product.
The font-weight budget exists for a performance reason: each additional weight of a custom font is a separate network request and a separate render-blocking asset on first paint. The builder enforces a soft ceiling of two weights per custom font family and flags a warning if a merchant tries to load more.
A merchant uploads a five-weight custom Bangla-Latin pairing. The builder warns that only two weights are budgeted; the merchant keeps Regular and SemiBold and defers the rest. Measured effect: roughly 90–140 KB of font payload removed from the critical rendering path — often the difference between meeting and missing the 2.0s LCP target.
Custom code — sandboxing and secret scanning
The custom code section accepts HTML, CSS, and script snippets — a live chat widget, a tracking pixel, a small interactive embed — and renders them inside an isolated iframe with no access to the parent page's DOM, cookies, or checkout state. If the embedded script throws an error or hangs, the failure is contained to that one section; the rest of the storefront, including checkout, keeps functioning.
Before any custom code snippet is saved, it passes through secret scanning: a pattern check for API keys, access tokens, and credential-shaped strings a merchant might have pasted in by accident. A match blocks the save and shows exactly which line triggered it, so the credential can be removed before it is ever published to a public HTML source.
Made-concrete abstraction
Performance budgets — why LCP matters for BDT conversion
Largest Contentful Paint (LCP) is the performance metric most correlated with whether a Bangladeshi mobile shopper stays on a product page long enough to scroll to "Add to cart." A large share of retail traffic in Bangladesh arrives over 3G/4G mobile data with variable latency, and every additional second of blank-screen wait is a second of attention and mobile data spent on nothing.
| Framique's stated performance budgets for any published storefront | Budget |
|---|---|
| Hero LCP asset | ≤ 90 KB |
| Any other image | ≤ 140 KB |
| LCP target (mid-tier Android / 4G) | ≤ 2.0 seconds |
| Motion | Transform / opacity only |
| prefers-reduced-motion | Full fallback on every animated element |
Worked example (stated assumptions, not a measured claim): 10,000 monthly mobile sessions, converting at 2.0% (200 orders) at a fast load time. An unbudgeted 900 KB hero image (versus the 90 KB ceiling) adds roughly 2.5s to LCP. At a commonly cited 7%-per-second conversion drop, that implies conversion falling to roughly 1.65% (165 orders) — 35 fewer orders. At an assumed average order value of 1,200 BDT, that is approximately 42,000 BDT of assumed monthly revenue attributable to one unbudgeted hero image. The arithmetic is the point, not the exact numbers.
The builder enforces the budgets at publish time: an oversized hero image is flagged with its actual file size and the ceiling it exceeds, and the merchant is offered an automatic compressed version before the version can go live.
Checklist completeness
Anatomy of a high-converting Bangladeshi product page
- 1.Product title in Bangla, with the English name in parentheses if it aids search
- 2.Price shown in BDT with the Taka symbol, never a bare number
- 3.At least one image showing scale or the product in a hand/on a body
- 4.Discount badge only if the original price is genuinely shown struck through nearby
- 5.Stock status stated plainly ("In stock", "Only 4 left", "Restocking [date]")
- 6.Delivery estimate by area (inside Dhaka vs. outside Dhaka)
- 7.COD availability stated explicitly
- 8.bKash/Nagad/Rocket/Upay logos shown near the price, not buried at checkout
- 9.Return/exchange policy in one sentence, in Bangla, linked to the full policy
- 10.Size or variant guidance specific to the product category
- 11.At least one section addressing a common pre-purchase doubt (durability, authenticity, warranty)
- 12.A visible, sticky "Add to cart" / "Order now" action that survives scroll on mobile
- 13.Related or complementary products below the fold, not above it
- 14.Contact channel visible (WhatsApp, phone, Messenger)
- 15.Page weight within budget — none of the above matters if the page has not finished loading
Implementation intention
Your first hour in the builder
- 0–5 min
Pick a theme
Use the decision table above. If genuinely unsure and your catalogue will likely grow, start with Classic.
- 5–15 min
Set your four core tokens
Primary colour, accent colour, corner radius, and base font. Everything downstream inherits these; do this before touching any section.
- 15–20 min
Edit the hero section
Replace the placeholder headline and image with your own; enter both the Bangla and English fields, not just one.
- 20–30 min
Add your first product grid
Connect it to your catalogue. Confirm price displays in BDT and that stock status is visible.
- 30–35 min
Add a delivery/COD/payment trust section
Place it directly below the hero or product grid — see checklist items 6–8.
- 35–45 min
Preview on your own phone
Use the shareable link, on mobile data if possible, not just on the office Wi-Fi.
- 45–50 min
Check the performance panel
Address any flagged oversized image before publishing.
- 50–55 min
Publish as version 1
Or schedule it for a specific launch time.
- 55–60 min
Bookmark the version history panel
You now know how to roll back if anything about the next change goes wrong.
Contrast framing
Framique builder vs. generic page builders
| Framique builder compared with generic page builders | Generic page builder | Framique builder |
|---|---|---|
| Preview fidelity | Simplified preview renderer, can diverge from production | Same renderer for editor and live store |
| Bangla support | Often a bolted-on translation plugin | One catalogue, native Bangla + English fields, script-aware typography |
| Payment context | Generic card/PayPal assumptions | bKash/Nagad/Rocket/Upay/card/COD built into theme sections |
| Versioning | Usually undo history within a session only | Numbered, immutable, author-stamped versions with one-click rollback |
| Scheduled publish | Rare or third-party plugin | Native, queue a draft for a future timestamp |
| Font governance | Unlimited weights, no licence step | Licence attestation + two-weight budget enforced at upload |
| Custom code safety | Inline script, can break the whole page | Sandboxed iframe, isolated failure |
| Secret exposure risk | Unchecked | Secret scanning blocks save on credential-shaped strings |
| Performance enforcement | Advisory at best | Hard budgets enforced at publish time, with auto-compression offered |
| Themes offered | Often hundreds of undifferentiated templates | Five official themes, each purpose-built for a distinct merchandising situation |
A marketplace of hundreds of templates optimises for browsing variety, not merchandising fit. Five themes, each mapped to a specific business situation, is a smaller but more honest promise.
Built in, not bolted on
Accessibility
The builder itself and every published storefront share the same accessibility baseline. Body text clears 7:1 contrast; any gradient spotlight card carrying text uses a minimum 4.5:1 against its darkest gradient stop. Focus states use a visible ring on every interactive element, including inside the token panel and section rail — a focused button also gets a visible outline shift, never colour alone. Motion is transform/opacity only and fully collapses under prefers-reduced-motion. Drag-and-drop section reordering has a keyboard-operable equivalent (move-up/move-down buttons revealed on focus). Bangla text accessibility is structural: minimum 1.35 line-height on Bangla display type prevents matra clipping, and lang="bn" is set at the subtree level so screen readers switch pronunciation correctly mid-page.
Questions