Bardibas RetailOS
liveA multi-tenant POS and accounting platform certified by Nepal's tax authority — built and operated by one engineer.
- Role
- Lead Engineer (sole developer)
- Period
- 2025 – present
Nepal's Inland Revenue Department requires VAT-registered retailers to transmit every invoice in real time to the Central Billing Monitoring System. Most small retailers run unlicensed desktop software that cannot do this, which leaves them exposed at audit. Imported SaaS does not handle the Bikram Sambat calendar, Nepali fiscal years, or Schedule-8 VAT.
Build a system that is simultaneously a point-of-sale, a double-entry ledger and a regulated fiscal device — where an invoice is not considered issued until the tax authority acknowledges it, and where a dropped acknowledgement is a compliance failure rather than a UI glitch.
- Designed a multi-tenant PostgreSQL schema with row-level security isolating every tenant's ledger, inventory and fiscal records.
- Implemented real-time CBMS transmission with per-invoice acknowledgement persistence, so every issued invoice carries a verifiable state from the tax authority.
- Built Nepal-specific compliance as first-class domain logic: Bikram Sambat calendar, Nepali fiscal-year boundaries, PAN/VAT modes, Schedule-8 VAT and Annex 5 XML export.
- Wrote double-entry accounting with automatic journal posting behind the POS, so the books reconcile without a separate bookkeeping step.
- Self-hosted the entire Supabase stack on a Nepal VPS for data residency and latency, and operate it end to end — migrations, backups, WAL archiving and incident response.
- Ran a full chartered-accountant-level database audit against my own system and worked the findings as a backlog rather than filing them away.
- Shipped Pasal, a per-tenant storefront on a subdomain, as a paid add-on to the core platform.
The audit surfaced real problems, and I would rather name them than hide them: floating-point arithmetic in VAT calculation is being migrated to fixed-point decimal, several row-level security policies shipped with permissive placeholders that are being closed, and CBMS retry logic is under verification. Money-handling code earns trust by being audited in public, not by being called robust.