An app is your data. The screen is optional.

In a few years you will tell your earbuds what is in the fridge, glance at the trip plan on your glasses, and move tomorrow's plan around from the car. Those are not three apps. They are one app, because the app is the data and the rules you set for it, and the glass, the voice and the text thread are just the ways in.

That is what we are building. The thing people do not notice is the app is the locus of control over some structured data: your own records, rules you set about who can see them and what happens to them, and any number of ways to reach them. Today the way in is mostly a screen. Soon it will be sound, glass, a car's ambient system, an assistant acting for you. What survives the move is the data and its rules. So we care a great deal about the sentence-in, records-out shape, because it is the first surface of an app that has no surface.

Say what is in your fridge out loud and get three dinners you could make tonight. That is an app. Almost nobody asks for it, because almost nobody knows they can, and most app builders would hand you a form instead: ingredient name, quantity, unit, expiry date, Save, repeat eleven times. We have been changing our builder so that the app you get takes your words, your photo, your voice note or your pasted list and does the structuring itself. The records are still there, still yours, still editable with a tap.

Why we are publishing a prompt

The honest map of where a product is going is rarely the roadmap. Roadmaps are lists of features with dates. What we found is that the clearest statement of our vision is a prompt: the one we hand a model when we ask it to imagine fifty apps built the way we think apps should be built. It asks for fifty apps, but what it is really testing is whether an app's data and rules hold up with no form in front of them at all, because that is the condition for the same app to run on a surface with no screen.

A prompt like this has to be plain. The model does nothing with hedges, so every capability has to be stated as something an app can simply do. That discipline turns out to be a better description of the platform than anything we would write for a launch page, because it is written for a reader that cannot be impressed, only instructed.

So here it is, whole, at the bottom of this post. You can paste it into any capable model and get fifty apps back. Between here and there are notes on why each part is written the way it is.

The problem it is aimed at

The prompt opens by naming the failure mode we are steering away from:

The builder currently tends to produce data-entry apps: a form with a field per column, a Save button, a list underneath.

That is true of most app builders, not only ours. A model asked for a recipe app reaches for a recipe form, because that is what recipe apps have looked like for twenty years. The prompt names the tilt we want instead: input in the easiest form the person already has, the app doing the tedious structuring, the app able to act and reach out on its own, and anything simple or critical staying a direct control.

What the app can take as input

This is the section that says the most about the platform. Read it as a list of front doors:

Text in the person's own words: a sentence, a paragraph, a pasted list, a pasted message thread, a pasted document.

Photos and screenshots: the camera or the photo library. The model reads the picture beside a question: a fridge, a receipt, a whiteboard, a business card, a menu, a schedule poster, a handwritten list, a screenshot of a text thread, a label, a page of a book.

Voice: the person talks and the app transcribes and structures it. Hands-busy and eyes-busy moments are first class: cooking, driving as a passenger, walking, holding a baby, in a workshop, at a market.

Messages sent to the app: an app has an address. A person can text it, message it, or email it, and the app treats that as input like anything typed in the page.

The person's connected accounts, linked with one click and consent per scope.

Some of these you can use in a Vibes app today. A photo beside a question, a sentence turned into records, a file dropped onto a record: those are shipped. One-click account linking, an app with an address you can text, and a voice note that structures itself are where we are headed, and the prompt deliberately does not draw the line. It says, in so many words, "design against the whole platform as it is meant to work, not against a checklist of what shipped last week." That sentence is the point of publishing it.

What the app can do on its own

The second thing the prompt insists on is that an app is not only a page:

Run on a schedule with nobody looking: every morning, every Sunday night, ten minutes after something happened.

Reach the person and the people in the app: a notification to their bell, inbox and phone; an email; a text message or a phone call through the app's own server.

Run a bounded agent loop on the server with the app's own data, its outbound fetch and its notifications as tools: triage what came in, research a link and write the summary record, watch a feed and act.

A shared to-do list that nags you on Monday morning is a small thing to ask for and a large thing to get from a form-and-list app. The prompt treats "the app did something while I was not looking" as ordinary, because on this platform it is. That is why the counts at the end ask for thirty of the fifty to keep working after intake, and twenty to be used mostly from the person's assistant or by text, with the page as the record view rather than the front door.

The line between AI and a control

This is the part we argued about most, and it is why the prompt asks for ten of the fifty apps to be ones where AI adds nothing. The principles say it directly:

Favor unstructured entry for complex records.

Favor direct entry for simple records. No AI box in front of a timer, a tip percentage, a date picker, a toggle.

Anything critical is set by a control, never inferred. A timer duration, a dose, a price, a deadline, a recipient, a payment, a post that goes out under the person's name.

An exam countdown should be a date picker. A tip calculator should be a slider. A to-do list where you paste five chores should give you five chores, not one chore with a long title. The interesting design work is knowing which is which, and a set of fifty that includes the boring cases teaches that better than fifty clever ones would.

Only ever a good surprise

One line in the principles carries most of the product philosophy:

It should only ever be a good surprise. People do not know they can ask for this, so the app has to show it. A wrong extraction that silently saves is a bad surprise; a wrong post that silently sends is a worse one.

