Small core, one named counterpart, partners at the edges
This page describes how work is staffed rather than listing faces. What matters when you hire a small studio is which roles turn up, who answers you on a Tuesday afternoon, and what happens when that person is ill.
No names and no photographs, on purpose
A team page full of headshots tells you almost nothing useful. People change roles, and a name on a marketing page is not a contractual commitment that the same person will be on your project in month three. We would rather describe the roles that will genuinely be involved and let you hold us to those.
Who is assigned to your work is named in the quotation, before anything starts, and named again if it changes.
The five roles on a project
Not every project uses all five, and on a small build one person carries two of them. What does not happen is a role quietly going missing — if nobody is doing integration, integration will not happen because a developer is busy.
Discovery and analysis
Establishes what exists today, which system holds the truth, who edits it, and what the current mess costs per month. Produces the scope and the out-of-scope list.
Development
Builds the thing. Core developers on the parts that need product knowledge, outside partners on well-specified components.
Integration
Bokun, channel managers, payment gateways, supplier feeds. Usually the role that decides whether a launch date survives, because it depends on other people's systems and approvals.
Content and search
Page structure, wording, structured data, images. On a website project this is not decoration; it is the difference between a site that gets found and one that only looks finished.
Operations
Deployment, backups, monitoring, the acceptance checklist, and the boring work of making sure the old system is still standing on cutover day.
Why the core is about ten people
Ten people in Hanoi, plus outside development partners engaged per project. It is a deliberate shape with a real cost, so here are both halves of it.
What it buys you: everyone in the core has context on the products and the travel domain, decisions do not travel through three layers, and we have no bench to keep busy by selling you work you do not need.
What it costs you: we cannot absorb a doubling of scope without moving dates, and a specialist skill missing from the core is bought in, which takes a week or two to arrange.
| Kept in the core | Brought in from partners |
|---|---|
| Product and domain decisions | Well-specified build components |
| Integration design and payment flows | Extra front-end capacity at peak |
| Client communication | Native-language content beyond English and Vietnamese |
| Deployment and production access | Specialist mobile or design work |
Partner developers work to a written specification, their output is reviewed by the core, and production credentials stay inside the core team.
Who you actually talk to
One named person on our side, from the first quotation through to handover. Not a shared inbox, and not an account manager who forwards your question to someone technical and forwards an answer back two days later.
In return we ask for one named person on your side who can decide about product and pricing. Integration work with no counterpart is where schedules die, and we say that before starting rather than after.
If your counterpart is not resolving something, you escalate to the person who signed the quotation. There is one step, because there are only ten of us.
What happens when someone is ill, or leaves
A small team has an obvious weakness and pretending otherwise would be insulting.
Everything that matters is written down rather than held in one head: the scope and out-of-scope documents, the acceptance checklist, the deployment runbook, and the reasoning behind the awkward decisions. At least two people in the core can deploy any system we run.
What we will not claim is that an absence is invisible. If the person doing your integration is out for two weeks, the schedule moves, and you hear it from us that week rather than at the deadline. A studio that promises seamless cover from a team of ten is describing a company it does not have.
Working alongside your own technical team
Roughly half our project work sits next to an in-house developer or an existing agency, and that arrangement works well when the boundary is drawn on paper before anyone writes code.
- A written split of responsibility: which system each side owns, and who deploys what.
- One named technical contact on your side, with time actually allocated to us.
- Shared access to the repository from the start, not at handover, so nothing is a surprise on the last day.
- An agreed answer to who is called at 9pm when a payment fails, decided before launch rather than during the incident.
If your team owns the build and wants only the booking or payment layer, that is a normal engagement and often the cheapest useful one — see booking integration and payment gateway.
Hiring
We hire slowly and rarely, and we do not run a graduate intake. What we look for, in the order it matters:
- Curiosity about the business problem. A developer who asks why a hold is fifteen minutes rather than implementing fifteen minutes.
- Written clarity. Most of our work is explained in writing to people who are not engineers, in English or Vietnamese.
- Finishing. Deployment, migration and the last ten percent are the job, not an afterthought.
- Comfort with someone else's mess. Travel systems are inherited, not greenfield.
What we do not test for: memorised algorithms, a specific framework, or a degree. We ask instead for something you have built and can explain the failure modes of.
There is no permanent vacancy list here. If the roles above describe you, write through the contact page. We answer, including when the answer is that we are not hiring.
When this team shape is wrong for you
- You need thirty developers staffed by next quarter.
- You need people onsite in your office every day.
- You need a supplier who can pass a large enterprise security questionnaire with certificates attached — see the security page for exactly what we do and do not have.
- You want a single supplier to own brand, marketing, media buying and software. That is not us, and we would subcontract most of it badly.
Describe the project and we will tell you who would be on it
Including the case where the honest answer is that a different kind of supplier fits better.
What travel operators ask us most
Will the people who pitch be the people who build?
Yes. With a core team of about ten there is no separate sales department, so the person answering your first email is the person who will run or build the work.
Where an outside partner is used for part of a build, that is stated in the quotation rather than hidden behind our logo.
Do you work in English or Vietnamese?
Both, day to day. Documents, scopes and acceptance checklists are produced in whichever language your decision-makers read, and sometimes in both.
Content work in other languages is arranged through partners, and we say so rather than running it through machine translation.
Can we meet the team before signing?
Yes, and we prefer it. A call with the person who would run the project is more useful than a credentials deck, and it is where most misjudged briefs get caught.
Our working day is GMT+7, and we schedule early or late in Hanoi to overlap with Europe or the Americas.
What happens to our project if Under2 gets busy?
We turn work down or give you a later start date. Taking a project we cannot staff and then discovering it in month two is worse for both sides.
If we are the wrong size for what you need, we say that in the first written reply rather than after a discovery phase you paid for.
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.