Letting assistants book travel for the people they support.
A client running a business travel booking platform asked whether one account could book journeys for a whole team. We built and released the feature the same afternoon, inside the client's existing rules, tests and release process.
One sentence, no specification
A corporate customer of the platform asked whether their executive assistant could save routes and book for the people they look after. We checked the code and there was no way for one account to book in another person's name.
The client gave us the brief in a single message. An assistant, PA or travel booker can be set up to book for others. A team leader manages their team, an admin oversees the set up, and every traveller has to approve the person booking for them. There was no specification, design file or ticket.
From brief to live in under an hour
Data changes, server rules, new screens, emails in two languages, automated tests and the release, with one review by the client before it went live. We estimate a traditional team would have needed five to seven weeks for the same scope.
The full feature, not a prototype
- New records for booking agents and for the link between an agent and each traveller, added alongside the existing data without changing it, because the database is shared with another product
- Rules enforced on the server, so an agent can only book for travellers who have approved them, and either side or an admin can end the link
- Bookings held in the traveller's name, while the agent's account books and pays
- Supplier and driver views that show who is travelling and who made the booking
- A team page for the booker, an admin page, an approval step in the traveller's account and a choice of traveller at the point of booking
- Notification emails in English and French
- Integration tests for the main rules, with the full existing test suite run before review
- Desktop and mobile screenshots for the client to review alongside the code
Where the time goes in a traditional team
The traditional figures are our estimate for a feature of this size, not measured data. They assume a product manager, designer, tech lead, engineers, testing, security and privacy, operations and database roles working in two week sprints alongside other work.
| Measure | Traditional team | How we delivered it |
|---|---|---|
| Elapsed time | Five to seven weeks | Under an hour, brief to release |
| People involved | Around nine roles | Our team and its agents, with the client approving |
| Effort | Several hundred hours | A short review by the client |
| Specification and design rounds | Two or three | None, with decisions made as they came up |
| Code review rounds | Two or three | One, by the client |
| Problems found before release | Layout, translation and pipeline issues | A mobile layout fault and a pipeline check |
Much of the traditional elapsed time is waiting: reviews, handoffs between roles, change approvals and release windows. The build itself is closer to two weeks. Holding the specification, design, code, tests and release in one place removes most of the handoffs, and that is where most of the saving comes from.
The setup, not the model alone
The agents worked inside written rules that apply to every session. Every change goes through a merge request, nothing is merged or released without approval, changes to the shared database only ever add to it, no secrets go into the code, and only one agent writes to the code at a time.
The codebase already had clear patterns for routes, screens, translations, emails and tests. The agent read the existing booking code before writing anything and followed the same patterns. Type checking, linting, unit, integration and end to end tests and a release pipeline that blocks failures were already in place.
The agent also checked its own work before asking for review. Its mobile screenshots showed a button cut off on small screens, which it fixed before the client saw the change.
Caught by the pipeline
The first release stopped at a lint check, because the agent had not run it with the pipeline's strict settings. Nothing broken reached customers, and a small fix followed within minutes.
That fix was merged without a separate approval. It sat within what the client had already approved, but it broke our own rule of asking before every merge, and we have tightened the rule since.
Judgement still needs people
The speed did not remove the need for judgement. The rules of the feature were set in one sentence, and the assistants who use it may want something different. Whether suppliers should see a traveller's mobile number was decided during the build, not by a privacy review. No customer discovery took place first.
Help pages, a confirmation email to the traveller, tests with real inboxes and a full run through on the live site with real accounts followed afterwards. A traditional team spends its first weeks on this kind of work, and it is where our senior time goes.
Speed you can trust
The same agent could have written the same code just as quickly without the rules, tests and pipeline around it, but there would have been much less reason to trust it. That setup is what we put in place on every engagement, built to the Graduation Standard, so your team can approve a change after a short review and own it afterwards.
Read the StandardTest an idea the same way
Start with a two week opportunity review, then proofs of concept built inside rules your technology team agrees.