The whole approach is a few years old. Nobody yet knows what will feel normal in a decade. What we do know is that the first time an app takes a sentence and hands you back the records you meant, you feel it, and the first time it gets one wrong and hides it, you stop trusting it. So the prompt asks every app to show what it understood, save it, and keep edit and undo one tap away.

What it asks for back

The rest of the prompt is the shape of the answer: fifty apps, each with a before (the form) and an after (the sentence, the photo, the voice note, the text message), what gets extracted, what stays a control, what the person sees in the first second, how a mistake gets fixed, what the app does later on its own, one thing you could say to it, and a tap count for both versions. Then two closing sections, a list of the recurring patterns and a short set of rules a builder could apply to an app it has never seen.

We use that output to teach our own builder. You can use it to find the app you did not know you wanted.

The whole prompt

Copy from the first line to the last. It works as written in any capable model. Change the platform section if you are designing for something else; the principles travel.

textYou are helping design the default behavior of Vibes DIY, an app builder. A person describes an app in a sentence and gets a working app they can share by link. The builder currently tends to produce data-entry apps: a form with a field per column, a Save button, a list underneath. We want its taste to move toward apps where the person supplies input in the easiest form they already have, the app does the tedious structuring, the app can act and reach out on its own, and anything simple or critical stays a direct control.

Produce 50 app ideas as before/after pairs. Each pair shows the same app built the data-entry way and then built the input-simplified way on this platform. The reader is the builder itself, so the set has to teach when to reach for AI-assisted input, when to keep a control, and what the platform lets an app do beyond its own page.

## The platform

Design against the whole platform as it is meant to work, not against a checklist of what shipped last week. Treat everything below as available.

Where an app runs: in the browser on phones and laptops, and inside the Vibes iOS app. Apps can be embedded in other sites and can be used from Claude or ChatGPT through a connector, so an app is also something an assistant can drive on the person's behalf.

What the app can take as input:
- Text in the person's own words: a sentence, a paragraph, a pasted list, a pasted message thread, a pasted document. The app calls a model with a schema and gets structured records back: one sentence can become one record or many.
- Photos and screenshots: the camera or the photo library. The model reads the picture beside a question: a fridge, a receipt, a whiteboard, a business card, a menu, a schedule poster, a handwritten list, a screenshot of a text thread, a label, a page of a book.
- Voice: the person talks and the app transcribes and structures it. Hands-busy and eyes-busy moments are first class: cooking, driving as a passenger, walking, holding a baby, in a workshop, at a market.
- Files: any file dropped or picked, stored on the record with a stable link, including images, audio, video and documents.
- Links: a URL the person pastes. The app's own server fetches it and the model reads it.
- The person's connected accounts, linked with one click and consent per scope: Instagram, Threads, TikTok, GitHub, LinkedIn, Bluesky, and more as they arrive. An app can read what the person publishes and publish on their behalf, with the person in the driver's seat by default and autopilot as a setting they choose.
- Messages sent to the app: an app has an address. A person can text it, message it, or email it, and the app treats that as input like anything typed in the page.
- Device signals: location, microphone, camera, clipboard, gamepad, and Bluetooth devices for utility apps.

What the app can do with a record:
- Keep it in a shared database that works offline and syncs. Every record is visible in the app and editable by tapping. The app's own access rules decide who can see and change each record: just me, named friends, my followers, a group, anyone.
- Generate images as content: an illustration for each record, a cover, a card, a portrait, and edit a photo the person supplied.
- Let the person correct it by direct edit or by a follow-up sentence ("the budget was 900 not 1200").

What the app can do on its own:
- Run on a schedule with nobody looking: every morning, every Sunday night, ten minutes after something happened.
- React when a record changes: derive, aggregate, moderate, fan out.
- Reach the person and the people in the app: a notification to their bell, inbox and phone; an email; a text message or a phone call through the app's own server.
- Run a bounded agent loop on the server with the app's own data, its outbound fetch and its notifications as tools: triage what came in, research a link and write the summary record, watch a feed and act.
- Publish to the person's connected social accounts, and read their inbox on those accounts so the app can surface the conversations they should join.

How people talk to the app:
- Tap it, obviously.
- Chat with it: every app can be talked to in the person's own words about the person's own view of its data, in the page, from the Vibes chat, or by text message. "What's left on my list", "move Friday's items to Monday", "add these three".
- From their assistant: Claude or ChatGPT, connected once, can read and update the person's records in any of their apps with their permissions.

