Six steps, and the gate in the middle
Every Under2 project runs the same six steps, in the same order. The one that matters most is the acceptance gate, because it is the step that decides whether a go-live is an evening of checking or a week of apologising.
The six steps
The same list appears on the services hub. Here each step is described by what it produces.
Discovery
What exists, what breaks, what the breakage costs you now. Produces three documents, described below.
Scope and quotation
A fixed scope with the out-of-scope list written down, and a number against it. Nothing is built before this is signed.
Visible increments
Work you can open and click at intervals, not a black box that opens once at the end.
Acceptance gate
A checklist agreed in the scope, run against the real system. It passes or it does not; there is no partial pass.
Cutover
The move to live, with the old system still standing until the new one has actually run.
Handover or maintenance
Repository, credentials and documentation to your team, or a monthly agreement.
Discovery produces three documents, not a slide deck
Discovery is short and it is written. Not a workshop with sticky notes, and it does not end with a design. It ends with three documents, each with a job.
| Document | What it answers | Why it exists |
|---|---|---|
| What the system must do | The behaviours the business needs, in operational language | It is the thing we build against, and the thing you can hold us to |
| What it will explicitly not do in this phase | The features consciously left out, with the reason next to each | It is what makes the quotation hold, and it prevents an argument later |
| How we will know it works | The checks that have to pass, written before anything is built | It becomes the acceptance gate, so nobody invents the criteria at the end |
The second document is the one clients resist and later quote back to us. Writing down what a phase will not do feels like admitting a limitation. It is the only way a fixed price survives contact with a real business, because everything not on the first list has somewhere to go instead of quietly landing in the build.
The third is written before the first line of code. If a check cannot be described in advance, the requirement behind it is not decided yet — far cheaper to discover in week one.
The acceptance gate
This is the part of how we work that we would defend hardest.
The rule: the new system passes the gate before a single live thing moves onto it. Never in parallel. Not "we will migrate the small ones while finishing the checks". The checklist passes against the real system, with real data, and only then does anything move.
We apply it to our own products first. The 2026 rebuild of izBooking onto a new white-label stack moves merchant sites in controlled batches, and the platform had to pass its gate before the first of those sites was touched. Seven are being moved this way rather than everything at once.
Why parallel running is the expensive option
Running old and new side by side sounds cautious. In a booking business it is the opposite, because availability cannot be in two places. The moment both systems can sell the same seat, someone has to decide by hand which one is right, at exactly the hour when nobody is available to decide anything.
A gate is unpopular for about three days and then it is the reason the launch is boring. It is the single step that most often saves a go-live.
The behaviours from the third discovery document, turned into checks anyone can run: a booking that completes, a payment that clears and refunds, an availability change that reaches every channel, a cancellation that releases the seat, a confirmation email with the right brand on it, and the rollback that puts everything back if one of those fails.
Who has to be there on your side
Every project that has gone badly for us had the same missing piece, and it was never the budget.
- One named technical contact. Somebody who can get us DNS access, hosting credentials, the gateway account, the Bokun keys. Not a department, a person with a name.
- One commercial decision maker who can settle a pricing or cancellation rule without convening anyone.
- Someone from operations who will actually use the system daily, present at the increment reviews rather than at the launch.
The technical contact is where schedules die. An integration waiting for credentials does not fail loudly; it sits, and two weeks later the date has moved and nobody can point at the day it slipped. We ask for the name before the quotation and write it into the scope.
How progress is reported
Internally, work runs through Lark Base, which is also where enquiries and pipeline live. Externally you get three things and no more, because a report nobody reads is a cost with no benefit.
- A short written update at a fixed interval: what moved, what did not, what changed in the estimate.
- The open decision list — questions waiting on you, with the date each one starts costing time. Usually the most useful item.
- The increment itself, on a link you can open on a phone.
We do not send screenshots of task boards as evidence. A board full of moved cards and a system that cannot yet take a booking are not the same thing.
What happens when the scope grows
It will. A build that runs two months in a real company always meets something nobody thought of. The useful question is not how to prevent that but where it goes when it arrives.
| The request | What we do |
|---|---|
| Costs us essentially nothing | We do it and say we did, rather than banking it as a favour to call in |
| Real work, not urgent | It goes on the next-phase list, with a note, and is quoted after launch |
| Real work and genuinely needed now | A change note with cost and date impact; nothing is built until it is accepted |
| Contradicts something already built and signed off | We stop and get the decision made, because building both is how a project becomes unmaintainable |
The only thing we refuse is silent scope. Work that appears without a note is work somebody is paying for without knowing it, and that somebody is eventually the client or the date.
Handover, and who owns the code
For custom builds, you own the result. Repository, deployment configuration, credentials and documentation are handed over, and the handover is a scheduled task in the plan rather than a favour after the invoice.
For platform products the software stays ours and is licensed to you — that is what makes a subscription price possible instead of a build price. Your data is yours in both cases, and the export is written into the contract rather than offered as goodwill at the point you want to leave.
Which model applies is stated in the quotation. We have never seen a good reason to leave that ambiguous.
Projects we turn down
Refusing early is cheaper for both sides than discovering it in month two.
- Work outside travel. A restaurant or clinic booking system is somebody else's.
- Design-only engagements where nothing operational changes behind the screen.
- Anything that would have us selling tours in competition with the operators running on our own platform.
- A payment integration that has to be live in under two weeks. No bank moves at that speed for anyone.
- Building before the scope is agreed, on the understanding that details get sorted later. That is the arrangement in which everybody loses.
Start with the discovery
Send what you sell, what you run on today and what breaks most often. That is enough for us to describe an approach and a range in writing.
What travel operators ask us most
How long is discovery?
For most projects it is days rather than weeks — long enough to read the current system, talk to the people using it and write the three documents.
For a digital transformation programme it is longer, because the subject is how a company works rather than what one system does.
Can we skip the acceptance gate to hit a date?
No. That is the one step we will not shorten, because the gate exists precisely for the projects that are running late, when the temptation to move a live site onto an unproven system is highest.
We will happily cut scope to hit a date. Cutting the checks is how a date is hit and a season is lost.
Do you work with our existing developer or agency?
Often. We are usually brought in for booking, payment or integration work while an existing team keeps the front end, and the split is written into the scope so nobody is guessing where a bug belongs.
This is another case where one named technical contact on your side is not optional.
What if we want to stop the project halfway?
You pay for the work completed to the last accepted milestone and you take what exists, including the documents from discovery.
We do not hold code or credentials as leverage. A supplier who does that is telling you something about how the relationship will end.
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.