Rescuing a Mobile App from Offshore Development Failure
Industry
Construction
Company size
50 - 200 Employees
About
Founded in 1998, Mainland Civil is a premier Australian civil engineering and construction contractor specializing in bulk excavation, deep shoring, foundation piling, and infrastructure. Headquartered in Kogarah, NSW, they operate extensively across New South Wales, Queensland, Victoria, and the ACT.
Control
Mainland Civil had an app they couldn't control, couldn't fix independently, and didn't know the security status of. That's changed.
Ownership
They know exactly what's running, where, on what security posture. When a driver calls to report a bug, there's a defined path to resolution with a response SLA.
The Situation
Mainland Civil is a civil construction company operating across greater Sydney. They move earth, lay infrastructure, run trucks. The work is physical — excavators, tippers, operators, job sites that change daily.
By early 2026, they also had a software problem.
A mobile application had been built over the preceding period by the previous development vendor, an offshore development firm. The app was intended to give Mainland Civil's drivers a way to track trips, record tonnage, log time, capture materials used, and generate job reports that customers could sign off digitally. The business case was solid: better data, better invoicing, better accountability, competitive advantage through digitised field operations.
The execution had not delivered on that promise.
What Mainland Civil discovered:
The application was live — barely — but built on infrastructure that wasn't owned by Mainland Civil. the previous development vendor held the hosting account. Mainland Civil had no direct control over their own system.
The codebase had security vulnerabilities consistent with offshore development produced under time and cost pressure: unpatched dependencies, no evidence of security scanning, exposure to the kind of automated ransomware scanning that hits poorly-secured production servers within days of deployment.
Hosting was on cheap shared infrastructure rather than a professional cloud provider. No Sydney data centre. No proper backup and restore capability verified to a tested standard.
Four different application URLs existed across Mainland Civil's digital environment — none using a consistent domain structure. The technical architecture reflected accumulated decisions made without ownership.
Internally, The Operations Manager acknowledged the company was "in the dark ages" regarding technology. The Managing Director had taken the the previous development vendor engagement to the board. Neither had the visibility to understand how serious the underlying state was — they knew something was wrong, but not what.
Why they called us
The Operations Manager and Managing Director didn't call Halcrow because the app had stopped working. They called us because they'd reached a point of clarity: the relationship with the previous development vendor wasn't working, and they didn't know how exposed they were.
The specific trigger was recognition that Mainland Civil didn't own their own infrastructure. An application that runs your field operations — trip tracking, tonnage recording, job signoff — should be in an account you control. It wasn't.
What they'd seen fail:
The offshore development model had delivered a product. But it had delivered it in a way that maximised the previous development vendor's leverage and minimised Mainland Civil's. The code was theirs but not accessible. The hosting was running but not controlled. The application worked but couldn't be changed without going back through the previous development vendor.
This is the structural pattern of vendor lock-in in technology delivery: Law 2 (Consultants sell deliverables. The outcome is someone else's problem.) the previous development vendor delivered code. What happened after that — security, ownership, operational continuity — was explicitly not their concern.
The question they were actually asking: Can someone take ownership of this properly, make sure we're not exposed, and maintain it going forward without holding us hostage?
How we worked
Handover Architecture: Four Parallel Tracks
Recovery projects with offshore development handovers have a specific risk profile: you're taking ownership of something you didn't build, whose quality you don't yet know, while keeping it running for an operational business. The handover needed to be structured to eliminate operational disruption while moving fast enough to close the security exposure window.
Track 1: Legal and commercial transition Mainland Civil contacts the previous development vendor directly to initiate handover. Halcrow facilitates a developer-to-developer video session — approximately one hour — where the codebase, credentials, and architecture are walked through. the previous development vendor provides codebase files and all account credentials within one-to-three business days. A one-month parallel support period is negotiated: the previous development vendor remains responsible for the application functioning until Halcrow has reviewed the codebase, confirmed the architecture, and formally accepted responsibility.
Track 2: Security first As soon as code access is obtained, a vulnerability scan runs. Not a courtesy scan — a priority scan looking specifically for anything that allows database or server access. The application was almost certainly built with insufficient security attention, and every day of delay on patching is a day the automated ransomware scanners are finding the same vulnerabilities we are. Critical patches applied immediately. Non-critical vulnerabilities triaged for the ongoing maintenance backlog.
Track 3: Infrastructure migration Application migrated to a professional cloud provider (AWS, Azure, or Google Cloud) in a Sydney data centre, in an account owned by Mainland Civil. Halcrow holds access but does not own the account — this is non-negotiable. If Mainland Civil ever wants to move providers again, they own their own infrastructure.
Track 4: Account and ownership verification The Operations Manager holds the Apple Developer ID and Google Play Store credentials. Website and hosting ownership needs verification and transfer. All accounts owned by Mainland Civil with access granted to Halcrow as service provider, not the reverse.
Direct access without gatekeeping: Slack channel between Halcrow, the Operations Manager, and the MD. Direct access to all application infrastructure once obtained. No ticket queues during the critical first five days.
Recovery Phase: Week by Week
Week 1: Discovery and Access (Days 1-5)
Objective: Understand what we've inherited before we own it.
Halcrow facilitates the developer-to-developer session with the previous development vendor. Codebase obtained. Initial architecture review conducted in parallel with vulnerability scan.
What we found inside the code:
The application functioned as described — drivers could log trips, record tonnage, sign off jobs. The core feature set was complete. But the implementation had several categories of risk:
Authentication: Session management implemented without standard security headers. Brute-force protection absent.
Dependencies: Multiple npm/library versions months to years out of date, including packages with known CVEs.
Infrastructure: No environment separation between staging and production. Database credentials hardcoded in configuration files that were version-controlled.
Monitoring: No application error tracking. No performance monitoring. If the app crashes at 2pm on a Wednesday, Mainland Civil finds out when a driver calls the Operations Manager.
Critical patch priority set: Hardcoded credentials and authentication vulnerabilities addressed first. Everything else triaged.
Law 1: Distance is the enemy of speed. Every day the previous development vendor held the codebase was a day we couldn't assess or fix exposure. We moved to get code access within 24 hours of the developer session being scheduled.
Week 2: Security Remediation and Migration Preparation
Objective: Close the highest-risk vulnerabilities. Plan the infrastructure migration.
Critical security patches deployed. Hardcoded credentials rotated — new values injected as environment variables, not stored in source code. Authentication headers added. Session management corrected.
Infrastructure migration scoped: AWS Sydney region selected, account provisioned in Mainland Civil's name, migration plan validated with the previous development vendor still on parallel support.
Monitoring installed: Application error tracking via Sentry. Uptime monitoring with PagerDuty alerting the Operations Manager for P1 incidents. No more silent failures.
Weeks 3-4: Migration and Handover Confirmation
Objective: Move to production in Mainland Civil's infrastructure. Confirm formal handover.
Application migrated to AWS Sydney. DNS updated. the previous development vendor's parallel support period begins winding down. Halcrow conducts end-to-end testing of all driver workflows: trip creation, tonnage recording, materials logging, customer job signoff, invoice generation.
Backup and restore procedures documented and tested. First backup verified. Recovery time objective established.
Formal handover confirmed: Halcrow assumes responsibility for the application. the previous development vendor engagement ends.
WHAT CHANGED
Quantitative Changes
Metric | Before | After |
|---|---|---|
Infrastructure ownership | the previous development vendor's account | Mainland Civil's AWS account |
Codebase access | Dependent on the previous development vendor | Direct access, version-controlled |
Critical vulnerabilities | Unknown (no scan) | Identified and patched |
Hardcoded credentials | In version control | Rotated, environment variables |
Monitoring | None | Application error tracking + uptime |
Backup verification | None | Quarterly, tested |
Incident response SLA | None defined | P1: 2-hour notification |
OS/app store updates | Ad hoc / dependent | Scheduled, owned |
Qualitative Shift
Before: Mainland Civil had an app they couldn't control, couldn't fix independently, and didn't know the security status of. The Managing Director had taken the situation to the board without being able to answer basic questions: Where is it hosted? Who owns the account? If something goes wrong tonight, who do we call?
After: Mainland Civil owns their infrastructure outright. They know exactly what's running, where, on what security posture. When a driver calls to report a bug, there's a defined path to resolution with a response SLA. When Apple releases a new iOS version, it's on the maintenance schedule — not a surprise.
The capability change is harder to quantify but more important: Mainland Civil can now make decisions about their application without going through an offshore vendor. Feature requests go on a backlog that Halcrow manages. Infrastructure changes happen in their account, with their approval.
WHY THIS WORKED
The Ownership Problem
The failure mode in offshore development isn't always bad code. Sometimes — as with Mainland Civil — the code does what it was asked to do. The failure is in what happens after delivery.
Offshore vendors operating on fixed-price contracts have one incentive: deliver to specification and move to the next engagement. Infrastructure, security posture, operational continuity — these are maintenance concerns, which means ongoing cost that a fixed-price engagement doesn't cover.
The result: applications built to launch, not to operate. Law 11: Every delivery partner behaves according to how it's rewarded. the previous development vendor was rewarded for shipping. Not for what happened after.
Halcrow is rewarded for what happens after. Our maintenance model ties commercial continuity to operational reliability — if the app is down, we're on the hook. That incentive structure produces different behaviour.
The Security Gap in Offshore Development
This pattern repeats across small-to-medium Australian businesses that commission offshore development: the team is capable, the product launches, and then the client discovers six to twelve months later that they don't own the infrastructure, the credentials are poorly managed, and the application has accumulated security debt that nobody is tracking.
The risk isn't theoretical. Automated scanners hit production applications constantly. An application with hardcoded database credentials and no authentication headers is a liability — not eventually, but immediately.
The five-day recovery engagement exists precisely for this scenario: enough time to take stock of what you've inherited, close the highest-risk exposure, and establish a maintenance model that keeps the situation from recurring.
what you're buying
Offshore development produces technology. It doesn't produce operational ownership.
If you've commissioned an application from an offshore firm and aren't certain of the answers to these questions, you have the same problem Mainland Civil had:
Is the hosting in your account, or theirs?
Have you run a security vulnerability scan?
If the app went down tonight, what would you do?
When did you last test a backup restore?
The recovery engagement isn't about blaming the previous vendor. It's about establishing the structural conditions for an application to run properly — owned by the right people, monitored correctly, maintained on a schedule.