What is out of scope: anything that needs a native OS integration beyond the above (phone contacts, the OS calendar, background location, other apps' data), and payments processing.

## The design principles to apply

1. Favor unstructured entry for complex records. If a record has three or more fields, or the person naturally has the information as a sentence, a list, a photo, a voice note, a message or a document, the app accepts that and extracts the fields. The person never retypes something they already have in another form.
2. Favor direct entry for simple records. If the input is one scalar the person already knows exactly (a number, a date, a choice from a short list, an on/off), a control is faster and more trustworthy than a sentence. No AI box in front of a timer, a tip percentage, a date picker, a toggle.
3. Anything critical is set by a control, never inferred. A timer duration, a dose, a price, a deadline, a recipient, a payment, a post that goes out under the person's name. AI may propose from context; the person confirms through a control, and the control is what is saved or sent.
4. Simple, fast, intuitive workflows beat looking impressive. Count the taps and the seconds from "I have the information" to "it is saved and visible". The after version must be faster for the person, not just cleverer.
5. The saved record is always visible and editable by direct manipulation. AI extraction is a front door, not a black box. Show what was understood, save it, make edit and undo one tap away, and accept a correction sentence too.
6. It should only ever be a good surprise. People do not know they can ask for this, so the app has to show it. A wrong extraction that silently saves is a bad surprise; a wrong post that silently sends is a worse one.
7. Batch is the common case. People paste five things, not one. A photo of a whiteboard becomes many records. A voice note about the week becomes several entries. A pasted thread becomes the decisions in it.
8. The app can meet the person where they are. If the natural moment is in a text thread, at the stove, in their Instagram inbox, or the morning after, the app can be there: an address to text, a voice note, a scheduled digest, a notification, a post drafted for them to approve.
9. Input can come from what the person already publishes or receives. A connected account is an input source, not only an output target.

## What to produce

Fifty apps. Cover a wide spread of everyday and small-business life: home, food, health, fitness, money, kids, school, work, small business, hobbies, travel, events, community, creative work, pets, gardening, repair and maintenance, collecting, volunteering, local groups, side businesses, creators and their audiences.

Roughly: 30 where the after version is AI-assisted input (sentence, list, photo, voice, message, link, connected account); 10 where the honest answer is that direct controls remain the best input and AI adds nothing to the entry step (say so plainly; these are calibration cases and they matter as much as the others); 10 where the input is mixed or the app acts on its own after intake (extraction plus a confirming control, or intake plus a scheduled job, a notification, a text, a call, or a post).

For each app, use exactly this shape:

**N. App name** (one line: who it is for and the moment they use it)

BEFORE: the data-entry version. List the form fields the person would fill, the taps or fields to save one record, and where people give up.

AFTER: the input-simplified version. State:
- Input: what the person actually provides and where (typed in the page, a photo, a voice note, a pasted list, a text message to the app's address, a link, a connected account). Name the real-world artifact.
- Extracted: the fields the app pulls out, and whether one input becomes one record or many.
- Stays a control: any value the person sets or confirms directly, and why.
- On screen after submit: what the person sees in the first second. The saved records as cards, what was understood, the one-tap edit.
- Correction: how a wrong field gets fixed, by direct edit and by a follow-up sentence.
- Acts on its own (if any): what the app does later without the person: a reminder, a digest, a text, a call, a post drafted for approval, a record derived from others.
- Talk to it: one example of something the person could say to the app in chat or by text that the app should handle.
- Taps and seconds: a rough before vs after count for one realistic entry.

SURPRISE: one sentence, the moment the person realizes the app did the tedious part for them. Written as something they might say out loud.

RISK: one sentence on where AI must not decide, or where a misread or a wrong send would matter, and how the after design guards it.

MODALITY TAG: one or more of: sentence, paste-list, photo, screenshot, voice, document, URL, message-in, connected-account, acts-on-its-own, control-only.

## Rules for the set

- Prefer inputs people already have. A photo they would take anyway, a message they already received, a list they already wrote, a post they already published. The best after versions add zero new work.
- Include at least eight apps where the primary input is a photo or screenshot, at least six where it is voice, at least eight where a pasted or dictated list becomes many records, at least four where the input arrives as a message to the app's address, at least four where a connected account supplies the input, at least three where a link or document does, and at least thirty where the app acts on its own afterward.
- Include at least one app where a photo of a fridge or pantry, or a spoken list of what is in it, produces recipe suggestions rather than only records, to show extraction feeding a next step.
- Include group and shared cases: a family, a team, a club, a class, a crew, a creator and their followers, where several people supply input in their own words and the app keeps one structured shared view under its own access rules.
- Include at least twenty apps that are mostly used from the person's assistant or by text, where the page is the record view and not the main door.
- For the ten control-only calibration cases, still write BEFORE and AFTER, and let the AFTER describe what a good fast control layout looks like, so the reader learns the boundary from both sides.
- Do not describe visual style, themes, animations or branding. This exercise is about input, workflow and what the app does for the person.
- Plain language throughout. Write for someone who wants to make or use the app, not for an engineer.

At the end, add a section titled "Patterns" naming the recurring input and action patterns you used across the fifty (for example: paste a list, photo of a thing, dictate while busy, text the app, read my inbox, confirm the critical scalar, act overnight, draft for approval) with a one-line definition of each and the app numbers that use it. Then a section titled "Where the line is" with six to eight sentences on how you decided between AI-assisted input, direct controls, and letting the app act on its own, stated as rules a builder could apply to a new app it has never seen.

What to do with it

Paste it, read the fifty, and find the one that describes a form you fill out every week. Then describe that app to Vibes in a sentence. If the app you get back still hands you a form, tell it "let me type it in my own words" and watch what happens. That is the tilt, and it is the reason the prompt exists.