Screenshot to app starts from a picture: a photo of a whiteboard sketch, a mockup exported from a design tool, a screen drawn on paper. The tool reads the image and returns an interface that looks like it, with the layout, type, colour and components it can see, and sometimes a little behaviour wired behind the buttons.
For a while it was a product category of its own. It is increasingly one more way into a site or app builder, an image instead of a sentence as the first prompt, which is why it sits on the base rung here. What comes out is usually a first draft of a page inside someone else's tool, not a component in a codebase you own.
What it is for
- Getting from a sketch to something clickable, so a conversation about a flow happens in front of a screen rather than a drawing.
- Turning your own mockup into a starting point faster than rebuilding it by hand.
- Exploring layout. A picture is a precise way to say "like this", and it beats a paragraph describing a grid.
Who it suits
Designers and founders who think in pictures and want a working draft without a front-end developer. Developers who want a starting layout to rework rather than an empty file. Anyone whose idea is clearer drawn than written.
How to tell this is your category
- Your input is an image, and you judge the output by holding it up against the picture.
- What you get back lives in the tool that made it, or arrives as markup you have not yet put into a codebase.
- If the input is a design file with named components and tokens, and the output has to land in a repository that already has a component library, you are doing design to code. It sits on a higher rung for exactly that reason.
- If the screenshot is of somebody else's product, you are doing reverse engineering and cloning, which this section covers under Cross-cutting practices and does not recommend.
What it costs you later
The layer page names the headline cost: a screenshot copies the picture, not the behaviour. This is what that means once real people use the interface.
- One state, drawn once. A screenshot is the success state, with every field filled and every list a tidy length. Empty, loading, partial, error and offline are not in the picture, so the tool invents them or leaves them out. An undesigned state is a state the tool invents, and the first person to see its invention may be a user. Designing a feature an AI coding agent cannot improvise has the list of states worth walking.
- Content the picture assumed. Mockups are drawn with short names, round numbers and the right photo. Real content is a surname of thirty letters, a product with no image, a heading that wraps onto three lines, a translation that runs longer than the original. The generated layout was fitted to the picture's content, and the real content is what breaks it.
- Structure guessed from appearance. An image has no headings, labels or reading order. The tool infers them from size and position, so large bold text may become a heading or may become styled text, and a box that looks like a button may not behave like one for a keyboard or a screen reader. Check the structure, not only the look: tab through it, and read the headings in order.
- One width. A screenshot is taken at one size. What happens on a narrow phone, or a very wide screen, was never shown, so it was never decided. If most of your visitors are on phones, a desktop picture is the wrong starting point. Start from the phone and let the layout grow from there.
- Measured values, not a system. The tool reproduces what it measures: this gap, that shade, this font size. You get values that match one picture rather than a small set of spacings and colours chosen on purpose. The next screen you add from another picture brings its own measurements, and the two will not quite agree.
- The builder's costs as well. Because the output usually lands inside a site or app builder, everything on AI website builders applies on top: the copy, search, page weight and who holds the account.
Getting more from the picture
The cheapest fixes happen before the image goes in.
- Draw, or at least list, the states that matter alongside the main screen: empty, loading, error and the narrow viewport.
- Use real content in the mockup, including the longest name and the missing image.
- Say in words what the picture cannot: which text is the page heading, what each control does, and what happens on error.
- Treat the result as a draft of the look. Decide the structure and the states yourself.