Selected engineering work.
Shared platforms, encrypted reporting and native mobile flows. A closer look at the engineering behind the interface.
Explore the engineering behind shared platforms, encrypted reporting and mobile wallet experiences. Each overview explains the problem, what we built and how the system works.
A shared platform. Clear access boundaries.
Financial operations across organisations, teams and accounts.
- The problem
- A shared financial platform needs to keep each organisation’s records and permissions within its assigned scope. Changing account relationships also needs to preserve the ownership recorded against earlier activity.
- What we built
- We implemented access rules across organisational and account boundaries, including checks on what a person can view and change. Current account membership and the ownership recorded on historical financial records are handled separately. Account-specific filters refresh when the selected scope changes.
- The engineering result
- The implemented behavior keeps current access and historical ownership distinct. A selection that grants no access is refused rather than treated as an unrestricted view.
- Organisation and account scope
- Protected viewing and editing
- Historical ownership
An abstract operations workspace separates current access from the ownership recorded on historical activity.
From source records to encrypted reports.
Reporting with explicit scope, business periods and delivery states.
- The problem
- Reporting involves more than exporting rows. Each output needs the correct organisational scope and reporting period, and a generated file must remain distinct from a confirmed transfer.
- What we built
- We implemented a pipeline that resolves scope, validates the business date and builds the selected reports. It records hashes of the generated and encrypted content, encrypts the files and tracks progress in a run ledger. Repeat-run checks preserve the distinction between partial progress and completed delivery.
- The engineering result
- Generation, upload and delivery have separate states. The workflow does not treat an upload as proof that every requested file reached its destination.
- Scoped source records
- Encrypted outputs
- Separate delivery confirmation
An abstract reporting flow shows validation, encryption and transfer as separate stages.
A mobile experience for the in-between states.
Native wallet integration with explicit activation and device checks.
- The problem
- Connecting an application to a native payment wallet involves states between starting a request and finding a usable card on the device. Cancellation, pending activation and an inconclusive response need different treatment.
- What we built
- We implemented provisioning through native platform services, with device availability checks and the card identity required by the integration. When activation remains in progress, the flow checks the phone and, where relevant, a paired wearable. User cancellation is handled separately from failure.
- The engineering result
- The interface distinguishes activation-required responses, confirmed wallet presence and inconclusive checks. An uncertain response is not automatically presented as either a completed action or an error.
- Native device integration
- Activation-state handling
- Cancellation and recovery
An unbranded mobile view pairs a generic payment-card shape with activation, device-check and confirmation stages.
Tell us what you’re building or improving.
Call or email, and a senior engineer will reply in under 6 hours.
Project enquiries
- Call+254 794 545 474
- AddressPhileo Arcade, Ruiru