Image to App · Your App Cloud
Build an app from your image or screenshot
Upload a screenshot, a mockup or a photo of a sketch. The image shows the layout; you describe what each button does, where the real records come from and who signs in.
From a picture of screens to screens that do something.
Show the layout, write down what the picture hides, then press every button before real records go in.
01
Attach one image per screen
Attach the screenshots or photos with the upload button above, one image for each screen. In the prompt, list them in order, such as 1 job list, 2 job detail, 3 new-job form. Say which kind each one is: a tool you use now, a mockup, a sketch or another product you like.
02
Write down what the picture can't show
For every button, say what it saves, changes or sends, and what the person sees next. Mark which values are samples. Add the states the image misses, such as an empty list, an error message or the options inside a closed dropdown.
03
Press every button, then add real records
In the preview in Studio, press each button and follow each link your images show. Then add a few real records and check the list, one detail view and one number. Describe who signs in before you publish and share the address.
What each part of the picture becomes.
Read across each row: something you can see in the image, what it can become in the app, and how to confirm it works. The rows use a made-up example: a screenshot of a job tracker at a plumbing company in San Jose.
| In the image | In your app | What to check |
|---|---|---|
| Rows on screen, such as 'Job 1042 · Emma Clarke · Leaking faucet · Scheduled' | A collection of jobs, with a list view and a detail view | Open the list after the first build. Check that Emma Clarke and the other on-screen rows weren't saved as records, unless you asked to keep them as sample data. |
| The column headings above those rows: Job, Customer, Problem, Status | Fields, each with a type such as text, date, amount or a choice | Give each field its type in the prompt. A column that only ever shows Scheduled, In progress or Done is a choice, so list every option, including any the screenshot happens not to show. |
| Buttons such as Save, Assign or Mark done | Actions you define: what each one saves or changes, and what the person sees next | Press each one in the preview and compare the result with what you wrote. A button nobody described can look finished and still be only a picture of a button. |
| Input boxes and a closed dropdown on the new-job form | Form fields with rules: required or optional, a format, a list of options | Submit the form with a required box left empty, then with a date in the wrong format. A closed dropdown hides its options, so type them into the prompt. |
| Tabs, a sidebar or a menu, with one item selected | Pages, and the navigation between them | Open every menu item in the preview. A tab that wasn't selected when you took the screenshot shows nothing of its contents, so add an image of it or describe it. |
| A number tile or a chart, such as 'Open jobs: 12' | A figure worked out from your records, with a measure you name | Say what the number counts, for example jobs whose status isn't Done. Change one job's status and watch the figure move. The 12 in the picture is a fixed number, not a count of anything. |
| A Send reminder button next to each job | An email the app sends, with a recipient, wording and timing you decide | Write who receives it and what it says. Send a test to your own address and read it on your phone before any customer gets one. |
| 'Signed in as Liam Carter' in a corner, an avatar or an Admin menu | Sign-in, with the access you describe for each collection | Sign in with a second test account that shouldn't see the Admin menu. Confirm it can see and change only what it should. |
| Arrows and numbers drawn between screens on a sketch | Links and buttons that lead from one screen to the next | Follow each arrow from the sketch in the preview, in order. Note any screen you can't reach and any link that leads somewhere the sketch didn't. |
What a picture leaves out.
An image holds the layout, the labels and whatever values happened to be on screen. It keeps no record of what the buttons did, where the rows came from or who was allowed to see them. Prepare your images with that gap in mind.
Say what kind of image it is
A screenshot of a tool you use now shows your real workflow, clutter included. A mockup shows what you intend. A whiteboard sketch shows structure and nothing about style. Label each image in the prompt and say what to take from it: the workflow, the arrangement or only the order of screens.
Crop and cover before you upload
Crop out browser tabs, bookmarks and pop-up notifications. Cover customer names, email addresses, phone numbers and account balances with a solid box, since a light blur on small text can still be readable. Work on a copy and keep the original.
Capture the states one screenshot misses
A screenshot is one moment: one tab selected, dropdowns closed, the page scrolled to the top. Take another image of each state you need, such as an open menu, the bottom of a long page or an error message, or describe it in the prompt.
Sketches on paper or a whiteboard
Photograph the sheet straight on in even light, with all of it in frame. Number the screens and draw arrows for what leads where. Type the labels that matter into the prompt too, so nothing depends on reading your handwriting.
Desktop or phone
A desktop screenshot says nothing about a narrow screen. The published app opens in a browser, including on phones, so if people will use it there, add a phone-sized screenshot or say which fields a phone should show first.
An illustrative starting point
Your screens, with behavior behind them.
Pages that follow your images, an action behind each button you describe, and records from your own data instead of the sample rows.
Screens that follow your layout
Ask for pages in the order, grouping and wording of your images, then click through them. Treat the image as a reference rather than a pixel-for-pixel specification, and check fonts, spacing and icons in a pass of their own.
An action behind every button
Describe what each button saves, changes or sends, what the person sees afterward, and what happens when it can't go through, such as a job saved without a customer name.
Your data, not the sample rows
The list in your screenshot can become a collection whose rows come from your records, or from people adding them through the app's forms. Saved records need a backend.
The sign-in a corner only hinted at
A name in the corner of a screenshot implies sign-in but says nothing about who sees what. Say who can read and change each collection, then test it with a second account.
Together in your app cloud
The pieces behind the possibility.
Choose the models and services that support the experience you want to create.
Vision models
Make sense of images and documents
Database
Keep data and context for apps and agents
Authentication
Give the right people access
A little more context
Good questions.
Can I really build an app from screenshots instead of designing from scratch?
Yes, if you treat them as the layout and wording rather than the whole specification. Screenshots show the screens you want, so you don't have to design them first. You still describe what each button does, where the records come from and who signs in, then click through the result.
Will the app look exactly like my screenshot?
Check it rather than expect it. Start with the structure: the screens, their order and the columns in each list. Then look at fonts, spacing, icons and colors, which may each need a correction. Name the few things that must match, such as the position of the main button, and ask for changes one at a time.
Can I turn a screenshot into a wireframe?
This page builds an app rather than a wireframe file. If you only need something clickable to show people, ask for the screens with sample content and nothing saved. A one-page version like that can be published on Free. Saving records, sign-in and sending email need a backend, which makes it an app with data.
Where does the app's data come from?
Not from the image. Names and numbers in a screenshot are samples, or real people's details you should cover before you upload. If your records already live in a spreadsheet, the Excel to App page covers bringing its rows in as records. Check the first few against the file. Otherwise people add records through the app's forms, which needs a backend.
Can I upload several screenshots at once?
Yes. Attach one image per screen and list them in the prompt in the order someone moves through them. Start with the screens of one task, such as a list, a detail page and a form, and add the rest once that journey works. That way you can tell which image a problem came from.
Can I use a screenshot of another company's app?
As a reference for arrangement, yes, but build your own version. Leave out their logo, product name, icons, illustrations and wording, and say in the prompt that the image is for layout only. Before you publish, search the preview for their name and look for any artwork that came along.
Can the finished app work with photos people take?
You can ask for a photo on each record, such as a technician's picture of a leaking pipe. Upload one from a phone and check it opens with its job. Vision models can describe or sort images where that helps. Check they are available for your app, try them on real photos and have a person review results that lead to a decision. Model usage is metered separately.
Explore Pricing for plans, included capabilities, and usage details.
Keep exploring.
Start from a sketch or a design ↗
See the outcome and the capabilities behind it.
A screenshot as the start of an app ↗
The blog guide to reading a screenshot for the records, actions and states it only implies.
Understand data and context ↗
Give information the right place in your app.
Prepare to publish ↗
Check the experience you will share.
Your ideas, up and running
Your next idea has a home.
Build an app. Run an agent. Make it yours.
Start building