Built for one operator, not for everyone
Six kinds of work we take on. Every one of them starts from what happens operationally, not from a design file.
The six things we build
Travel websites
Operator, DMC, destination and MICE sites. Fast, self-contained, structured for search, with a booking path that works on a phone.
Mobile apps
Guest-facing apps and internal tools for guides and operations, where a browser genuinely is not enough.
Booking integration
Bokun, channel managers and supplier feeds connected properly, so product, price and availability stop disagreeing.
Payment gateway
Taking money online, including international cards, without a checkout that loses a third of the people who reach it.
Data and API
Moving tour, price and availability data between systems, and exposing it to partners in a way they can consume.
Digital transformation
Getting a company off spreadsheets and email attachments and onto something that can be audited and handed over.
How a project is shaped
Nothing is quoted from a wish list. The first step is a short paid or unpaid discovery depending on size, and it produces three documents: what the system must do, what it explicitly will not do in this phase, and how we will know it works.
That third document matters more than it sounds. Our own platform migration rule is that the new system passes an acceptance gate before a single live site moves onto it — never in parallel. We apply the same rule to client projects, and it is the single thing that most often saves a launch.
- Discovery — what exists, what breaks, what it costs you now
- Scope and fixed quotation, with the out-of-scope list written down
- Build in visible increments you can look at, not a black box
- Acceptance gate — a checklist that has to pass before anything goes live
- Cutover, with the old system still standing until the new one has run
- Maintenance, or a clean handover to your own team
What a project costs and how long
| Type of work | Typical first phase | What drives the number |
|---|---|---|
| Booking engine connected to an existing site | 3 - 5 weeks | How editable the current site is |
| New operator or DMC website | 4 - 8 weeks | Number of pages and languages |
| Payment gateway live | 4 - 10 weeks | Bank and gateway approval, not code |
| Mobile app, first release | 8 - 14 weeks | Offline behaviour and app review |
| Data or API integration | 2 - 6 weeks | Quality of the source data |
Indicative ranges are on the pricing page. Every engagement is confirmed in a written quotation before work starts.
When you should not hire us
- If what you need is a logo and a brochure site with no booking behind it, a design studio will do it better and cheaper.
- If the business has not decided who owns product and pricing internally, software will freeze that confusion rather than fix it.
- If you need something live in under two weeks and it touches money, the honest answer is that the approvals will not be finished, whoever you hire.
Describe the project
What you sell, what you run on today, and the date that matters. You get a written approach and a range, not a sales call.
What travel operators ask us most
Do you work with our existing developer or agency?
Yes, and it is common. We are usually brought in for the booking, payment or integration layer while an existing team keeps the front end.
We ask for one named technical contact on your side, because integration work with no counterpart is where schedules die.
Who owns the code at the end?
For custom builds, you do, and the repository is handed over. Platform products remain ours and are licensed to you, which is what makes the subscription price possible.
Which model applies is stated in the quotation, never left ambiguous.
Can you take over a project someone else started?
Sometimes. We will read the codebase first and give you an honest assessment, including the case where rebuilding is cheaper than inheriting.
We charge for that assessment, because it is real work and because a free one always concludes that a rebuild is needed.
Do you provide support after launch?
Yes, as a monthly agreement covering fixes, minor changes and monitoring, or as a handover package if you have your own team.
Support without an agreement is best-effort, and we say that rather than implying a response time we have not committed to.
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.