Most operators do not need an app
Under2 builds mobile apps for travel businesses. We also talk a lot of people out of one, because a guest installs an app for a five-day trip and deletes it on the flight home.
Start with the uncomfortable part
A guest books a five-day trip. To use your app they have to find it in a store, install it, create an account, remember which of their eleven travel apps yours is, and then delete it when they get home. That is four steps demanded before any value arrives, in exchange for something a web page delivers in one.
This is why single-trip guest apps end up costing more per active user than the margin on the trips they support. The cost does not fall as you sell more, because each new guest starts at the same install screen.
So the first thing we do with an app enquiry is try to kill it. If a phone-friendly web page does the same job, that is our recommendation, and we would rather lose the build than ship something your guests uninstall on the way home.
Ask what this does that a web page on the same phone cannot. If the answer is a list of things a web page can do, there is no app. The answers that survive are almost always one of the four below.
The four cases where an app is the right tool
An internal tool for guides
A guide with fifteen guests needs the manifest, the pickup list, the dietary notes and the emergency numbers in one hand, in the rain, on a bus. Daily use, a known user, a company phone. That install is earned.
Work that has to survive no signal
A cave, a boat, a border road, the second day of a trek. An app can hold the day's data on the device, accept input and reconcile when signal returns. The operations that need this are exactly the ones with no coverage.
Capture at the point of work
Photographing a vehicle before handover, collecting a signature on a waiver, scanning a voucher at a gate, timestamping a pickup. Camera, location and a record that cannot be quietly edited afterwards.
Guests who come back
A dive centre, a language school, a city operator with regulars. If the same person opens it a dozen times a year instead of once, every argument above reverses and an app starts paying for itself.
The strongest travel app business case we see is not guest-facing at all. It is the operations side: dispatch, guide manifests, checklists, incident reports. Those users are paid to open the thing, they can be trained, and you are allowed to require it. Nobody is required to install anything.
Offline is a design decision, not a checkbox
Working offline means deciding, screen by screen, what is true when a device has been out of contact for six hours: which data was cached, how stale it may be, what happens when two guides edited the same manifest, and which side wins.
- Read-only offline is cheap. The day's data downloads at the depot in the morning and is displayed all day.
- Offline capture costs more. Input queues on the device and syncs later, and every queued item needs a state a human can see: waiting, sent, rejected.
- Offline editing of shared records is the expensive one. Two people change the same passenger count and the app has to resolve it or surface it. Most projects do not need this and should not pay for it.
We settle which of the three you need before quoting, because the distance between the first and the third is the distance between a feature and a second project.
The release cycle, and the part nobody controls
A web page ships when we deploy it. An app ships when a store allows it. That is a different rhythm and it changes how you plan a season.
- Build and internal testing on real devices, not only simulators
- A test build to your own staff before anything reaches a store
- Store submission, where review time is outside anyone's control — it can be a day, it can be a fortnight, and it can come back asking for a change
- Release, then the tail: a rejected build has to be fixed and resubmitted, which restarts the clock
Plan a first release at eight to fourteen weeks, and never plan it for the week a season opens. If a fix has to reach guests on a particular day, a store queue is a risk a website simply does not carry.
For that reason we keep anything time-critical — prices, schedules, the wording of a policy — in data the app fetches rather than inside the build. Then a change is a data change, not a resubmission.
What an app costs to keep after it is built
The build is the smaller number. An app is a subscription to an obligation.
- Developer accounts with both stores, renewed every year
- An operating system release every year, which routinely breaks something and always needs a rebuild against a new toolchain
- The minimum supported device version moving underneath you, and the annual argument about which old phones to drop
- Two codebases to test if you support both platforms, or one cross-platform codebase with an upgrade treadmill of its own
- Somebody whose job it is to answer store reviews, which are public and permanent
Budget for that as an annual line from the first year, not from the year it starts hurting. An app nobody maintains stops working within about two operating system cycles, and the broken version still sitting in the store does more damage to your brand than never having shipped one.
What we build instead, most of the time
When we talk someone out of an app, the replacement is usually one of these, and it usually costs less.
| What you wanted the app for | What we build instead |
|---|---|
| Guests can see their itinerary | A page per booking, sent as a link — no install, works on any phone |
| Guests can book faster | A checkout on the website that works with one thumb |
| Push notifications during the trip | The messaging channel they already read, plus email — an app has to be installed before it can push anything |
| Guides get the day's list | The internal tool case, which may genuinely be an app |
| The company should look modern | Nothing. This is not a reason to ship software |
When you should not hire us for an app
- If the app exists to prove the company is innovative, we will decline. That app is finished on launch day and abandoned by the next release cycle.
- If you want a guest app for something people buy once, we will propose the web version first and build the app only if you still want it after seeing that work.
- If nobody internally will own it — the store accounts, the reviews, the yearly rebuild — the project has no owner and should not start.
- If it has to be in a store in under two weeks, no. Review queues do not negotiate, and neither do we about that date.
The honest sequence for most operators is to get the website and the booking layer right, run a season, and then look at whether an app is still the thing missing. Usually it is not, and the money has gone somewhere that earned more.
Describe the job, not the app
Tell us what the person holding the phone is trying to do, where they are standing, and whether they have signal. We will tell you whether it has to be an app.
What travel operators ask us most
Can you build one app for both iOS and Android?
Usually yes, with a single cross-platform codebase, which is the right default for internal tools and for most guest apps.
Native code per platform is worth it when the app leans hard on the camera, background location or a device feature that changes with each OS release. We will say which one applies before quoting.
Can the app use our existing booking data?
That is the normal case. The app reads from whatever system holds bookings, through an interface we build or one that already exists, rather than keeping a second copy of the truth.
Where the source system has no usable interface, that work belongs to data and API and is scoped before the app.
Who owns the store accounts?
You do. The developer accounts are registered to your company, with your legal entity and your bank details, and we are added as a developer.
An agency that owns your store listing owns your ability to ship. We will not set it up that way even when it is faster.
Can you take over an app someone else built?
Sometimes. We read the codebase first and give a written assessment, including the case where a rebuild is cheaper than inheriting it.
We charge for that assessment, because it is real work and because a free one always concludes that a rebuild is needed.
Read next
Tell us what you are trying to run
What you sell, what you use today, and what is breaking. You get a written answer with an approach and a price range - not a brochure.