Group travel is sold business to business: an operator buys blocks of seats or charters an aircraft, and travel agents book those seats for their own customers. The client wanted software that let agents enquire, negotiate, pay and book on their own, while the sales and operations team kept control of pricing, inventory and money.
Codevibe, a software development company in Gurugram, designed and built the whole platform: a public website that never shows a price, one panel for every role, and the API that enforces every rule. Phase one went live ahead of the 60-day deadline; the same team has kept adding to it weekly since.
The client asked that their name not appear in any public material. We have kept the brand, the domain and the product name out of this page and its images. The figures, the architecture and the integrations are taken directly from the codebase as it stands.
What had to be true on day one.
In most group-travel businesses this trade runs on phone calls, WhatsApp threads and spreadsheets. Someone quotes from memory, the seat count lives in one person’s head, and money is reconciled at month end. It works until it does not scale, and it leaves no record of who agreed what.
The brief: replace that with software three groups could rely on. Switch between what was asked for and what is live today.
For travel agents
- Ask for a group or a chartered flight without phoning anyone.
- See the quote, push back on it, and accept it in one place.
- Search seats the operator already holds and book them on the spot.
- Pay from a prepaid wallet or online, and download the ticket.
For the sales and ops team
- Every enquiry, from every channel, in one inbox.
- Build a quote, send it, and keep every version on record.
- Upload seat inventory from a spreadsheet without breaking anything.
- Record the airline PNR and the ticket against the booking.
For the business
- Prices are never public. Only logged-in agents see inventory.
- Money is tracked to the rupee: wallet, ledger, invoices, refunds.
- The marketing site, blog and landing pages are editable in-house.
- Go live in 60 days, then keep improving every week.
“The hard part was deciding what not to build: one panel instead of three apps, rules in the database instead of the screens, and a 60-day line we would not cross.”
Five phases. Shipped before the line.
Tap a phase to expand it.
The client’s brief became an architecture document, a 60-day scope of work, and an open-questions log both sides could read. The biggest decision was made here, on paper: one panel where permissions decide what each person sees, instead of separate apps for agents, sales and admin. That removed months of duplicated screens.
Before any feature, the ground: one repository for the website, the panel and the API; the database schema; login and permissions enforced on the server; a shared design system; and the Docker setup that later ran production. Boring on purpose, so everything after it could move fast.
The core of the business, end to end: enquiry, lead, quote, negotiation, acceptance, payment plan, Razorpay, PNR, ticket. Every round of a negotiation is kept, every payment is verified before it is recorded. Phase one shipped on this, before the deadline.
The second product line. Staff upload blocks of pre-bought seats from a spreadsheet, checked row by row. Agents search what is on sale and book, paying from a prepaid wallet in the same transaction that locks the seat count. A double-entry ledger records every movement; refunds need approval.
With bookings flowing, the things a growing business asks for next: leads arriving on their own from Meta ads and WhatsApp, notifications with editable templates, GST invoices and credit notes, a CMS with approvals, reports, and a secrets page. Each went live as its own release, usually within a week of being asked for.
Five people. A report every day.
Five people from the Codevibe team were assigned to this project. The client dealt with one of them; that one ran the other four.
Group-travel operator. Read the daily report, joined the weekly call, answered the open questions.
One point of contact. Owned the scope, sent the daily report, ran the weekly call, kept the open-questions log current.
Architecture, data model, the money path. Reviewed every pull request.
Payments, wallet and ledger, lead parsing, notifications, scheduled jobs.
The role-based panel: leads, quotes, inventory, bookings, invoices.
Public site and CMS, design system, infrastructure, deploy pipeline.
- Every day: a written report to the client. What moved, what is blocked, what is next.
- Every week: one call. Demo what shipped, agree the next slice, close open questions.
- Every change: a pull request, reviewed by another engineer. No direct pushes.
- Most weeks: a release. The build runs in GitHub Actions; the server pulls the exact commit.
Which day the call fell on is illustrative. The daily report, the weekly call and the reviewed pull requests are not.
One booking, start to finish.
The path every group booking takes. Each step names who acts and what the system records. This is what phase one had to get right, and what went live first.
Fills the public form. A lead is created with a reference number.
- 01 · Travel agentEnquiry
Fills the public form. A lead is created with a reference number.
- 02 · AdminLead inbox
Qualifies the lead, invites the agent to open an account, assigns a sales owner.
- 03 · SalesQuote
Builds a priced quote. Every version is saved.
- 04 · Agent and salesNegotiate
Accept, reject or push back with remarks. Each round is recorded.
- 05 · AgentAccept
A payment plan opens with instalments and a validity date.
- 06 · AgentPay
Razorpay or wallet. The webhook is verified before anything is written.
- 07 · OperationsPNR
Records the airline PNR. The booking is confirmed.
- 08 · OperationsTicket
Uploads the ticket. The agent downloads it and the invoice.
Eight parts, explained two ways.
The shape of the system first, then each part described twice: plain language for anyone, specifics for engineers.
Enquiry form, blog, route landing pages. Never shows a price.
One app for every role. Permissions decide the screens.
33 controllers, 239 endpoints. Every business rule is enforced here, documented in Swagger; the panel’s client is generated from it.
67 tables, 60 migrations. Seat counts and ledger entries live here.
Queues, retries and the six scheduled jobs.
One codebase, three apps
A public website anyone can visit, a panel that agents and staff log into, and a server both talk to. They live in one repository and share one database, so a change to how a booking works is made once.
Twelve outside services, one system.
Each of these was integrated, tested and documented. Every one that sends data in is verified before anything is written.
Online payments and wallet top-ups. Orders API, verified webhooks, idempotent capture.
Facebook and Instagram ad-form leads arrive in the inbox on their own, via the Graph API.
Messages become leads. Meta Cloud API directly, or DoubleTick as a provider.
Invisible spam protection on the public enquiry form, scored on the server.
Transactional mail with templates the client can edit. Credentials on the secrets page.
An aviation news feed on the public site, pulled from the GNews API.
Marketing tags added from the panel as managed site scripts, no deploy needed.
Seat inventory uploaded from spreadsheets with per-row validation; exports from the panel.
Invoices, credit notes and booking vouchers rendered in the browser from ledger data.
Images built in CI and stored in the GitHub Container Registry. The server never builds.
PostgreSQL, Redis, API, site and panel as one Compose stack on a small rented server.
TLS via Certbot and host-level routing for the three public hostnames.
What the business can do now.
How the platform behaves and how the team works today. The numbers are counts from the codebase, not projections.
- 01
Live before the deadline
Phase one, enquiry to ticket, was scoped at 60 days and went live ahead of that line. Everything since has shipped weekly, not as a second big bang.
- 02
One login for everyone
Agents, sales, operations, accounts and admins run the same panel: 33 screens, each visible only to the roles allowed to see it. No separate apps to maintain.
- 03
Leads arrive on their own
Website, Meta ads and WhatsApp feed one inbox. Duplicates are flagged, failed hand-offs retry, and sales start the day with a queue instead of a search.
- 04
Money and seats cannot disagree
Every top-up, booking and refund is a ledger entry, and the seat count is locked in the same transaction as the payment. Two agents cannot both buy the last seat; invoices come from the ledger, not a form.
Questions about this project.
A group-travel operator in India that sells group seats and chartered flights to travel agents and tour operators. They asked us not to publish their name, so this case study describes the work in full and leaves the brand out. A reference can be arranged on request.
Three connected pieces from scratch: a public website with an enquiry form, one panel used by agents, sales, operations, accounts and admins, and the API and database behind both. That covers leads from every channel, versioned quotes, payment plans and Razorpay, a prepaid wallet with a double-entry ledger, seat inventory with spreadsheet import, bookings with PNR and ticket upload, refunds, invoices, notifications, a CMS with approvals, reports, and role and permission management.
Phase one, the full path from enquiry to ticket, was scoped at 60 days and went live ahead of that deadline. Five people from Codevibe worked on it: four engineers and an engagement lead who sent the client a written report every day and ran a call every week. Work has continued since as weekly releases.
Razorpay webhooks are signature-verified and rejected outright if the secret is missing. Captures are idempotent on the gateway payment id. Wallet debits for seat bookings happen in the same database transaction that locks the seat count, so a payment and a seat can never disagree. Every movement is a double-entry ledger entry, and refunds require approval before they are paid out.
Next.js 16 and React 19 for the public site, a React single-page app for the panel, and a NestJS 11 API on PostgreSQL 16 with Prisma, Redis and BullMQ. The panel talks to the API through a typed client generated from its OpenAPI spec. Tests run on Vitest and Playwright, and it ships as Docker containers built by GitHub Actions.
The client’s own team runs it. Blog posts, pages, landing pages, email wording, marketing scripts, roles and third-party keys are all managed from the panel, so routine changes never wait on a developer. Codevibe keeps shipping improvements as weekly releases, and every architecture decision, open question and status update lives in the repository so nothing depends on one person’s memory.
Yes, and the approach would be the same: a short discovery to write the scope and the open questions down, a foundation first, then the one path your business makes money on, shipped before the rest. The timeline depends on scope; this one was 60 days to a working booking path. Start with the form below and we will come back within one business day.
Building a platform your customers transact on?
We design the system first, put the business rules where they cannot be skipped, and ship every week with the integrations your business actually runs on. Senior engineers, no shortcuts.