← Back to projects
Personal project · In progress · 2026

Karbar

One system to run a shop in Bangladesh: the counter, the online store, stock, customer dues, the books, VAT and payroll.

A product I'm designing and building end to end. The demos below run on sample data.

The problem

A typical shop in Bangladesh runs on several disconnected tools: a POS at the counter, a paper khata for customers who buy on credit (baki), Excel for stock, Facebook messages for online orders, and an accountant who rebuilds the books at the end of the month. None of them agree, so the owner never really knows today's stock, who owes what, or whether the month was profitable.

Big ERPs are expensive and built for other countries. Simple POS apps stop at the receipt. Karbar's goal is a single system where every sale, purchase and payment updates stock, dues and the books at the same moment, in language the shop already uses.

How a sale moves through Karbar

  1. 1

    Sold at the counter or online

    A cashier scans a barcode on the POS terminal, or a customer orders from the shop's own online store. Both draw from the same stock in the same warehouse.

  2. 2

    Stock and cost update instantly

    Stock drops in the right warehouse, and the product's average cost is used to work out the real profit on that sale.

  3. 3

    The books write themselves

    Every sale, purchase, expense and salary is posted as a double-entry journal entry automatically. The owner never writes a journal entry.

  4. 4

    Credit sales become dues (baki)

    Selling on credit respects each customer's credit limit and shows up in their dues, with collections recorded against them.

  5. 5

    Low stock turns into a purchase order

    When stock reaches the reorder level, the owner is notified and Karbar drafts a purchase order. Large orders wait for approval before they're placed.

  6. 6

    The month closes itself

    Profit & loss, balance sheet, trial balance and the VAT report are always up to date, because they're built from the same journal.

Key decisions, and why

A modular monolith, not microservices

Eleven modules (Inventory, POS, Purchasing, Accounting, CRM, HR, E-commerce, Storefront, Reports, Platform, Core) live in one codebase behind one REST API. Each company switches modules on or off by plan. One team gets clear boundaries without the cost of running a distributed system.

Many shops, one database, strict isolation

Every company's data is scoped to that company in a shared PostgreSQL database. Dedicated tests try to read and use another company's data and must fail.

Accounting by double entry, never edited

Journal entries can't be deleted; a mistake is fixed with a reversing entry. The trial balance proves debits and credits always match, so the numbers can be trusted.

Owners stay in control of money

Limits for purchase orders, expenses, supplier payments and discounts send large actions for approval. Nothing reaches the books, and no money leaves, until someone approves.

Speed that doesn't decay as a shop grows

A query-budget test calls every API endpoint on a small shop and again on one five times bigger; the number of database queries must not grow. It catches N+1 problems before they ship.

One storefront deployment, every shop's domain

The Nuxt storefront renders pages on the server for SEO, picks the shop from the domain, keeps customer sessions in httpOnly cookies, and talks to the API through its own gateway, so custom domains need no CORS setup.

What's built

POS terminal

Barcode scanning, discounts, cash/card/mobile/bank and store credit, receipts, returns and refunds.

Wholesale (B2B)

Quotation → sales order → delivery → invoice, with partial deliveries and payments.

Customers & dues

Credit limits, baki tracking and collections, store credit, loyalty points and activity notes.

Inventory

Products with variants and units, multiple warehouses, average costing, CSV import/export and barcode labels.

Purchasing

Suppliers, purchase orders, receiving goods, reorder planning and supplier payments.

Online store

Server-rendered storefront per domain, orders, discounts and codes, collections and shipping.

Accounting

Cash, bank and bKash/Nagad accounts, expenses, owner's money, opening balances, P&L, balance sheet, trial balance, bank reconciliation.

VAT

Configurable rates, supplementary duty, VAT-inclusive or on-top prices, BIN on invoices, and a VAT report.

HR & payroll

Employees, attendance, leave approval and monthly payroll runs posted to the books.

Approvals

Spending and discount limits with approve, reject and withdraw, and notifications to both sides.

Roles & activity

Role-based permissions per company, a staff activity log and in-app notifications.

Platform admin

Plans, per-company modules and invite-only signup for running Karbar as a service.

Where it stands

  • All eleven modules work end to end; the demos above show the desktop and phone apps.
  • About 220 automated tests across 40 feature suites, including tenant isolation, stock valuation, financial statements, VAT and the N+1 query budget.
  • A user guide in Bangla and English written for shop staff, not developers.
  • Next: a pilot with a real shop, then the mobile app on the same API.

My role

  • Designed the product, the data model and the architecture.
  • Built the Laravel API, the Vue admin app and the Nuxt storefront, with AI tools as a pair programmer.
  • Wrote the test suite and the user guides.

Skills involved

LaravelPHPPostgreSQLMulti-tenant SaaSDouble-entry accountingREST API designVue 3PiniaNuxt (SSR)SanctumRole-based accessFeature testing

© All right reserved to Safayet