A commerce system for businesses that sell from WhatsApp, not a desktop Shopify admin

Problem

Most small businesses Sqaleshop was built for already sell. They just sell badly at scale. Product photos live in camera rolls. Orders live in WhatsApp threads. Prices get typed out one customer at a time. When volume arrives, the process collapses.

Off-the-shelf tools were a poor fit: too expensive in dollars, too desktop, too plugin-heavy, and built for card checkout in markets where bank transfer and cash on delivery are still how people pay. The job was not “make a website.” It was “give a merchant one link they can drop in a bio and actually sell from.”

Constraints

• Mobile-first or it does not exist. Customers and owners both live on phones.
• Local payment behavior: transfer, cash on delivery, and proof of payment — not a Stripe-only happy path.
• Low operational overhead. A merchant should go live without plugins, developers, or a theme store.
• Multi-tenant from day one. Thousands of stores on shared infrastructure, isolated by tenant, cheap enough to start free.
• Room to grow into inventory, POS, invoices, bookings, and analytics without a second product.

Architecture

One tenant, one sales link, many modules. Storefront is the entry; POS, invoices, bookings, and analytics share the same catalog and orders.

Decisions

We did not build a Shopify clone. We built a sales link: sqale.shop/yourstore. That decision simplified onboarding, sharing, and the mental model. A merchant does not “launch a website.” They claim a handle, add products, and paste a URL into Instagram or WhatsApp.

Multi-tenancy was non-negotiable. A single-store build would have been faster and would have died the first time we needed isolation, custom domains, or per-merchant billing. Payments were modeled around how Nigerian SMEs actually collect money, with notifications that meet the owner where they already work — often WhatsApp — instead of a desktop order inbox they will never open.

Implementation

• Multi-tenant storefronts. Isolated shops on shared infrastructure, each with a public sales link, catalog, variants, and branded page.
• Inventory. Stock that updates from online orders and in-person sales instead of a spreadsheet that lags both.
• POS. Counter sales against the same catalog, so a physical stall and a WhatsApp store are not two businesses.
• Invoices and bookings. Service businesses and fashion drops do not share the same checkout. Packages and time slots sit alongside products on the same tenant.
• Payments and analytics. Local payment methods, order tracking, and a dashboard of visits, product views, orders, and revenue.

Scaling challenges showed up immediately: image-heavy catalogs on slow networks, notification volume, and tenants that outgrow “a link” into real operations. Those are product problems we designed for — not afterthoughts for a later rewrite.

Results

Sqaleshop launched in 2025 as a Sqaleup Inc. product. Merchants can go live in minutes, share one link, and run catalog, orders, and growth from a single dashboard. It is the commerce system we wished existed for mobile-first African SMEs — and the proof that Sqaleup operates production SaaS, not only client retainers.

Visit sqaleshop.com

Lessons

• Clone the workflow, not the category leader. A sales link beats a website builder for this customer.
• Multi-tenant costs more on day one and saves the company on day thirty.
• Local payments and messaging are architecture, not integrations you add when “the US version works.”