Software development statement of work: 2026 guide for cruise lines
TL;DR
A software development statement of work for a cruise line app in 2026 has three jobs: date every client dependency as a gate, define acceptance as a test with a clock, and pay milestones on accepted releases. Cruise programs rarely slip on code. They slip on VPN access, expiring test accounts, APIs that work only in production and store accounts the cruise line owns.
- Write milestone dates relative to verified gates, not to the signature date.
- Start the acceptance clock when the build sits in the agreed environment, and name one approver.
- Since September 30, 2026, Android requires registered developers in four countries, so store accounts belong in the SOW.
- Mercury Development's onboard spa platform for OneSpaWorld has run on over 160 ships since 2018.
Why cruise SOWs fail after signature
Seatrade Cruise News, citing CLIA, reported 37.2 million ocean cruise passengers in 2025, up 7.5% from 34.6 million in 2024.
The contracts behind cruise software leak value. World Commerce & Contracting estimates that the average business loses almost 9% of value a year through poor contract management. PMI's 2018 Pulse of the Profession, quoted in PM Network, found scope creep or uncontrolled changes in 52% of projects completed in the prior 12 months.
A cruise SOW breaks in one place. The vendor signs up to dates that depend on the cruise line: VPN access, API endpoints, design approvals, a ship to test on. The SOW files those under assumptions in an appendix. When one slips, nobody can tell from the contract whose date moved.
Store accounts became a contract term on September 30
Google switched on Android developer verification on September 30, 2026 in Brazil, Indonesia, Singapore and Thailand, and plans to expand it globally in 2027. Play developers register their apps in Play Console, and Google told them to register remaining apps by that date to avoid removal from Google Play.
The app belongs in the cruise line's own developer accounts, and the vendor gets a role there to ship builds. Write it into the SOW: who owns each store account, which roles the vendor receives, by which date.
How we built this guide
We read the three pages that answer this question in AI search today: Bestarion's SOW checklist, Sprintlaw's guide to development contracts and Oleksandr Tytarenko's SOW template. All three ask for testable acceptance and listed dependencies. None says when the review clock starts or prices the time a vendor spends waiting.
- Legal anchors come from primary texts: UCC § 2-606, FAR Part 46 and the European Accessibility Act.
- Cruise patterns come from Mercury's contract and delivery records, without client names or counts.
- Any group of our own data with fewer than three data points is not published.
- This is operational guidance, not legal advice.
Mercury Development has built custom software since 1999 and writes SOWs for a living, so read this as a vendor's view.
The cruise SOW at a glance
| SOW section | What it must say | Cruise trap |
|---|---|---|
| Scope | Features by release, plus exclusions | Onboard and shoreside versions counted as one feature |
| Dependency gates | Each client deliverable with an owner and a date | Access and APIs buried in assumptions |
| Acceptance | A test, an environment, a review window, one approver | QA behaves differently from production |
| Milestones | Payment on accepted releases | Payment on calendar dates while gates are open |
| Change control | Cost and date impact, approvers | Scope cuts priced only as a total |
| Store accounts | Owner of each account, vendor roles | Vendor publishes from its own account |
| Handover | Source code, mocks, credentials | Test fixtures stay with the vendor |
Dependency gates: the clock starts when the client delivers
A dependency gate is a client deliverable that a milestone cannot start without. The SOW names it, dates it and states what it blocks. Milestone dates then count from the verified gate: four sprints after it, say, instead of a fixed day in March.
Gates we put in cruise SOWs:
- Access: VPN per engineer, identity accounts, test accounts per guest and crew role with expiry dates.
- API contract: documented endpoints with sample payloads, and QA endpoints reachable from the vendor's network.
- Design: approved screens for the release, signed by the design owner.
- Store roles: App Store Connect and Play Console roles that can upload builds.
- Ship window: dates on a vessel for anything that depends on the onboard network.
- Reviewers: named sign-off owners for accessibility and payments.
A gate closes when the vendor verifies it, not when someone emails that it is done.
Then decide, gate by gate and before signing, what a slip triggers:
- The milestone date moves day for day.
- The team switches to mocked work at no change in price.
- After an agreed number of idle days, standby is billed or scope is cut.
Acceptance criteria that end arguments
Acceptance usually releases payment. FAR Part 46 says acceptance "constitutes acknowledgment that the supplies or services conform with applicable contract quality" requirements, ordinarily evidenced by an acceptance certificate. The certificate is worth copying.
Write five things per deliverable:
- The test: "a guest books a dinner slot for two in QA and sees it in the itinerary", never "dining works".
- The environment: QA with real-shaped data, plus a named person for calls that work only in production.
- The window: a number of business days, starting when the build is installed in the agreed environment with that milestone's gates closed.
- The approver: one named person signs, and the other reviewers report to that person.
- The severity rule: only blocking defects stop acceptance. The rest go on a dated fix list.
Then decide what silence means. Sprintlaw notes that silence or production use can count as acceptance if the contract says so. Where UCC Article 2 applies, § 2-606 treats a failure to reject after a reasonable opportunity to inspect as acceptance. Put a number on "reasonable".
Compliance belongs in the criteria. WCAG 2.2 success criterion 1.4.4 requires text that resizes up to 200 percent without assistive technology. The European Accessibility Act covers websites, mobile applications and electronic tickets of waterborne passenger transport services provided to consumers after 28 June 2025. ADA and PCI DSS reviews act as release gates on cruise programs, so their evidence belongs in acceptance.
How to plan the ship window that some of these tests need is covered in our guide to cruise ship app testing.
Milestones that pay for proof
A milestone should end in something the cruise line can inspect, so payment follows evidence instead of the calendar. A sample plan for a guest app:
| Milestone | Accepted when | Gates it needs |
|---|---|---|
| Discovery | Backlog, gate register and build price signed off | Current apps and docs |
| Contract and mocks | Core flows run end to end on mock data in QA | API contract, designs |
| Pre-cruise release | Release candidate passes acceptance, store build uploaded | QA endpoints, store roles |
| Onboard release | Onboard flows pass on the ship network or its simulation | Ship window |
| Store launch | App live under the cruise line's accounts | Accessibility and payments sign-off |
| Warranty | Defect window closes, handover complete | None |
Hold back part of each payment until warranty closes, and state the share in the SOW.
On HSBC iFund, Mercury built two beta UI versions in a prototyping phase, and development continued from the selected one. On DOW Acoustomize and CO2, Mercury delivered an alpha 48 hours after the contract was signed. Dow later compressed the CO2 Calculator from 6 weeks to 4 before a trade show, paid for with a larger team and overtime. A date change is a priced decision.
Change control without a standoff
Every SOW says changes need written approval. A cruise SOW needs three more lines.
- Price each scope cut separately. Cruise buyers ask what each cut removes from the budget.
- Give every change a date impact tied to the gates it touches, alongside the cost.
- Name approvers on both sides with a turnaround in business days. A pending signature is a gate too.
How to price the same uncertainty at the RFP stage is covered in our guide to a cruise software RFP without paid discovery.
Fixed price, capped or gated: which model fits
| Model | Who carries dependency risk | Fits when |
|---|---|---|
| Fixed price per milestone | Vendor, priced into the margin | Gates are closed and scope is specified |
| Time and materials with a cap | Cruise line, below the cap | APIs and designs are still moving |
| Fixed price with dependency gates | Vendor owns the build, client owns the gates | Most cruise programs after a paid discovery |
Cruise procurement often asks for risk margins to come out of a fixed bid. That is safe only once gates are closed, because the margin pays for exactly that uncertainty. When an RFP rules out paid discovery before vendor selection, make discovery the first milestone of the contract.
What our cruise programs show
Mercury's onboard spa platform for OneSpaWorld, which describes itself as the operator of health and wellness centers onboard cruise ships, has been in production since 2018 on over 160 ships operated by multiple cruise lines. The E-Forms platform serves 1,000+ devices and over 3,000 staff members.
For cruise line clients Mercury cannot name under NDA, we build React Native food and beverage apps, dining host and tableside ordering tools, and backend components that aggregate dozens of legacy microservices. The gates in this guide come from that work. Test accounts expire. VPN access arrives late. An API works in production and fails in QA. Some behavior reproduces only on a real ship. Each costs less as a dated gate than as a dispute.
Price the waiting separately
Most cruise SOWs hide waiting inside the build price. The vendor pads the estimate, the client cannot see the padding, and the first slipped gate starts an argument about it.
Put waiting on its own line: a gate register the cruise line can read, a standby rate after agreed idle days, and milestone dates that move with verified gates. The cruise line then controls part of its own schedule, and the vendor stops charging for risk it cannot see.
Then list what the cruise line keeps. Mercury's About page states that all work is work-for-hire and the customer owns the code and all underlying IP. Name mocks and test fixtures among the deliverables, so the next team starts where this one stopped.
Written by Rob Devereaux, Chief Operating Officer at Mercury Development. Rob has run the firm's operations from Hudson, Ohio since 2019 and has over 20 years of operational and financial experience. The contract and delivery records behind this article's cruise examples sit in the operations he oversees.
Drafting a cruise app SOW? Date the gates before you sign
Send us the draft SOW or the vendor's proposal, plus the systems your app depends on. We will mark each client dependency as a dated gate, rewrite the acceptance terms with a starting event and one approver, and show which milestone payments rest on proof.