The vendor stopped replying.
Bring it back home. A straight read on stalled software builds.
Half-built portal stuck overseas? Vendor stopped replying? Code your team cannot read? Start with a rescue review. We look at the basics, call out the obvious risks and help you decide whether to pause, patch, finish or rebuild.
100+ shippedNo blame
§01
Sound Familiar?
The symptoms we see on almost every project rescue intake. Three or more is enough to call.
The code only runs on one person's laptop.
The offshore team keeps asking for more budget.
The portal is half-built but the business still needs it.
Nobody can explain the hosting, backups, or secrets.
The team is embarrassed to show customers the current version.
§02
The Rescue Review
A bounded first step before you tip more money into a stalled build. Clear enough to act on, light enough to start quickly.
§03
Project Rescue & On-Shoring
Bring an abandoned or offshored software project back to Australia.
Start with a short rescue review. We look at the build, access, hosting, vendor context and obvious risk, then tell you whether to stabilise, finish, rebuild or stop. If the project is worth saving, we scope the next move properly.
- First step
- Rescue review
- Output
- Next-step note
- Hosting
- Australian migration
- Source
- Escrow ready
Included
- Short call and access checklist
- Code, data, hosting, vendor and security triage
- Plain-English next-step note with stop, fix, rebuild or finish call
- Secrets, backups, docs, and release stabilisation
- Written rescue scope if the project is worth saving
Rescue review
A short, practical look at the build and the business risk. You leave knowing whether to stabilise, finish, rebuild or stop.
Stabilise
Fix the urgent risks first: access, hosting, secrets, backups, broken release paths and documentation.
Finish or handover
We take over the work that makes sense, ship the missing pieces, or help move the project to a safer owner.
§04
Confidentiality And Access
Project rescue often means sensitive systems, messy vendor history and production data. The first step should reduce risk, not create more.
Confidential by default
We can work under NDA before reviewing source code, hosting, vendor notes, credentials or product roadmaps.
Read-only first where possible
The first review prefers read-only access, screenshots, exports and guided walkthroughs before anyone changes production systems.
Credentials are handled deliberately
Passwords, API keys and hosting access should be rotated, limited and documented. Shared inboxes and reused secrets are called out as risks.
Production data stays protected
We do not need broad production data access for an initial risk read unless the scope specifically requires it.
§05
Project rescue questions
Short answers about confidentiality, access and what happens after the first review.
Can you review a software project under NDA?
Yes. Project rescue and software audit work can start under NDA before source code, hosting, vendor notes or product details are reviewed.
Do you need production access for a rescue review?
Not usually at the first step. We prefer read-only access, guided walkthroughs, screenshots, exports and existing documentation before anyone changes production systems.
What happens after the rescue review?
You get a clear recommendation: pause, stabilise, finish, rebuild or stop. If the project is worth continuing, the next scope is written separately.
§06
Apply
Send the basics. We reply with the access checklist, likely fit and next step.