Cruise software RFP without paid discovery: how to price it in 2026
TL;DR
A cruise software RFP without paid discovery asks vendors to price a product nobody has been paid to define. In 2026 you can still get comparable bids, if the RFP fixes how every vendor prices that uncertainty.
- Ask for a baseline for the scope as written, plus a separate contingency against named risks that you hold and release.
- Where scope will keep moving, buy capped time and materials: fixed rates, a written ceiling, a ranked backlog.
- Send one pricing sheet and read exclusions before totals. Ship testing and offline sync are where low bids go quiet.
- Since June 28, 2025, EU accessibility law covers the websites and apps of cruises leaving EU ports, so accessibility belongs in the baseline.
- Mercury Development's closed contracts for cruise software have a median of $250,000.
Why cruise RFPs arrive without paid discovery
CLIA's 2025 Global Market Report counts 37.3 million ocean cruise passengers in 2025, up 7.7% from 2024. When the software they touch, from booking sites to spa intake forms, is bought through an RFP, the vendor is picked first. Nobody can be paid to study the problem before the price is set. One cruise procurement team told us exactly that: because this was an RFP, paid analysis was off the table.
So the vendor prices from the document. Construx's cone of uncertainty puts estimates made at the initial concept stage at up to 4x too high or 4x too low. Commit at that point, Construx says, and you live with a 2x to 4x error.
Declining to pay for discovery does not remove that uncertainty. It decides who carries it.
EU accessibility law now covers cruise apps and booking sites
Since June 28, 2025, the European Accessibility Act has applied to services provided to consumers in the EU, including the websites, mobile apps and electronic tickets of waterborne passenger transport. The directive takes that definition from the EU sea passenger rules, which apply to cruises sailing from an EU port with more than two nights on board. The microenterprise exemption, under 10 staff, will not cover a cruise line.
CLIA counts more than 9 million passengers who sailed in Europe in 2025.
A vendor that leaves accessibility out of the baseline has not quoted a cheaper app. It has quoted a later change order. In guest app work for cruise line clients Mercury Development cannot name under NDA, release depended on ADA and PCI DSS sign-off, and legal review could stop it.
How we built this guide
We read the pages that rank for this question: PMI's paper on fixed-price contracts, the AIA's guide to contingency allowances and Marine Inspection's fleet software RFP template. None covers custom cruise software priced without discovery.
- Contract mechanics come from those pages and FAR 16.601, read in October 2026. Cruise deal examples come from Mercury Development's records, described without client names.
- Any group of our own data with fewer than three data points is not published.
- This is commercial guidance, not legal advice.
One disclosure. Mercury Development answers cruise RFPs and has built custom software since 1999, so read our advice as a vendor's.
Three pricing structures at a glance
| Structure | What the vendor commits to | Where the uncertainty goes | Fits when |
|---|---|---|---|
| Fixed price from the RFP alone | One total for the scope as written | Hidden padding, or change orders later | Every system and interface is already documented |
| Baseline plus held contingency | A baseline and a risk-priced contingency | A visible line you hold and release | Scope is clear, risks are known but not yet priced |
| Capped time and materials | Fixed rates and a written ceiling | Scope inside the ceiling flexes | Product decisions are still open |
Baseline plus a contingency you hold
In PMI's paper, George Lowden and John Thornton define a contingency reserve as budget for identified risks, the known unknowns. Unknown unknowns go to a management reserve, often a flat percentage of project cost, with 5%, 10% and 15% as their examples. Their test: if the vendor already knows it will spend the money, it belongs in the baseline.
Ask for both halves:
- A baseline for the scope as written, with every assumption numbered.
- A contingency priced as hours against named risks, each with a trigger.
- A release rule: you approve each draw in writing.
- Unspent contingency stays with you.
That last rule comes from construction. In the AIA guide, architect David H. Hart says remaining contingency is the owner's, not the contractor's. He also suggests putting a contingency amount into the bid documents, so every price is built the same way.
On cruise programs the named risks repeat: an API that is not ready, a QA environment unlike production, an undocumented cruise line interface, low-cost tablets slower than the spec. Price each one.
Expect pressure on this line. We have priced a cruise RFP with contingency as its own line and been asked to take it out. Deleting the line removed the visibility. The risk stayed.
Capped time and materials: fixed rates, written ceiling
A cap turns time and materials into a budget you can defend. Under FAR 16.601, US federal T&M contracts are for work whose extent or duration cannot be estimated accurately, and they carry a ceiling price the contractor exceeds at its own risk. Cruise lines are not bound by the FAR, but the mechanism travels.
Decide which cap you are buying:
- A hard cap at the vendor's risk. Hours past the ceiling are the vendor's loss, so expect pricing close to a fixed bid.
- A soft cap, the plain T&M default in PMI's paper. The supplier need not work past the ceiling, and the client carries the risk of extra time.
Make the ceiling useful:
- Attach a ranked backlog, so the ceiling buys the top of the list first.
- Ask for weekly burn reports and a notice point well before the ceiling.
- Agree how the team scales. Mercury Development's About page states the team structure can be updated within 2 weeks of a customer request when skill set, pace or burn rate must change.
We have been asked for this structure once scope was defined, together with a second request: strip the risk margin to match competing bids. Ask what those bids assumed.
How to write the ceiling, the gates and the acceptance rules into the contract is covered in our guide to the software development statement of work.
What cruise software bids leave out
Hart puts it bluntly for design-bid-build: the contractor who makes the most mistakes in bidding is typically low. In cruise software the mistakes cluster. Read every response for these lines:
- Offline behavior: what works on board when the shore link drops, and how records sync once it returns.
- Testing on a real vessel, because some behavior reproduces only at sea.
- Client-side access: VPN, test accounts, API documentation. Programs stall on these before the first sprint.
- Cruise line interfaces, priced one by one.
- Compliance: accessibility, PCI DSS for payment flows, privacy rules for guest health answers on spa forms.
- Running costs. One of our cruise estimates listed cloud-based messaging as an extra cost outside the price.
- App store accounts and the target hardware, at the price you will pay.
A missing line is not a saving. It is a change order waiting.
How to compare vendor responses line by line
Send one pricing sheet and make every vendor use it. Marine Inspection's template goes further: any cost not entered in the sheet is not payable, and scoring weights go out before responses arrive. Both rules transfer to custom cruise software.
Give it columns for baseline, contingency with its risk list, rate card, cap type and ceiling, exclusions, client-side dependencies with dates, and change-order rate.
Then normalize:
- Read exclusions before totals, and ask each vendor to price what it left out.
- Compare baselines, not totals. A vendor that folded contingency into its baseline looks expensive next to one that ignored the risk.
- Price scope cuts. One cruise buyer asked us for the exact amount each proposed cut would remove. Every RFP should ask every vendor for that table.
- Run one scenario in orals: the shore link drops mid spa check-in. A team that has shipped onboard software names the queue and the conflict rule. A team that has not names the cloud.
Typical budgets and what each scope cut saves are in our guide to cruise app development cost.
Which structure fits your cruise program
- A bounded tool on documented systems, such as a kiosk form for one fleet: baseline plus held contingency, priced per milestone.
- A guest app rebuild with APIs and design still moving: capped time and materials with a soft cap.
- A fixed board budget: capped time and materials with the ceiling at the budget.
- A supplier serving several cruise lines: a baseline for the shared platform, then each line's interface as its own pack with its own contingency.
If you can buy a small paid discovery after all, the two-phase route in our guide to fixed price RFPs works for cruise programs too.
What our cruise programs show
From Mercury Development's cruise deal records: our closed contracts for cruise software have a median of $250,000.
The commercial pattern repeats. In the RFP-led cruise deals in our records, procurement resisted paid discovery before a vendor was selected, and once scope was defined, buyers pushed for capped exposure and lower risk margins. Our answer is the structure in this guide.
So does the delivery pattern: login tokens issued on shore that fail on the ship, APIs that work in production but not in QA, expiring test accounts, slow VPN access. Each belongs on a contingency risk list.
The work behind these patterns: Mercury Development's spa platform for OneSpaWorld, a client named in our portfolio, has run in production since 2018 on over 160 ships operated by multiple cruise lines, on onboard servers without external internet. Its E-Forms platform serves 1,000+ devices and over 3,000 staff members. For cruise line clients Mercury Development 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.
Price the uncertainty instead of hiding it
Opinion, stated plainly. Declining paid discovery does not skip discovery. It moves it into the first weeks of the build, paid at build rates.
So stop asking for a number with the uncertainty taken out. Ask vendors to price it where you can see it. The vendor that shows its risks is usually the one that read your RFP.
Put one more line in every cruise RFP: who owns the code. At Mercury Development, all work is work-for-hire; the customer owns the code and all underlying IP. If a vendor stalls at the ceiling, the next one starts from your repository.
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 deal and contract records behind this article's cruise pricing examples sit in the operations he oversees.
Issuing a cruise RFP without discovery? Get the pricing structure checked first
Send us your draft RFP or scope, the systems the product must touch, and any budget or date that cannot move. We will reply with how we would price it: what goes in the baseline, which risks belong in contingency, and where a capped ceiling fits better.