The challenge: software that must work without the internet, without excuses
Defence organisations operate under constraints that are categorically different from anything in commercial software procurement. The most fundamental is air-gapping: the systems that manage vessel operations, personnel movement, spares inventory, and safety inspections cannot be connected to external networks. They run on classified infrastructure, subject to security audits that no commercial product can pass, and maintained by personnel who need security clearances before they can touch the codebase.
Commercial off-the-shelf software is not an option — not because it lacks features, but because it cannot be vetted, cannot be hardened to the required classification level, and cannot be deployed on approved hardware. Every application must be purpose-built from scratch, with security baked into the architecture rather than bolted on later. The requirements span a wide operational range: vessel maintenance planning, stability engineering, inventory for critical spares with multi-year lead times, personnel safety aboard ships, and spatial operations planning across geographic areas.
The secondary challenge is the pace of requirement evolution. Defence organisations do not issue a fixed specification and wait for delivery. Operational experience surfaces new requirements continuously. A system designed for one class of vessel may need adaptation for another. A safety inspection workflow that covers one type of equipment will need extension when the equipment mix changes. Software delivered into this environment must be maintainable and extensible by a team with the appropriate clearances — which means the architecture matters as much as the initial functionality.
A third constraint defines everything else: failure is not an acceptable outcome. These systems are not productivity tools. They support decisions that have direct consequences for personnel safety, vessel seaworthiness, and mission readiness. The reliability bar is not set by uptime SLAs — it is set by the fact that the system must function in conditions ranging from portside routine operations to active deployment scenarios.
The solutions delivered
Six classified applications were built and deployed as part of this engagement, each targeting a distinct operational domain.
Refit Management with Stability Calculator addresses one of the most technically demanding aspects of vessel maintenance. A refit is not simply a scheduled maintenance event — it involves changes to the vessel's weight distribution as equipment is removed, replaced, or added. The software tracks the full refit schedule while simultaneously calculating stability margins based on weight changes at each stage of the refit. Engineers can model proposed changes before they are implemented, see the projected stability impact, and identify configurations that would bring the vessel outside safe operational parameters. This is not a feature that can be purchased from a marine software vendor and imported into a classified environment. It had to be designed from first principles against the naval engineering standards applicable to the vessel class.
Spares Management handles naval inventory where the stakes of a stockout are qualitatively different from a commercial warehouse. Critical spares for naval vessels may have lead times measured in months or years. The software tracks stock levels, manages minimum stock thresholds calibrated to lead times and operational tempo, and integrates with the refit schedule to forecast spares consumption. Demand signals from e-Round inspections (described below) feed into spares planning automatically, so that an inspection that identifies a worn component triggers a review of stock levels for that component type.
e-Round Monitoring System automates the safety inspection rounds that naval personnel conduct aboard vessels. Traditional rounds involve a crew member physically checking equipment status at defined intervals and recording observations on paper. The e-Round system digitises this process: inspectors carry rugged terminals, follow a defined inspection sequence, and record observations against specific equipment items. The system validates that all inspection points have been covered, timestamps each entry, and flags deviations from expected status. Inspection completion rates and anomaly history are visible to supervisors in real time.
Gangway Monitoring Software tracks personnel movement at vessel access points while in port. Every person boarding or departing a vessel is recorded. The system maintains an accurate headcount aboard at all times — a requirement for both routine security and emergency muster. Access can be restricted based on rank, watch rotation, and security clearance, with the gangway reader enforcing those restrictions rather than relying on manual verification.
GIS-Based Spatial Operations Software provides geographic information system capabilities for operational planning. Mapping, overlays, and spatial analysis tools configured for the specific requirements of naval operational planning — built as a standalone classified application rather than a layer on top of a commercial GIS platform that could not be cleared for deployment.
Data Analytics and Machine Learning capabilities were developed exclusively for this environment. Predictive maintenance models trained on equipment history, anomaly detection on inspection data, and operational pattern analysis — none of which can use cloud-based ML infrastructure or commercial analytics platforms. The entire pipeline runs on approved on-premise hardware.
Custom hardware: built to military specification
Software running in naval environments must run on hardware that can survive those environments. Commercial tablets, workstations, and networking equipment are not qualified for shipboard use. They are not rated for the vibration profiles, humidity ranges, salt air exposure, or electromagnetic interference that naval vessels generate. Purpose-built hardware products were designed and delivered alongside the software.
Each hardware product underwent environmental stress testing to verify compliance with the relevant defence procurement standards. Ruggedisation was not a cosmetic exercise — it involved redesigning enclosures, selecting components rated for the operating ranges involved, and validating performance under simulated operational conditions. The result is hardware that operates reliably in environments where off-the-shelf equipment would fail within months.
Building for an air-gapped classified environment means that every design decision gets made without the option of a patch or a hotfix deployed remotely. The architecture has to be right before deployment, because deployment is a physical event that requires cleared personnel and a maintenance window — not a CI/CD pipeline and a container restart.
Working with defence: what the engagement model actually looks like
Defence software engagements are multi-year by nature. The procurement cycle alone can extend well beyond what a commercial client would consider reasonable. Requirements are initially expressed at a high level and refined through operational consultation — which requires access to domain experts who are not always available on a commercial schedule. Security reviews add elapsed time at every stage: design review, code review, penetration testing, and formal certification before any system goes live.
The development team operates under formal security protocols. Access to systems under development is controlled. Code repositories are maintained on approved infrastructure. Personnel working on classified systems undergo background verification. These are not bureaucratic obstacles — they are the conditions of the engagement, and treating them as such from the outset is the difference between a delivery that completes and one that stalls.
The operational lessons from this engagement run in both directions. Building software for environments where connectivity is not an option forces architectural discipline: every system must handle offline operation gracefully, synchronise state correctly when connectivity is available, and fail safely when it is not. These are good architectural properties in any context. Defence work just makes them non-negotiable.