Why not build Tsuno with ChatGPT, Notion and Make?

You can assemble a convincing prototype with ChatGPT, Notion and Make in a weekend. The real question comes six months later: who maintains the connections, who is allowed to see what, where does each piece of information come from, and what happens when an automation stops without warning? A stack like this is a project you have to maintain, not a finished product.

The Sunday night when everything works

The owner of three restaurants spends a Sunday evening building something. A database of pages for procedures, an automation that sends a message when a task is checked off, and an AI he can ask questions about all of it. On Monday he demos it to his sous chef. It works. The answer is clear, the message arrives.

Three weeks later, a line cook who started on Monday asks for the slicer cleaning procedure. The page exists in two versions: one copied from an old binder, the other edited by the chef. The AI answers with both, blended together. Nobody knows which one is current. The owner is traveling, and he is the only person who knows how it all holds together.

Why the stack holds up in a demo and breaks in service

The prototype has one user

In a demo, one person sees everything. In production, a dishwasher, a station lead, a site manager and an owner should not all see the same thing. Permissions by role and by location are rarely the first thing anyone builds, and they are the most painful to add afterward.

Provenance disappears

Generated text looks as certain as a measured fact. In a restaurant, the difference matters: a temperature logged by a sensor, a temperature reported by a cook and a temperature inferred from an average do not carry the same weight. Without a provenance label, everything looks equal, and the smoothest answer wins.

Nobody owns the maintenance

Each tool evolves at its own pace: data formats, limits, access conditions. The stack depends on all of them staying compatible. The day one step changes, the chain often breaks silently. And in a group of 30 to 80 employees, the owner does not have time to be the IT department.

Actions without a safeguard

Sending a message or creating a task automatically is easy. Deciding what goes out, to whom, with what summary of the effect and what record of the confirmation takes real design. Without it, a misread becomes an instruction sent to an entire team.

What the prototype shows and what it hides

Question	In the demo	After six months
Who sees what?	Everyone sees everything	You need permissions by role and by location
Where does the answer come from?	It sounds plausible	You need to know whether it is measured, reported or inferred
What if data is missing?	The AI fills the gap	The tool must say it does not know
Who fixes it?	Its author	A named person, with a backup
Who confirms an action?	Nobody	A person, with a record
What happens to the history?	Overwritten by the last edit	Dated and searchable

How to decide without ideology: a six-step test

1. Write the use case in one sentence. For example: "When a manager changes a procedure, the checklists for the affected role follow." If you cannot write it, the project is too vague.
2. List who must be able to read and who must be able to edit. Do it by role, not by first name. A spreadsheet and ten minutes will do.
3. Pick three real questions you ask every week (for example "what have my managers not dealt with?") and check that the stack answers with its sources.
4. Break a step on purpose. Switch off an automation and note how long it takes anyone to notice. If the answer is "when someone complains", that is your answer.
5. Name the maintainer and their backup. With dedicated hours. Maintenance "when we have time" does not exist.
6. Put a number on the real time, not just the subscription: building, fixing, training managers, explaining it to new hires.

Common mistakes

• Confusing a demo with a deployment. The first is judged in ten minutes, the second over time.
• Making the AI the source of truth. It rephrases. Truth has to come from a dated, attributed database where missing information is visible.
• Opening all permissions "to go faster". You will never close them again.
• Automating an action before deciding who confirms it. Nothing should go out without human approval.
• Forgetting that when a person leaves, the stack is orphaned. That is exactly the problem you were trying to solve for instructions.

What to measure

• Repair time: how many days pass between an automation failing and someone noticing?
• Share of sourced answers: out of ten questions asked, how many show where the information comes from and when it was entered?
• Weekly maintenance time, logged honestly for a month by the person who looks after it.

Where Tsuno comes in

Tsuno does not claim that building your own stack is impossible. It offers the work already done: what you keep repeating is written once, assigned to a role, and passed on through checklists, training and onboarding. Every fact carries its provenance (measured, reported, proven, observed, inferred, absent), and when data is missing, Tsuno says so. You ask questions in plain language, from Tsuno or from your own AI. Tsuno prepares the action, summarizes its effect, and a person confirms. Your data stays yours, with export available. To see how it fits together with the rest, read the solution page.

You also keep your existing tools: read does Tsuno replace your scheduling, HR or HACCP software? to see what to keep.

Where to go next

The underlying question is covered in do restaurants really need another software tool?. To evaluate any tool, including your own, see how to tell whether restaurant software will save or waste time. And if you are unsure about getting started, software delivered pre-filled shows what onboarding spares you.

Key takeaway

Building is fun; maintaining is a job. Before you decide, test permissions, provenance, failure and human confirmation. That is where the difference between a prototype and a tool you can run a service on shows up. On the interface itself, see talking to your restaurant: gimmick or new interface?.