Ship It Live — $1,999 flat
Design + build + deploy · kickoff in 24h · limited slots
Ship It Live · travel sprint
Trips searched, booked and paid for, in 30 days.
Tours, stays and experiences sold directly, with the deposit taken and the itinerary in the traveller's pocket.
Quick answer
A travel booking app can be designed, built and taking bookings in 30 days for a fixed $2,500, covering inventory and availability, search and filters, the booking and payment flow, itineraries and traveller details. Live GDS or airline inventory integration depends on your provider contract and is quoted separately.
The plan
Day one to day 30, written down.
You get this schedule before you commit, not after. If a phase slips, that is mine to absorb — the price and the date were agreed before anything started.
- 1
Days 1–3
Scope lock
What you sell, how availability really works, and your rate and cancellation rules. Travel pricing has more exceptions than any other vertical, so this is a long conversation.
- 2
Days 4–12
Design
Search results and the trip or room page — the pair that sells — then the booking flow and the operator views.
- 3
Days 13–24
Build
Inventory, availability engine, booking and payments. Double-booking protection and date maths get tested hard, because both fail quietly.
- 4
Days 25–28
Book real trips
Real bookings through real dates, including the awkward ones — cross-month stays, group changes, cancellations inside the window.
- 5
Days 29–30
Launch
Payments live, your inventory published, and the team trained on the dashboard.
What $2,500 gets you
Everything needed to launch — nothing padding the invoice.
Who books this
Built for
Tour operators taking bookings by email and spreadsheet
Hotels and lodges paying 15–20% to booking platforms
Travel startups with supply lined up and nowhere to sell it
Real situations
Five ways this shows up, and what actually fixes it.
Not hypothetical — the shape of the problem before someone books this sprint, and the specific part of the build that resolves it.
Situation 1
Taking bookings by email and spreadsheet in a growing business
A tour operator or lodge manages availability and bookings through email threads and a shared spreadsheet, which becomes error-prone as booking volume grows.
A real booking flow with availability rules and traveller details replaces the spreadsheet, with automatic confirmations and itineraries.
Situation 2
Paying 15-20% to a booking platform for guests who already found them
A hotel or lodge pays a substantial commission to a booking platform even on guests who discovered them independently and would have booked directly if given the option.
Direct booking and payment, with the platform kept only as a discovery channel, stops the commission on guests who already know the property.
Situation 3
Travel supply lined up, no sales channel to sell it through
A travel startup has secured inventory — tours, stays, experiences — but has no platform of their own for customers to search, book and pay through.
Search, availability and Stripe checkout ship in 30 days, giving that secured supply an actual place to be sold.
Situation 4
Rate and cancellation rules too complex for a generic booking tool
A travel business's pricing has seasonal rates, minimum stays and cancellation exceptions that don't fit cleanly into an off-the-shelf booking system's assumptions.
Days 1-3 are spent specifically mapping those real pricing and cancellation rules, because travel pricing has more exceptions than any other vertical.
Situation 5
Guests arriving without an itinerary they can actually access
Travellers currently receive booking confirmations that aren't practical to reference once they've landed and lost signal or roaming.
Itineraries are delivered by email and openable offline on the phone — a detail that matters far more than it sounds once someone actually lands.
The honest part
When 30 days is the wrong answer.
A fixed deadline only works when the scope genuinely fits inside it. These are the cases where I will tell you so rather than take the booking.
GDS, airline or channel-manager integration — Amadeus, Sabre and similar. Technically feasible, contractually slow, and outside my control, so it is quoted only once your access is confirmed.
Aggregating other operators' inventory with individual payouts. That is the marketplace sprint, and I will point you there.
Dynamic pricing engines that reprice against demand and competitors, which is a data product rather than a booking flow.
Inside the 30 days
- Inventory: trips, rooms or experiences with dates, capacity and rates
- Search and filters built around how travellers decide, not how you file things
- Availability and pricing rules — seasons, minimum stays, group sizes
- Booking flow with traveller details, extras and special requests
- Deposits or full payment through Stripe, with your own cancellation rules
- Automatic confirmations and itineraries the traveller can open offline
- An operator dashboard: bookings, occupancy, manifests, payments
- Source code, design files and 30 days of support at handover
Quoted as one number before day one. A week running long is mine to absorb.
Outside the line
- GDS, airline or channel-manager integration — Amadeus, Sabre and similar. Technically feasible, contractually slow, and outside my control, so it is quoted only once your access is confirmed.
- Aggregating other operators' inventory with individual payouts. That is the marketplace sprint, and I will point you there.
- Dynamic pricing engines that reprice against demand and competitors, which is a data product rather than a booking flow.
Real work, sized and priced separately. You hear it before you book, not at handover.
Questions
Before you book
Yes, for your own inventory with your own rates. The month covers search, availability, booking, payments and itineraries. What sits outside is live airline or GDS inventory, which is a contract question before it is a build one.
Other sprints
30 days from now, this could be live.
A 30-minute call decides whether the scope fits. If it doesn't, I'll tell you what would.