A restaurant POS that ships on the regulator’s timeline.
Bahrain’s NBR e-invoicing mandate is not a feature to add later. It is the schedule. We scoped, specced and started building a POS that meets it, in phases, alongside the customer who will run it on opening day.
- Client
- Bahraini F&B operator
- Sector
- Hospitality · point-of-sale
- Region
- Manama, Bahrain
- Engagement
- MVP partner, anchor customer
A regional F&B operator wanted a POS they could own — not a SaaS rental whose roadmap they don’t control. The wrinkle: Bahrain’s e-invoicing rollout means the system has to speak to the regulator from day one. The scope had to be carved down to what could be live for the first restaurant’s opening, with the rest sequenced behind it.
- 01
Treat the spec as the product.
Before any UI: a written PRD, an e-invoicing research document, VAT and service-charge rules pinned down. The spec exists so the build can be honest about scope.
- 02
Phase one is one restaurant.
Casual dining, single venue, full compliance. Multi-location and fine-dining variants are phase two — designed for, not built yet.
- 03
Build the customer into the loop.
The operator reviews each module the week it lands. No big-bang reveal — the team running the floor knows the software before opening.
- Product requirements (v0.1) — phased and dated
- Bahrain NBR e-invoicing compliance research
- POS core: orders, payments, VAT, service charges
- Module architecture for multi-venue rollout
- Engagement
- Anchor customer, in build
- Constraint
- Regulatory deadline, fixed
- Approach
- Spec first, then code
Customer identity withheld until launch.
- Application
- TypeScript · React · Node services
- Data
- PostgreSQL · receipt + audit trails
- Compliance
- Bahrain NBR e-invoicing integration