Turning real courier-operation challenges into clear workflows, trusted reporting and practical decision-support software.
Portfolio demonstration · Fictional data
This hero image is a sanitized portfolio concept. It does not reproduce the original production application, customer information, operational records, thresholds, routes or confidential business rules.
Important
Portfolio disclosure
This repository is a clean-room, sanitized case study of a historical private software project.
It contains no original application source code, employer or customer names, production data, credentials, internal URLs, proprietary business rules, confidential documents or production screenshots.
All interface concepts, shipment records, locations, metrics and operational examples in this repository are fictional, generalized or anonymized. Future additions must follow the same standard.
- Executive Summary
- Why OpsTower Existed
- The Problem
- Project Goals
- My Role
- Solution Overview
- Working Deployment
- Time-Aware Operational Reporting
- Threshold-Based Reporting
- Nationwide Slack Notification System
- Automated Invoice Verification
- High-Level Architecture
- Key Design Decisions
- Technology
- Outcomes
- What I Learned
- Evolution into the Logistics Intelligence Platform
- Confidentiality Boundaries
- Repository Guide
- Excluded Material
- Project Status
- About the Builder
- Rights and Use
| Area | Summary |
|---|---|
| Project | OpsTower |
| Project type | Private operations-intelligence platform |
| Industry context | National courier and logistics operations |
| Primary challenge | Fragmented operational visibility, repetitive manual checks and inconsistent reporting |
| My role | Operations lead, product designer and full-stack software builder |
| Solution | A unified platform for operational visibility, exception management, reporting, notifications, invoicing verification and controlled workflows |
| Operational use | A working deployment ran from a workplace computer and delivered scheduled operational reports to teams nationwide |
| Status | Historical working system; original application remains private |
| Public material | Sanitized case study only |
| Product evolution | Practical predecessor to the Logistics Intelligence Platform |
Courier operations generate large volumes of time-sensitive information.
Shipment events, exceptions, reports, operational notes, invoice records and performance indicators may exist across different tools and exports. Even when the underlying information is available, teams can still struggle to answer basic operational questions quickly:
- What is currently at risk?
- Which exceptions require immediate action?
- Where is the largest operational pressure?
- Which information can be trusted?
- Does the live operational view agree with the report?
- Are automated invoice outputs supported by the underlying activity?
- What changed since the previous check?
- What should the team act on next?
The operational challenge was not simply a lack of data.
The challenge was turning fragmented data into clear, trusted and actionable operational intelligence.
OpsTower was developed from firsthand experience with these problems in a national courier environment.
The workflow OpsTower addressed involved several recurring difficulties.
Operational information was spread across multiple sources, screens, reports and manual exports.
This made it difficult to create one reliable picture of the operation.
Teams repeatedly reviewed shipment information to identify missing events, delayed movement, incomplete workflows and other exceptions.
The process required time and attention that could have been directed toward resolving the exceptions themselves.
Live monitoring, historical reporting and exported data could produce different interpretations when they did not share the same underlying definitions.
A report is only useful when the team trusts how it was calculated.
Large lists of exceptions do not automatically tell an operator what matters most.
The system needed to separate:
- urgent problems from low-risk items;
- actionable exceptions from informational records;
- early-warning risks from already completed work;
- operational ownership from current physical location.
The meaning of risk changes throughout the operating day.
An exception that matters early in the morning may not be the most important issue during the afternoon or at close-out.
Operational reporting therefore needed to adapt according to:
- the current time of day;
- the stage of the delivery cycle;
- the remaining opportunity for intervention;
- defined operational thresholds;
- the readiness of the operation to close.
Automated invoicing improved efficiency, but an automated output still needed to be checked against the underlying shipment and operational activity.
Without an independent verification layer, teams could struggle to confirm whether:
- all expected billable activity was represented;
- any records were missing;
- activity had been duplicated;
- invoice outputs agreed with operational evidence;
- apparent differences were genuine errors or valid exceptions.
When risks are identified too late, the opportunity to correct them may already have passed.
The operation needed earlier and clearer warning signals.
OpsTower was designed around several practical goals:
- Create one operational view of shipment activity and risk.
- Reduce reliance on repetitive manual checks.
- Make exceptions easier to identify and prioritize.
- Align dashboards, reports and exports around shared definitions.
- Give operational teams earlier warning of developing problems.
- Adapt operational reporting to the stage of the operating day.
- Use thresholds to reduce noise and highlight meaningful risk.
- Deliver scheduled operational intelligence to teams nationwide.
- Verify automated invoice outputs against authoritative operational records.
- Separate user-facing controls from background processing.
- Preserve an auditable history of important operational actions.
- Explore how route-planning tools could support dispatch decisions.
- Build software around the way operators actually work.
The project was not intended to be another decorative dashboard.
It was intended to become a working operational command surface.
I worked across both the operational and technical sides of the project.
My responsibilities included:
- Identifying the operational problems
- Translating operational workflows into software requirements
- Defining the product direction
- Designing dashboard and exception-management workflows
- Designing the application and data architecture
- Building full-stack application functionality
- Developing reporting and export logic
- Designing time-of-day operational reporting
- Defining threshold-based notification behaviour
- Building scheduled Slack notification workflows
- Supporting nationwide operational reporting through automated Slack messages
- Designing an invoice-verification and reconciliation workflow
- Comparing automated invoice outputs against authoritative operational records
- Building checks to identify missing, duplicated or inconsistent billing information
- Giving the operations team a controlled way to review potential discrepancies before invoices were finalized
- Improving confidence that automated invoicing aligned with the underlying shipment activity
- Designing background synchronization processes
- Creating notification and alerting workflows
- Exploring route-planning and optimization approaches
- Designing administrative and access-control capabilities
- Testing operational definitions against realistic scenarios
- Investigating inconsistencies between live and historical views
- Improving worker reliability, monitoring and recovery behaviour
- Documenting implementation and operational decisions
The central challenge was not only writing code.
It was understanding the operation deeply enough to build the right system.
OpsTower brought several operational capabilities into one platform.
Portfolio demonstration · Fictional data
This interface is a sanitized portfolio concept. It does not reproduce the original production application, customer information, shipment records, thresholds, team mappings or confidential operational rules.
The platform created a consolidated view of shipment activity, operational status and developing risk.
The objective was to help users understand the current state without manually combining several reports.
Portfolio demonstration · Fictional data
This interface is a sanitized portfolio concept. It does not reproduce the original application, production records, customer information, operational thresholds, ownership mappings or confidential rules.
Operational exceptions were organized so teams could distinguish between:
- items requiring immediate intervention;
- developing risks;
- incomplete operational events;
- unresolved workflow blockers;
- completed or protected records that no longer required action.
Reporting logic was designed around consistent operational definitions.
The same underlying interpretation was intended to support:
- dashboard totals;
- detailed reporting;
- filtered views;
- CSV exports;
- PDF outputs;
- management summaries;
- scheduled Slack reports.
OpsTower did not treat every point in the operating day as the same.
The reporting model changed its focus according to the time of day and the remaining operational opportunity.
This produced three main reporting stages:
- Morning Risk
- Afternoon Risk
- Close-Out
Each stage focused on different questions, risks and thresholds.
The platform delivered scheduled Slack notifications to operational teams nationwide.
These notifications were not generic reminders. They were generated from operational data and adapted according to the stage of the operating day.
The notifications helped distribute a common operational view without requiring every user to open the application manually.
OpsTower included an independent verification layer that compared automated invoice outputs with the supporting operational activity.
The system helped identify potential discrepancies before invoice finalization and gave the responsible team greater confidence in the automated invoicing process.
Long-running and repeatable operational processes were separated from the user-facing dashboard.
Background services handled work such as:
- data synchronization;
- recalculation;
- recovery;
- scheduled processing;
- controlled retries;
- health and readiness monitoring.
Portfolio demonstration · Fictional data
This interface is a sanitized portfolio concept. It does not reproduce original production routes, addresses, customer information, vehicle details, optimization rules or confidential operational data.
OpsTower also explored route-planning workflows using open routing and optimization technologies.
The focus was on controlled operational use:
- validating uploaded stop data;
- grouping work into manageable route batches;
- previewing proposed sequences;
- reviewing results before applying them;
- exporting dispatch-friendly outputs;
- protecting approved route plans from accidental changes.
OpsTower did not go through a formal enterprise launch or centrally managed production rollout.
Instead, a working deployment ran from a computer at the workplace.
That deployment:
- processed operational information;
- generated scheduled risk reports;
- applied time-of-day reporting logic;
- evaluated operational thresholds;
- sent Slack notifications to teams nationwide;
- supported daily operational decision-making;
- provided invoice-verification results during invoicing;
- demonstrated real value in a live operational environment.
This deployment model had obvious limitations.
The system depended on:
- one physical computer;
- the local runtime remaining available;
- the network connection remaining stable;
- the application processes continuing to run;
- manual operational oversight.
However, it was still a working system.
It moved beyond a prototype by performing real operational work and delivering information used by national teams during the operating day.
The lack of a formal launch became one of the most important architectural lessons from the project.
A useful system can prove its value before it has enterprise-grade hosting, but reliable commercial software requires stronger deployment, monitoring, redundancy and support foundations.
A major design principle in OpsTower was that operational risk changes throughout the day.
The platform therefore used different reporting models for different stages of the delivery cycle.
The morning report focused on problems that should already have been visible or resolved early in the operating day.
Its purpose was to answer:
- What is already missing?
- What has not progressed as expected?
- Which risks require early intervention?
- Where could the day begin falling behind?
Typical risk categories included generalized conditions such as:
- missing expected inbound movement;
- shipments not progressing to the next planned stage;
- incomplete early operational events;
- invalid or unusable operational information;
- records that required immediate branch or team attention.
The morning report was designed to give teams enough time to intervene before the operational window narrowed.
The afternoon report shifted attention from early readiness to execution risk.
Its purpose was to answer:
- What has entered the delivery cycle but is not progressing correctly?
- Which shipments are at risk of failing before close-out?
- Which work appears stuck?
- Where does the remaining intervention time need to be focused?
The afternoon view used different logic from the morning report because operational expectations had changed.
A condition that may have been acceptable early in the morning could represent meaningful risk later in the day.
The close-out report focused on whether the operation was ready to complete the day.
Its purpose was to answer:
- What risk remains unresolved?
- What has been successfully completed?
- Which blockers are still open?
- Is the operation ready to close?
- Which items require continued attention or escalation?
The close-out report did not automatically assume that the operation was ready.
Readiness depended on defined operational thresholds.
When the operation remained outside the acceptable close-out threshold, the report reflected that the close-out was not yet ready rather than presenting an inaccurate completion message.
OpsTower used thresholds to prevent reports from becoming noisy and meaningless.
A threshold represented a defined operational boundary that influenced:
- whether a condition should be highlighted;
- how severe the risk appeared;
- whether a notification should be sent;
- whether the operation was considered ready for close-out;
- whether an exception required escalation.
Thresholds were valuable because not every variation required the same response.
A useful operational system must distinguish between:
- expected variation;
- manageable pressure;
- meaningful risk;
- critical operational failure.
Threshold-based reporting helped turn raw counts into operational signals.
The exact original thresholds and business rules are intentionally excluded from this public case study.
The Slack notification workflow became one of the most actively used parts of OpsTower.
Portfolio demonstration · Fictional data
This interface is a sanitized portfolio concept. It does not reproduce the original application, notification schedules, recipients, thresholds, customer information or confidential operational rules.
At scheduled times during the day, the working deployment:
- Loaded the latest available operational information.
- Applied the relevant time-of-day reporting model.
- Evaluated the applicable thresholds.
- Calculated the current operational risk.
- Produced a structured summary.
- Sent the report through Slack to the relevant nationwide operational audience.
The reports changed throughout the day:
Morning
Early readiness and developing operational risk
Afternoon
Execution risk and unresolved delivery-cycle pressure
Close-out
Remaining blockers, completion status and operational readiness
The notification model helped provide a consistent national view without requiring each operational team to build its own report.
The Slack output was intended to remain concise and actionable.
Detailed investigation belonged in the supporting platform or report exports rather than in an overloaded notification message.
The system helped:
- create a common national operational rhythm;
- surface risk at predictable times;
- reduce dependence on manual report preparation;
- keep multiple teams aligned around the same definitions;
- identify problems while there was still time to act;
- prevent important exceptions from remaining hidden in large datasets;
- support more consistent operational conversations across locations.
The nationwide Slack use is a key reason OpsTower should be described as a working system rather than only a prototype.
One of OpsTower’s most valuable operational capabilities was an automated invoice-verification workflow.
Portfolio demonstration · Fictional data
This interface is a sanitized portfolio concept. It does not reproduce the original application, invoice structures, financial values, customer information, reconciliation rules or confidential operational data.
Automated invoicing can process large volumes of operational records efficiently, but automation alone does not guarantee that every charge is complete, unique and correctly supported by the underlying activity.
The verification system provided an independent control layer between operational data and the final invoicing process.
At a high level, it:
- Compared invoice outputs with authoritative shipment and operational records
- Checked whether expected billable activity was represented
- Identified possible missing records
- Identified possible duplicated records
- Flagged inconsistent or unsupported billing information
- Separated potential discrepancies from valid operational exceptions
- Produced structured verification results before invoices were finalized
- Replaced informal spot checks with a repeatable reconciliation workflow
- Helped the responsible team investigate differences more efficiently
The purpose was not to replace financial approval.
It was to give the responsible team stronger evidence that the automated invoice output agreed with the underlying operational activity.
This became a valuable operational control during invoicing and materially improved confidence in the accuracy of the automated process.
The generalized verification process was:
flowchart LR
A[Operational Shipment Activity] --> C[Verification Layer]
B[Automated Invoice Output] --> C
C --> D{Records Agree?}
D -->|Yes| E[Verified Result]
D -->|No| F[Potential Discrepancy]
F --> G[Human Review]
G --> H[Correction or Valid Exception]
The exact reconciliation rules, invoice structures and business logic remain private.
The detailed production architecture is intentionally not included.
Portfolio demonstration · Fictional data
A sanitized conceptual view of the platform. No original production topology, customer mappings, credentials or confidential rules are shown.
The generalized structure was:
flowchart TD
A[Operational Data Sources] --> B[Ingestion and Synchronization]
B --> C[(Normalized Operational Data)]
C --> D[Rules and Classification]
C --> E[Reporting and Aggregation]
C --> V[Invoice Verification]
D --> F[Exception Management]
D --> G[Threshold Evaluation]
E --> H[Operational Dashboard]
E --> I[Reports and Exports]
G --> J[Scheduled Notifications]
J --> K[National Slack Reports]
V --> L[Reconciliation Results]
L --> M[Human Review]
F --> H
N[Administration and Controls] --> H
N --> O[Background Execution]
O --> B
At a high level, the platform separated:
Dashboard
User experience, reports, exports, administration and controls
Background services
Synchronization, scheduled processing, notification delivery,
recovery and worker execution
Shared domain logic
Operational definitions, classification, threshold evaluation,
invoice verification and reporting rules
Database
Normalized operational records, control state and reporting truth
The user-facing application should not own every long-running operational process.
Separating the dashboard from background execution made it easier to reason about:
- responsibility;
- retries;
- failure recovery;
- health monitoring;
- controlled shutdown;
- worker ownership.
Dashboards, reports, exports and notifications should not calculate the same operational metric in different ways.
Shared definitions reduce disagreement and improve trust.
Raw events are not automatically useful operational information.
The system needed to interpret and normalize events before turning them into:
- classifications;
- exceptions;
- performance indicators;
- reports;
- alerts;
- invoice-verification evidence.
Morning risk, afternoon risk and close-out readiness are not the same problem.
Reporting logic needed to reflect the current operational stage rather than applying one static interpretation throughout the day.
An effective notification system should not treat every record as critical.
Thresholds helped determine when information justified attention, escalation or a change in operational readiness.
The most useful exception view is not always the one with the most records.
A good operational view should help users understand:
- what happened;
- why it matters;
- who should act;
- how urgent it is;
- what should happen next.
Background processing requires more than a recurring timer.
Reliable workers need:
- ownership;
- bounded leases;
- heartbeats;
- retry rules;
- duplicate protection;
- visible failure states;
- recovery after interruption.
An exported report should not tell a different story from the dashboard that produced it.
Filtering, ownership, totals and classifications should remain consistent across both.
Automated invoicing should be checked against authoritative source activity.
The verification process should remain distinct from the process that generated the invoice.
Route optimization should support operational decision-making rather than silently replacing it.
Proposed routes should remain reviewable before they become approved operational outputs.
The private application used or explored technologies including:
- TypeScript
- React
- Next.js
- Node.js
- REST APIs
- PostgreSQL
- Prisma
- Structured operational data models
- Transactional application workflows
- Docker
- Git
- GitHub
- GitHub Actions
- Automated validation and testing
- Background worker processes
- Scheduled application processes
- Slack integrations
- OpenStreetMap
- OSRM
- VROOM
- Map-based route visualization
- Nearest-neighbour sequencing
- Solver-assisted route optimization
This public repository does not include implementation code, configuration or original infrastructure details.
Exact employer figures, shipment volumes, financial values and internal performance measurements are intentionally excluded.
At a qualitative level, OpsTower demonstrated that a purpose-built operational system could:
- Bring fragmented operational information into one view
- Reduce dependence on repetitive manual checking
- Make operational exceptions easier to identify
- Help users prioritize developing risks
- Adapt operational reporting to the stage of the operating day
- Use thresholds to distinguish meaningful risk from normal variation
- Deliver scheduled operational intelligence nationwide
- Create consistent morning, afternoon and close-out reporting
- Improve consistency between live monitoring, reports, exports and notifications
- Verify automated invoice outputs against underlying operational records
- Identify potential billing discrepancies before invoice finalization
- Replace informal invoice spot checks with a structured reconciliation workflow
- Improve operational confidence in automated invoicing
- Turn recurring operational knowledge into reusable system logic
- Support controlled notification, reporting and export workflows
- Explore practical route-planning assistance
- Translate real logistics experience into working software
Most importantly, the project proved that operational knowledge could be converted into a serious technical system rather than remaining trapped in spreadsheets, manual checks and individual experience.
OpsTower produced several lessons that continue to influence my work.
Terms such as “at risk,” “late,” “missing,” “complete,” “verified” and “owned by” need precise definitions.
Small differences in interpretation can materially change a dashboard, notification, report or invoice-verification result.
A beautiful dashboard has little value when operators do not trust the numbers.
Accuracy, traceability and consistency must come before decoration.
The correct report depends on the stage of the operation.
A static report cannot always represent morning readiness, afternoon execution risk and close-out readiness equally well.
A threshold should not be chosen merely because it creates a convenient number.
It needs to represent a real operational boundary that changes the required action.
A list of problems is not the same as decision support.
Users need enough context to understand why a record matters and what action is expected.
Workers require clear execution responsibility and recovery behaviour.
Ambiguous ownership creates duplicate processing, stalled work and difficult failures.
Operational systems must deal with incomplete data, delayed events, retries, changing ownership, interrupted processes and inconsistent source information.
Happy-path behaviour is not enough.
Automating invoice generation improves speed and consistency, but financial outputs should still be reconciled against authoritative source activity.
A reliable verification layer should help answer:
- Is every expected billable record included?
- Has any activity been counted more than once?
- Do invoice outputs correspond with the supporting operational records?
- Are differences genuine errors or valid operational exceptions?
- Can the team explain and reproduce the final result?
Automation creates efficiency.
Independent verification creates confidence.
Running successfully from one workplace computer proved the operational value of OpsTower.
It also exposed the need for:
- reliable centralized hosting;
- process supervision;
- redundancy;
- secure configuration;
- formal monitoring;
- controlled deployments;
- disaster recovery;
- operational support ownership.
A system designed around one operating environment can solve a real problem while still requiring significant redesign before it can serve multiple organizations.
Commercial products need stronger boundaries around:
- organizations;
- permissions;
- configuration;
- integrations;
- auditing;
- data isolation;
- lifecycle management.
OpsTower was an important practical predecessor to the Logistics Intelligence Platform, or LIP.
OpsTower answered the first question:
Can firsthand logistics experience be translated into useful operational software?
The answer was yes.
The system performed real operational work, delivered scheduled reports nationwide and supported an important invoice-verification process.
It also revealed the next, more difficult question:
How should that capability be redesigned as a secure, configurable, resilient and organization-aware product?
Those lessons now inform LIP.
The Logistics Intelligence Platform is being designed from the beginning around:
- Organization-aware architecture
- Role-based authorization
- Secure identity and access workflows
- Configurable operational models
- Stronger auditability
- Clear product boundaries
- Multi-organization data isolation
- Reliable deployment and worker foundations
- Documentation-led architecture
- Long-term platform evolution
OpsTower was built around a specific operational environment and proved the value of the concept.
LIP is the product evolution of the lessons learned while building and operating it.
This public case study intentionally excludes:
- Former-employer names and branding
- Customer names and branding
- Production shipment records
- Employee or contractor information
- Internal branch, route or team mappings
- Customer and account codes
- Internal terminology and status mappings
- Proprietary operational rules
- Original reporting thresholds
- Invoice structures and reconciliation rules
- SLA calculations
- API endpoints
- Environment-variable names
- Credentials and secrets
- Slack workspaces, channels and webhook configuration
- Infrastructure addresses
- Database schemas from the original application
- Production screenshots
- Source code from the original repository
- Original commit history
- Internal documents or communications
This repository does not claim endorsement, sponsorship or affiliation with any former employer, customer or technology provider.
This repository is intentionally documentation-focused and contains only sanitized public case-study material.
| File | Purpose |
|---|---|
README.md |
Executive case study, operational context, capabilities, outcomes and product evolution |
LICENSE.md |
Proprietary licence notice confirming that the case study is not open source |
RIGHTS.md |
Rights, permitted reference and no-open-source-licence terms |
docs/architecture.md |
Generalized system architecture, data flow, workers, reporting and deployment lessons |
docs/design-decisions.md |
Major product and engineering decisions, including their reasoning and trade-offs |
docs/lessons-learned.md |
Operational, technical, commercial and product lessons that shaped LIP and RouteFoundry |
docs/confidentiality-boundaries.md |
Sanitization, publication and clean-room boundaries governing the repository |
| Asset | Purpose |
|---|---|
assets/opstower-case-study-hero.png |
Branded case-study hero and repository introduction |
assets/architecture-overview.svg |
Sanitized conceptual architecture overview |
assets/control-room-concept.webp |
Operational control-room concept |
assets/exception-management-concept.webp |
Prioritized exception-management workflow |
assets/notification-cycle-concept.webp |
Morning, afternoon and close-out reporting cycle |
assets/invoice-verification-concept.webp |
Invoice reconciliation and human-verification workflow |
assets/route-planning-concept.webp |
Reviewable route-planning and optimization workflow |
All interface concepts and operational examples use fictional, generalized or anonymized data and are visibly labelled:
Portfolio demonstration · Fictional data
This repository does not contain:
- The original OpsTower application
- A sanitized copy of the private source repository
- Production-ready source code
- Real operational data
- Original production screenshots
- Original invoicing records
- Original notification messages
- Instructions for accessing any private system
- Confidential employer or customer information
- A complete reconstruction of proprietary workflows
The original private project remains separate and will not be made public through this repository.
OpsTower was a working historical private project.
It was not formally launched as a centrally hosted enterprise platform.
A working deployment ran from a workplace computer and performed real operational functions, including scheduled nationwide Slack reporting and automated invoice verification.
This repository exists to document:
- the operational problem;
- the product thinking;
- the architecture;
- the working deployment;
- the nationwide notification model;
- the invoice-verification capability;
- the engineering lessons;
- the progression from operational experience to software;
- the influence of that work on future RouteFoundry products.
It is not an active public software release.
I’m Phillip Pieterse, a logistics operations professional, software builder and founder of RouteFoundry Technologies.
My work focuses on turning difficult operational processes into:
- clearer workflows;
- useful dashboards;
- reliable reporting;
- practical automation;
- secure operational systems.
- RouteFoundry Technologies: routefoundry.co.za
- GitHub: github.com/Sleek1598
- Email: hello@routefoundry.co.za
Copyright © 2026 Phillip Pieterse. All rights reserved.
This repository is provided as portfolio material for viewing and professional evaluation.
It does not contain or license the original OpsTower application.
Except for the limited platform rights provided through GitHub’s Terms of Service, no broader permission is granted to reproduce, republish, distribute, commercialize or represent the contents of this repository as another person’s work without prior written permission.
All organizations, shipment records, locations, interfaces, metrics and operational examples shown in this case study are fictional, generalized or anonymized.
OpsTower: where operations experience became a working system.