Developers · AI-built apps

Your app, walkable by design.

Accessibility and tutorials want the same thing: controls with names. The app guide tells your codebase or your AI assistant what to build in. Rehearsal tells you what you missed. The rework file hands the fixes back.

Read the app guideSee pricing

What an app needs to be walked

Every control has a name a person would say. Labels are unique on a screen or carry context. Fields say what they are. Dialogs announce themselves. Loading is marked honestly. It is plain accessibility, and it is the difference between a script that lands first time and one that asks you five questions. The guide is a checklist and a paragraph you paste into your AI assistant's project instructions.

What you get as a developer

Beyond the videos.

01

The app guide

Twelve short sections: names, uniqueness, field types, dialogs, surfaces, iframes and shadow DOM, stable hooks, things that fight automation, readiness, demo state.

02

The rework file

After rehearsal, a JSON report per beat: what the sentence meant, what it hit, the script fix, the app fix. Written to be read by an AI.

03

Readiness, honoured

aria-busy, disabled, and focus are respected: Tuti Tuti waits for a control to be usable instead of guessing a timeout.

04

Stable pins

data-testid, data-test, data-cy, hand-written ids, aria-label, name, href, stable classes, then the path. Generated ids and hashed classes are ignored on purpose.

05

Local and staging

Runs on localhost and staging like anywhere else. Record the tutorial before the feature ships.

06

MCP tools

Your assistant can parse and check a script against the real parser before you paste it.

Paste this into your project

One paragraph makes every new screen walkable.

The guide's last section is a block for an AI coding assistant: label every control, keep labels unique, type every field, build dialogs with roles, hide closed overlays properly, put data-testid on tutorial controls, mark loading with aria-busy. Paste it once.

The developer loop

1

Paste the guide into your instructions

Claude, Cursor, Copilot: whichever builds your screens.

2

Rehearse the script

Where words and UI disagree, you find out in a minute, not in a support ticket.

3

Hand the rework file back

Your AI fixes the labels and the sentences. Rehearse again. Export.

For developers: the questions people ask

Does my app need special markup to work with Tuti Tuti?
No. It reads visible text, aria-labels, placeholders, titles, and input types, the things an accessible app already has. Test ids make pins sturdier across redesigns, but they are not required.
Does it work with React, Vue, Angular, Svelte?
Yes. Clicks are dispatched as real pointer, mouse, and click events in order, and typing uses real input events one character at a time, so controlled inputs update normally.
What breaks it?
Click handlers that require trusted events, native alert and confirm dialogs on the tutorial path, essential controls that only exist on hover, text baked into images, and the app's own UI inside iframes or closed shadow roots. The guide lists each with the fix.
Can I run it against localhost or a staging server?
Yes, any page Chrome can open. Many teams record the tutorial on staging before the release and ship it with the feature.
How do I find out which labels my app is missing?
Rehearse a script. Every miss is flagged with the reason and what was on screen; the rework file collects them with the suggested aria-label or id. Give it to your AI.
Is there an API?
An MCP server, at tutituti.ca/api/mcp, with tools to read the guides and parse and check scripts. A plain REST API for scripts and rework files is on the roadmap.

Make it walkable. Then let it walk.

The app guide takes ten minutes to read and one paste to apply.

Add to ChromeCreate an account

Tuti Tuti - powered by Pandacat.