Status: Pre-launch
FasoCommerce
A phone-first management platform where each shop or service turns on the modules its trade needs.
- 15switchable modules
- 13trade profiles
- 207backend tests
- 3team roles

Context
In Burkina Faso, many shops and services track sales, stock, customer debts and WhatsApp orders by hand. Their reality: limited connectivity, Mobile Money payments and very different trades.
Problem
Existing software assumes a stable connection, card payments and a single kind of business. A grocery, a dry cleaner, a restaurant and a garage have different needs.
Objective
A single, phone-first platform that adapts to each trade through modules — and never blocks a sale.
Architecture
Modular monolith: a shared core (team, payments, customers, notifications) and switchable modules. Code checks a module, never a trade: adding a trade means adding a profile, with no migration.
- InterfaceNext.js 15, React 19, TypeScript. Mobile first, relative API calls behind a proxy.
- APIFastAPI: thin routes, shared services, one permission checked per business.
- DataPostgreSQL 16, schema versioned with Alembic migrations.
- JobsRedis and Celery for notifications and background work.
- FilesMinIO for product images.
- ProductionDocker Compose and Caddy (automatic HTTPS, security headers).
Technologies
- Next.js
- React
- TypeScript
- Tailwind CSS
- zustand
- zod
- Python
- FastAPI
- SQLAlchemy 2
- Alembic
- JWT
- PostgreSQL
- Redis
- Celery
- MinIO
- Docker
- Caddy
- pytest
- Playwright
- GitHub Actions
Features
- Online store and WhatsApp orders
- Point of sale, including offline, synced when the network returns
- Stock, sold by the case or by the unit
- Debt book (credit sales)
- Scheduled promotions and loyalty card
- Receipts for 58 / 80 mm thermal printers
- Direct Mobile Money payment, CinetPay as an option
- Trade modules: restaurant, driving school, garage, dry cleaning, bookings
- Team, custom roles and activity log
- Invoices, credit notes, suppliers, purchases, expenses, Excel export
- Subscriptions with a limited mode that never blocks the till
Screenshots

Online store 
Point of sale 
Offline sale 
Thermal receipt 
Restaurant module 
Garage module
Screenshots from the automated tests, with demo data.
Technical decisions
Modules, not trades
A profile (butcher, dry cleaner…) is only a starting point that switches modules on. Merchants can adjust them, and a new trade needs no migration.
Permissions, not roles
Each endpoint asks for a precise permission on a business. Team roles (manager, cashier…) are just sets of permissions.
A sale is never blocked
No network or unpaid subscription: the till keeps working. An offline sale is recorded with its real time once the connection returns.
Tokens out of JavaScript’s reach
Tokens in httpOnly cookies, never in localStorage, with an anti-CSRF header required on sensitive requests.
Challenges
Limited connectivity
A light, phone-first interface and a till that works without network.
Protecting sign-in
Attempts limited per phone number and per real IP address, supplied by the proxy rather than the client.
Compliance by design
Legal pages, processing register, no tracker without consent, and automated accessibility tests (WCAG 2.1 AA).
Result
Pre-launch: 15 modules, 207 automated backend tests, end-to-end and accessibility tests, continuous integration. The pricing grid is defined and still to be validated with merchants.
Possible evolution
- Field tests with merchants
- Flutter mobile app on the same API
- Ordering assistant on WhatsApp
- New trade profiles
Code and demo
Private repository — demo on request