Yozu Web: the public MVP scaffold for an AI travel decision layer

What Yozu Web is, and who the scaffold is for

Yozu Web is the public launch surface for a four-page MVP. The README describes the product as an AI Operating System for Enterprise Travel, and states plainly that this repository is the public 4-page launch MVP: a landing page, trip intake, a demoable coordination flow, and a contact path for human follow-up. The live flow is summarised as `intent -> decision-ready options -> source/disclosure -> approval -> preflight`.

The audience is narrow. The README lists the repository as suitable for landing page iteration, trip intake UX, demo flow presentation, and submission or demo-day deployment. It is not the repository for supplier integrations, real booking or payment execution, SDKs, or enterprise and hotel production systems. If you are a team looking for an open travel operating system to build on, this is the wrong artefact. If you are a product or design engineer evaluating whether the intake and approval model is worth copying, the routes and the stated boundaries are the interesting part.

The five-stage flow behind the four routes

The mechanism visible in the repository is a routing and disclosure model rather than a booking engine. Four routes carry the whole public surface: `/` for the landing page, `/intake` for trip intent and request handoff, `/demo` for the coordination flow, and `/contact` for human follow-up. The README says the demo uses mock/sandbox data, and the product boundaries repeat that: mock/sandbox demo states, approval-gated coordination only, source and disclosure shown before next-step coordination, and a preflight re-check before checkout coordination.

That ordering is the design decision worth noting. Disclosure comes before coordination, and the preflight re-check comes before checkout coordination, so the system is built to stop and ask rather than to proceed. The boundaries also state there is no automatic booking, no payment capture, no merchant-of-record claim, and no booked, paid or ticketed completion state on the public site. In other words, the repository ships the decision and approval half of the journey and deliberately omits the execution half. The `app/lib/` directory sits alongside the route folders, which is where shared logic would live, but the README does not document what is inside it.

Install and run the Yozu web app locally

The README gives prerequisites of Node.js 20+ and npm. Install dependencies from the repository root:

npm install

Then start the development server:

npm run dev

The README says to open `http://localhost:3000`, where the landing page is served from the `/` route. From there, `/intake` collects trip intent, `/demo` runs the coordination flow on mock data, and `/contact` is the human follow-up path.

For a production build, the README lists two commands in sequence:

npm run build
npm run start

A `lint` script is also declared in `package.json` as `next lint`. The dependency list includes `postgres` at `^3.4.9` alongside Next.js, React and React DOM, but the README does not document a database schema, connection string or any route that reads from Postgres. Treat that dependency as unexplained by the documentation until you inspect the code.

The intake privacy boundary and what not to submit

The intake flow collects destination and dates, budget range, travelers, trip stakes and constraints, and contact details for follow-up. The README states the current intake and privacy boundary directly: submitted details are used only to respond to that trip request, and users should not submit passport, payment, or other sensitive identity data.

That is a sensible boundary for a demo, and it is also a constraint on what you can build on top of the form without changing the stated terms. If your evaluation involves real traveller data, the README does not describe encryption, retention periods, a data processing agreement or any storage location. The contact path is a single address, `contact@yozu.me`. Nothing in the repository description indicates an account system, so a phrase like Yozu web login has no matching feature in this scaffold: there is no documented authentication route among the four pages.

Where the scaffold stops: no booking, no payment, no execution

The most important limitation is stated by the project itself. The README says the repository does not represent a full OTA, merchant-of-record product, open travel operating system, or completed booking or payment platform. The product boundaries add that there is no automatic booking, no payment capture, and no booked, paid or ticketed completion state on the public site.

For anyone searching for a Yozu web download, the answer is that no packaged binary or client application is described. This is a web application you run from source with npm. The demo is mock/sandbox data, so any coordination you see in `/demo` is a presentation of the flow, not a live supplier transaction. If your requirement is to complete a booking end to end, this repository cannot do it, and the README says those future directions should be documented separately until they become part of the shipped product.

How this differs from an open source travel platform

A project like Medusa takes the opposite approach: it is an open source commerce platform with modules for carts, orders, payments and fulfilment, and you assemble a storefront on top of it. Yozu Web is not that. It is a source-available front end with four routes, a mock coordination demo, and a documented boundary that stops before execution. The difference is not only licence but intent: Medusa gives you the execution primitives and expects you to build the decision layer, while Yozu Web ships the decision and approval layer and leaves execution out of the repository entirely.

A second contrast is the licence. Medusa is distributed under an open source licence, while Yozu Web carries a NOASSERTION licence identifier and a README notice stating the repository is not open source, is for non-commercial internal evaluation use only, and that commercial use or production deployment requires written permission from Yozu. If your selection criteria include the freedom to modify and deploy commercially, that single paragraph decides the comparison before any technical evaluation begins. Third-party dependencies remain subject to their own licences, which the README also notes.

Maintenance, licence and the cost of upgrading

The repository is not archived, and the last push was on 2026-06-09. No releases were retrieved for this repository, and `package.json` carries version `0.1.0` with `"private": true`, so there is no published package to track. Upgrading means pulling the repository and reconciling your changes with the four routes and the `app/lib/` directory yourself. The README does not document a migration path, a changelog, or a rollback procedure.

The version pins are worth reading before you plan an upgrade. Next.js is pinned at `16.2.7`, React and React DOM at `19.2.7`, and TypeScript at `6.0.3`, with `@types/node` at `22.15.29`. Those are exact pins rather than ranges, so moving any of them is a deliberate edit. On licence, the README states non-commercial internal evaluation use only, and that commercial use requires written permission from Yozu. That is a business decision to take up with the maintainers, not a technical one, and it is outside what this review can settle.

Editorial conclusion

Adopt it if you are evaluating the Yozu intake and approval flow, or need a four-route Next.js surface to iterate on landing and demo UX. Do not adopt it if you need booking, payment capture or supplier integrations: the README states none of those exist here. Before anything else, read the LICENSE file and confirm the non-commercial evaluation terms, then check whether /demo still runs on the mock/sandbox states the README describes. The last push was on 2026-06-09, so treat the repository as a launch snapshot rather than a product you can build on without a written agreement.

Frequently asked questions

Official sources

1. Issues
2. lorettawillow-lele/yozu-web on GitHub
3. Project website
4. README