The kinds of system we have had to keep running
This is not a logo wall. It describes the kinds of travel system Under2 has built and kept running, what each one broke, and where the lesson ended up in the products.
Read this first
A client's name is theirs to publish, not ours. This page describes the kind of business, the system we built and what went wrong along the way. If you want to speak to a business with a case like yours, ask, and we arrange it with their agreement.
A second thing we do not do here: publish results. There are no traffic figures, no revenue, no conversion rates attached to any project below. A number without an independently verifiable source is decoration, and travel technology is full of it. What this page shows is which kinds of system we have had to keep alive, and what each of them forced into the products.
An inbound DMC selling on Bokun
An inbound DMC selling Vietnam to foreign visitors, with Bokun as its booking system and a website that has to read from it correctly. This kind of project is why our team knows Bokun the way it does — not from documentation, but from a business that loses money when a product mapping is wrong.
An inbound DMC is a demanding case for software. Products sell in several currencies to buyers in several time zones, agents ask for holds before they confirm, and the same tour exists as a private departure, a joined group and an agent rate at once. Every one of those is a way for availability and price to disagree.
The integration work we sell is shaped around the failures these builds exposed: stale prices pushed by a channel, catalogues that match on name and nothing else, holds that expire at the worst possible minute.
Walking tours booked the same day
Short walking tours sit at the opposite end of the spectrum from a DMC: the guest journey is short, the booking window is measured in hours, and most traffic arrives on a phone from a hotel lobby.
Short-lead-time products punish slow websites in a way long-haul tours do not. Somebody deciding what to do this afternoon does not wait four seconds for a page. That is where our habit of building static, self-contained sites with no third-party scripts came from — not from a benchmark score, from watching how people actually book a tour that starts in two hours.
Free tours — the booking with no payment at all
Some tours are free. No money, no checkout, no payment gateway, and there never will be. It is the clearest example of something we say on the payment page: a booking system is not a payment system, and plenty of travel businesses need the first without the second.
Remove payment from a booking flow and what remains is more interesting than it sounds. Capacity is still finite, because a guide can only walk with so many people. Confirmations still have to arrive and be understood abroad. Cancellation matters more, not less, because nothing was paid — a free booking is the easiest thing in the world not to turn up to, so the reminder and the release rule carry the whole operation.
- The system has to lose the payment step entirely, not hide it behind a zero price. A checkout charging nothing is a checkout that will still fail.
- No-show behaviour is the real problem to design for, not fraud.
- The confirmation and the reminder do the job the deposit does elsewhere.
- Any platform assuming money exists in every flow fails this case, and a surprising number of them assume exactly that.
Destination and MICE sites on one engine
A large share of our website work is destination and DMC-facing sites: a city or a region, a multi-country itinerary, a conference venue. They share one engine and one publishing approach, and they are where the website service was actually developed.
| Kind of site | What it has to do |
|---|---|
| Destination site | Answer what a visitor searches before they know any company name, and hand a qualified enquiry on |
| Multi-country itinerary site | Show long programmes day by day without turning into a wall of text on a phone |
| DMC site for agents | Give an agent net-rate context and a quote they can forward, rather than a consumer checkout |
| MICE site | Produce a well-formed group enquiry — dates, numbers, budget — rather than a booking |
Building the same kind of site repeatedly turns a website project into a system. Structured data, itinerary pages, enquiry handling and how a booking path behaves on a phone stopped being per-project decisions and became defaults, which is why a new site takes weeks rather than months.
MICE sites deserve a note. Nobody buys a conference for two hundred people from a checkout. Those sites exist to produce a qualified enquiry, and their design goal is the quality of the form submission, not a booking count.
What these builds taught the software
Keeping systems like these running every day has one specific advantage, and it is not credibility. A plausible-looking system that fails in week three is not an option, because the failure reaches a real guest.
| What the builds taught us | Where it ended up in the product |
|---|---|
| Availability in two systems eventually sells the same seat twice | One source of truth, and the acceptance gate before any migration |
| A guest who does not recognise the statement name disputes the charge | Brand, entity and descriptor treated as one decision, not three |
| A free product still needs capacity, confirmation and release rules | Payment is a removable module, not a required step |
| Short-lead-time bookings are lost to page weight | Static sites with no third-party scripts in the booking path |
| An enquiry that is lost is worse than one that is slow | Enquiries are written to a log file before any external call is attempted |
The last row is the smallest and the one we would keep if we could keep only one. Every form on this site writes to disk first, then sends to Lark and to email. When a webhook is down, the enquiry is still there. That is not clever engineering; it is what you build after losing one.
What this page cannot tell you
A description of past builds proves some things and not others.
- It shows the kinds of system we have kept running. It does not show how we behave on your project — ask for a reference in the conversation instead.
- It shows breadth of travel product, from a free walking tour to a MICE enquiry. It does not show scale beyond what we publish: over a thousand merchant sites on izBooking, and nothing else quantified.
- It is not relevant to you at all if you are outside travel. We do not take that work.
- It does not include results, and it will not start to. Any figure here would be one we produced and audited ourselves, which is not evidence.
Ask about the case closest to yours
Tell us what you sell and how bookings reach you today. We will point at the build above that resembles it and what it cost in time.
What travel operators ask us most
Why are no clients named?
Because a client's name is theirs to publish, not ours. The page describes the kind of business and the system instead, which is the part that tells you whether a case resembles yours.
If a reference matters to your decision, ask. We arrange it with the client's agreement, for the kind of project you are running.
Why are there no results or traffic numbers?
Because we would be the source, the auditor and the beneficiary of every figure, and a number like that is worth nothing to a reader who cannot check it.
In a conversation we will talk about what a specific build cost in weeks and what changed operationally, which is checkable against your own situation.
Can we see a demo of one of these systems?
We will walk through a real booking flow with you rather than a prepared demo environment, because the interesting parts are cancellations, holds and refunds.
For izBooking specifically the product page describes what the platform does and what stage the 2026 rebuild is at.
Do you work for businesses that compete with each other?
Yes, and it is worth understanding how that is kept clean. Product data and customer data belong to each merchant, and nothing moves between clients.
If a specific overlap concerns you, raise it before the scope is signed and we will put the boundary in writing.
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.