DukaFlow is a multi-tenant business-management application for day-to-day retail operations, including point of sale, inventory, customers, credit, suppliers, staff, reporting, subscriptions, and payment workflows.
This repository documents selected engineering decisions from the private implementation, with emphasis on authorization boundaries, offline resilience, payment reliability, and release qualification.
The implementation repository is private. This case study contains sanitized architecture and engineering documentation; it does not publish application source code, production data, credentials, or infrastructure identifiers.
The implementation uses Next.js and TypeScript with PostgreSQL/Supabase for application data and authorization controls, Vitest and Playwright for automated verification, Vercel for hosted deployment, and M-Pesa Daraja for payment integration.
I selected these areas because they required explicit authority boundaries, failure handling, state reconciliation, and runtime qualification rather than only feature implementation.
Authenticated application requests resolve an active business context before business scoped reads or mutations. Database row level security provides an additional tenant boundary.
Offline POS prepares business, user and browser device scoped state for constrained local operation, then synchronizes queued work through server authorized paths after connectivity returns.
Payment flows integrate M-Pesa Daraja with callback validation, reconciliation, and idempotent transaction finalization.
See the system architecture and system context diagram for the public engineering model.
I designed business scoped authorization around authenticated memberships and active-business resolution, enforcing the resolved context across server/API access, business scoped operations, and database row level security policies.
Read the multi-tenancy and authorization case study · View the authorization flow
I implemented locally persisted sale drafts, prepared offline application state, business/user/device-scoped browser storage, cached product data, and synchronization back into the canonical sales workflow after connectivity returns.
Offline authorization uses server issued, time bounded permission leases and fails closed when cached authority is invalid, expired, or outside the active scope.
Read the Offline POS case study · View the Offline POS flow
I engineered payment flows around callback validation, tenant-aware transaction ownership, reconciliation, and idempotent finalization so retries and provider callbacks do not become uncontrolled duplicate business mutations.
Read the payment reliability case study · View the payment lifecycle
I qualified release candidates through static analysis, automated regression testing, migration verification, hosted runtime exercises, production smoke checks, distributed rate limit verification, deployment provenance checks, and controlled rollback exercises.
Read the release-engineering case study · View the release qualification flow
I document ten selected design decisions using a consistent structure: problem, rejected direction, selected approach, rationale, trade off, and evidence boundary.
Topics include tenant authority, application authorization with RLS, browser device scoping, time-bounded offline permissions, synchronization authority, payment state ownership, idempotency, release evidence classes, and verifier qualification.
Read the engineering decisions 0
The current qualified source baseline passed ESLint, TypeScript compilation, the complete Vitest regression suite, and a production build.
Browser and hosted-runtime evidence is treated separately from source-level and unit/integration qualification. The case study preserves those evidence classes rather than presenting test source, build success, or historical runtime evidence as proof of a stronger claim than was actually established.
The Offline POS documentation also preserves a specific limitation: a later browser-test scenario models disconnect, refresh while offline, continued sale entry, reconnection, and synchronization, but a matching execution record for that exact later scenario was not established during portfolio qualification.
TypeScript · Next.js · React · PostgreSQL · Supabase · Vitest · Playwright · Vercel · M-Pesa Daraja
- System architecture
- Engineering decisions
- Multi-tenancy and authorization
- Offline POS resilience
- M-Pesa transactional reliability
- Release engineering
- System context diagram
- Tenant authorization flow
- Offline POS flow
- Payment lifecycle
- Release qualification flow
This repository is a sanitized engineering case study. Private source code, credentials, environment files, production data, raw logs, infrastructure identifiers, and sensitive operational artifacts are intentionally excluded.
The diagrams are synthetic representations of the engineering model rather than exported production topology. Public visual assets are governed by the assets policy.