Solutions Engineer | Software, Cloud And Geospatial Systems

Context

Operational context

Sales representatives worked in the field while finance, management and HR teams operated from a central office. Information had to move between teams reliably despite intermittent connectivity and a previously manual reporting process.

Challenge

The problem

Manual and fragmented processes delayed reporting, limited visibility into field activity, and made it difficult to connect sales transactions with accounting and workforce operations. Management reports could take up to three months to prepare, reducing the organisation’s ability to respond quickly.

Constraints

• Field users needed to continue working when internet access was unavailable.
• Sales, accounting and workforce data had to remain consistent across mobile and web workflows.
• Deployment and support needed to be repeatable across production infrastructure.

Architecture

System design

A Cordova-based Android client stores field transactions locally and synchronises them through REST APIs when connectivity returns. Django provides the application and integration layer, PostgreSQL holds the operational record, and the web interface supports reporting, accounting and HR workflows. Docker and Kubernetes package and run the services on AWS, while Jenkins, Git and Ansible automate deployment.

Solution

What was built

I designed and delivered an offline-capable mobile sales workflow connected to a central web platform. The system brings together transaction capture, invoices, accounting information, workforce activity and management reporting, with automated deployment and operational monitoring supporting reliable releases.

Engineering judgement

Decisions and trade-offs

Contribution

My role

• Translated sales, finance and workforce workflows into system requirements and architecture.
• Built the Django and PostgreSQL backend and REST integration layer.
• Developed the Cordova field application and its offline synchronisation workflow.
• Containerised and deployed the platform on AWS using Docker and Kubernetes.
• Automated delivery with Jenkins, Git and Ansible.

Product demonstration

See the system in use

Results

Operational impact

• Replaced delayed manual reporting with near-real-time operational analytics.
• Connected field activity with accounting, sales and workforce information.
• Improved targeting and supported fairer performance-based rewards.
• Reduced repeat deployment work through a consistent automated release process.

Reflection

Lessons learned

• Offline workflows need explicit synchronisation states and recovery paths, not only local storage.
• A shared data model creates the most value when operational ownership is agreed across departments.
• Deployment automation is part of the product when rapid, reliable change matters to operations.

Context

Operational context

Multiple apartment complexes were managed through spreadsheets, telephone calls and paper records. Financial, maintenance, tenant and asset information lived in separate workflows, making it difficult to see the full operational picture.

Challenge

The problem

Disconnected processes caused delayed rent collection, inconsistent reporting, tax calculation errors and limited visibility into maintenance and asset condition. Repair histories and spatial utility records were difficult to trace, contributing to service delays, unplanned costs and poor tenant experiences.

Constraints

• Financial, tenant and asset records needed to be unified without losing operational accountability.
• Payment and tax workflows required accurate, secure processing.
• The platform needed to work well for both management and tenant-facing use on desktop and mobile.

Architecture

System design

Django and PostgreSQL provide the core application, business rules and REST APIs. A responsive Bootstrap and JavaScript interface supports management and tenant workflows. Scheduled jobs drive billing, reminders and maintenance alerts, while Pesapal handles online payments. The platform runs on AWS in Docker and Kubernetes behind Traefik and cert-manager, with Jenkins, Git and Ansible supporting CI/CD and Prometheus, Grafana and Alertmanager providing operational monitoring.

Solution

What was built

I designed and built a central platform for rent, billing, taxes, maintenance, stores, tenant communication, spatial as-built plans and property assets. Automated reminders, online payment integration, task assignment and operational dashboards replaced disconnected manual steps and gave managers a reliable system of record.

Engineering judgement

Decisions and trade-offs

Contribution

My role

• Mapped property management workflows and designed the system architecture.
• Built the Django backend, PostgreSQL data model and REST APIs.
• Developed responsive management and tenant interfaces.
• Integrated billing schedules, maintenance alerts and Pesapal payments.
• Deployed and monitored the platform on AWS with Docker, Kubernetes and CI/CD automation.

Product demonstration

See the system in use

Results

Operational impact

• Improved maintenance response through real-time issue reporting and task assignment.
• Made asset repairs, depreciation and lifecycle information easier to track.
• Improved billing transparency, tenant communication and service delivery.
• Provided management with current financial and operational information.

Reflection

Lessons learned

• Operational platforms are strongest when finance, maintenance and asset workflows share identifiers and ownership rules.
• Automated financial workflows need visible exceptions and reconciliation paths.
• Monitoring scheduled jobs is as important as monitoring the web application.

Context

Operational context

Field teams operated as far as 250 kilometres from headquarters. Management needed a practical way to confirm visits and asset locations without depending on continuous connectivity or self-reported activity alone.

Challenge

The problem

The organisation could not reliably verify whether scheduled customer visits occurred or whether recorded assets were at the claimed location. Skipped visits and weak evidence contributed to reduced prospective sales and limited accountability across a widely distributed field operation.

Constraints

• The mobile workflow had to function in areas with intermittent connectivity.
• Visit evidence needed to combine identity, time and location without creating a burdensome field process.
• Managers needed a clear map and report view from centrally synchronised records.

Architecture

System design

A Cordova Android client captures QR, GPS and timestamp evidence, queues records offline and synchronises them through Django REST APIs. PostgreSQL stores visit, user and asset records, while a web dashboard uses Leaflet and mapping services to present verified activity. Docker and Kubernetes run the services on AWS, with Jenkins, Git and Ansible automating delivery.

Solution

What was built

I built an offline-capable field application for scanning assigned QR codes, capturing location evidence and recording visits. A connected web dashboard maps synchronised activity and gives managers verified reports for follow-up, customer service and field accountability.

Engineering judgement

Decisions and trade-offs

Contribution

My role

• Translated field verification requirements into a mobile and web system design.
• Built the Django and PostgreSQL API and operational data model.
• Developed the Cordova mobile workflow for QR, GPS and offline capture.
• Implemented the mapped management dashboard and activity reporting.
• Containerised and deployed the platform on AWS with automated CI/CD.

Product demonstration

See the system in use

Results

Operational impact

• Gave managers a real-time mapped view of synchronised field activity.
• Produced verified visit reports using QR, location and timestamp evidence.
• Improved field accountability and supported faster customer follow-up.
• Allowed teams to capture work in the field without continuous connectivity.

Reflection

Lessons learned

• Verification works best when it is quick for field staff and useful to managers, not merely an additional control.
• Offline location events need clear capture, pending, synchronised and exception states.
• Geospatial evidence should be collected proportionately and protected through role-based access.