How Yuzu plans an app before writing code

Ask Yuzu for a booking app and the first thing it produces isn’t a screen. It’s a short plan: the tables it wants, the pages it thinks you need and the services it will connect. You can read it in about a minute, and you can change any of it before a single file exists.

Schema first, because data is the hard part

Buttons are cheap to move. Data is not. If the plan has a bookings table with no link to classes, every screen after that has to work around it. So Yuzu starts with the data model, checks it against your prompt, and only then writes server code and screens.

For the pottery studio in our demo, that meant five tables: classes, seats, bookings, members and payments. The prompt never mentioned a seats table. It said “8 seats each”, which turned out to be enough.

What the plan includes

• Tables and the fields on each, in plain words.

• Pages, and who is allowed to see them.

• Integrations, with Stripe in test mode until you say otherwise.

Why you get to edit it

A plan you can’t change is just a progress bar. Most edits are small, like “members can cancel up to 24 hours before”, and making them at the plan stage costs nothing. Making them after the build costs a few credits. We’d rather you spend those on something fun.