Step 1
Submit details
Share the repo shape, current pain points, and enough context for Shipward to confirm fit before work starts.
How it works
How Shipward works from source preflight to the next approved step
Shipward is designed to help you understand whether the current system is recoverable before you pay for the wrong implementation move.
Step 2
Source preflight
Confirm stack fit, source access, and whether the audit can proceed inside the published boundaries.
Step 3
Audit the current system
Review the codebase, release risk, architecture issues, and operational pressure points before touching risky paths.
Step 4
Report the decision
Deliver a recover, contain, rewrite, or unsupported recommendation with the evidence behind it.
Step 5
Scope the smallest safe next step
If recovery is sensible, define the next bounded remediation slice, the exclusions, and the approval boundary.
Step 6
Approve or stop
Follow-on work starts only when the next phase is explicitly approved and funded; otherwise the audit stands on its own.
What to prepare
- A supported repository or approved archive.
- Enough context to explain the current pain points, goals, and delivery risk.
- A willingness to let the audit say recover, contain, rewrite, or unsupported.
Where pricing, trust, and legal details live
Pricing and approval rules live on the pricing page.
Source handling and data-use boundaries live on the trust page.
The legal pages describe the current public website and audit-purchase posture, but legal publication status remains a separate truth gate.