TravelOS

Agencies that place students abroad or prepare visa files run on spreadsheets, WhatsApp threads and paper. A single client's file — the programme they want, the documents collected so far, what they have paid, which agent spoke to them last — ends up scattered across tools that know nothing about each other. Very little survives a handover between agents, and none of it is visible to the client, who phones the agency to ask where things stand.

Two further constraints shaped the build. The market is Algerian: the interface has to be in French, prices have to be in dinars, and the online card payment rails a Western SaaS would take for granted are not available. And one platform has to serve many agencies at once — each with its own data, branding, staff and permissions, and none of them able to see another.

TravelOS is four applications over one multi-tenant API: the agency workspace, a public portal for each agency, a client space, and an operator console for running the platform itself.

Work enters through the agency's own portal — a themeable mini-site that publishes its programmes, services and group trips straight from the catalogue, and carries a configurable quote form. A submitted request lands in a commercial inbox, gets qualified and enriched with internal notes, and converts into a case file without anyone retyping it.

The case is the spine of the product. Each type — study, visa, travel, general service — carries its own workflow, and a case advances stage by stage with tasks and checklists applied from reusable packs at creation. Documents are requested, versioned, and accepted or refused with a reason. Payments are recorded per case and per trip participant and pass through a confirmation step, because card rails are not an option in this market. Group trips track capacity, participants, itinerary and booking requests, with waitlisting once a departure fills. The client follows the same file from a private space and uploads what is asked of them.

Roles and permissions are granular — an agent sees only the sections their role allows — and each agency's data is isolated from every other. Plan limits on agents, branches, active clients and storage are enforced as resources are added, and downgrading a plan never deletes what is already there.

The front end is Next.js 16 and React 19 with Tailwind CSS and Radix primitives, using TanStack Query against the API. The backend is NestJS 11 on Fastify with Drizzle ORM over PostgreSQL, Argon2 password hashing and S3-backed document storage.

TravelOS is deployed and demonstrable end to end: a prospect can browse an agency's portal, send a quote request, and watch it become a tracked case with documents, tasks and payments behind it — while the client follows that same file from their own space and the operator console tracks the agency's plan and subscription.

The product is deliberately explicit about its edges. Transactional email, in-app messaging, an appointment calendar, advanced exports and integrated online payment are not built, and the product documentation names them as not-yet rather than letting the interface imply them. What exists is the operational core: the thread that keeps one client's context intact from first enquiry to finished file.