The problem
Small and mid-sized merchants in Bangladesh who want to sell online are stuck choosing between two bad options: a generic global platform that doesn't speak to local delivery, payment, and marketing tools, or a custom-built site that costs too much and takes too long to change. Graphland's answer was StoreOS — a hosted e-commerce platform where one admin can run several stores from a single console, and where the storefront itself is editable without touching code.
I joined early enough to help set up the app's initial structure, and my main responsibility became the theming system — the part of the product that decides how flexible a merchant's storefront can be without a developer in the loop.
Setting up the foundation
Before any theming work could start, the app needed a shape. Working within a Next.js and TypeScript codebase backed by PostgreSQL and Drizzle, I helped lay out how stores, products, orders, and merchants would relate to each other, and how a single authenticated admin session could switch between multiple stores without re-authenticating or leaking data across tenants. That multi-store switcher — visible in the top-left corner of the merchant dashboard — became one of the more subtle pieces of the structure: it looks like a dropdown, but underneath it re-scopes every query on the page to a different store context.
The public-facing pitch: one console for catalog, checkout, orders, payments, and delivery, aimed squarely at merchants who've never run a storefront themselves.
The dashboard for GearHaat, one of the stores running on StoreOS in production. Totals for orders, revenue, customers, and products sit above a monthly sales chart and a status breakdown — the numbers a merchant checks first thing.
Building the theme builder
The theming system was the harder problem. Merchants aren't developers, but they still want their storefront to look like their brand, not a template. I built most of this system as a drag-and-drop customizer: merchants add blocks — headings, images, buttons, carousels — to storefront pages, rearrange them, and preview the result on desktop, tablet, and mobile before publishing.
The design decision that mattered most here was separating "draft" from "published" state at the data layer, not just in the UI. A merchant editing their homepage shouldn't risk showing half-finished changes to live customers, so every theme edit writes to a draft version, and publishing is a deliberate, explicit action that swaps which version the storefront renders. That distinction sounds obvious in hindsight, but it drove a lot of the schema and API design underneath the builder — block ordering, versioning, and preview rendering all had to respect it.
The customizer itself. Blocks stack top to bottom; the device switcher above the canvas re-renders the same draft at three breakpoints so merchants catch layout problems before they publish.
Plugins as the extension point
Rather than hard-coding integrations, StoreOS treats delivery, marketing, analytics, and payments as installable plugins. Pathao and Steadfast handle delivery, Google Analytics and Meta Pixel handle tracking, and the marketplace is built so new integrations — RedX is already queued as "Soon" — can be added without touching the core checkout flow. That plugin boundary was a direct response to a problem generic platforms have: every merchant in Bangladesh wants a slightly different combination of couriers and payment gateways, and hard-coding any one of them would have made the platform less useful the moment a merchant's needs didn't match.
23 integrations across delivery, marketing, analytics, support, payments, and notifications — each one opt-in per store.
A shared media library so merchants upload an image once and reuse it across products and collections, with usage counts to show what's safe to delete.
What I'd do differently
The draft/publish split solved the immediate correctness problem, but it means every new block type has to be built with versioning in mind from day one — that's a constraint I'd want to make more explicit in the block API if I were starting over, probably with a stricter schema contract instead of relying on convention. I'd also want undo/redo inside the customizer itself; right now, recovering from a bad edit means falling back to the last published version, which is coarser than merchants would like.