Build from a screenshot or a spreadsheet

Some apps are easy to describe in words. Plenty aren't. You know exactly what you want because you're looking at it — a mockup from your designer, a screenshot of a tool you wish you could afford, the spreadsheet your whole business secretly runs on. Explaining a layout in prose is slow and lossy, and describing a data model column by column is nobody's idea of a good afternoon.

So show Vorx instead. Attach images and files to a build prompt and they become part of the build.

Start from a screenshot

Drop in a mockup, a screenshot of an app whose layout you admire, or a photo of the whiteboard where you sketched the thing.

Vorx doesn't paste the image into a page and call it done. The image feeds the design stage of the pipeline — the part that decides screens, structure and visual direction before any code is written. The layout you showed it shapes the spec, and the spec shapes the build, so what comes out is a working app that matches what you were looking at, with real navigation, real state and a real backend behind it.

Build around your data

Attach a spreadsheet or a CSV and Vorx reads it the way you'd want a careful developer to: it works out the entities, the column types and the relationships between them, and builds the data model around your actual data rather than a guess at it.

It also seeds the app with realistic content drawn from what you gave it — so the first build looks like your business, not like lorem ipsum with your logo on top. There is no faster way to find out whether an app is right than seeing your own data inside it.

Mix words and attachments

The combination is where this gets good. Words are best at intent; attachments are best at detail.

• "Build this, but for gym class bookings" plus a screenshot says more than three paragraphs of layout description.
• "Track these, and flag anything overdue" plus your spreadsheet gets you a working tracker with your real columns and your real rows.

Reference or asset — say which

Not every image means the same thing. A screenshot can be a reference — build something like this — or an asset — put this actual photo on the About page.

Vorx works out which role each attachment plays from the context of your prompt, the same way it reads everything else you ask for: from meaning, not from filenames. You can make it explicit when it matters — "use this as the hero image" versus "match this layout" — and remove the guesswork entirely.

Attachments stay with the project

Files you attach are kept with the project, not thrown away after one build. Later edits can lean on them: "match the header spacing from the mockup" works next week, not just in the message where you uploaded it. The things you showed Vorx become part of what it knows about your app.

What you can attach

Any file type — Vorx reads images, documents and data directly, and keeps everything else available for your app to use or link to.

• Up to 10 files per message
• 20 MB per file on the Free plan, 256 MB per file on paid plans

This is for showing Vorx what you mean, not for bulk-importing a hard drive. Files your app's users upload are a separate thing — see Files and storage.

It still gets verified

Everything attached goes through the same pipeline as everything else: the build that comes back has been rendered in a headless browser and clicked through before you see it, screenshot or no screenshot.

Bring a screenshot. Bring the spreadsheet. Show it the thing.

For more on what to put in the words around your attachments, see Prompting basics; for modelling data you've imported, see Connect a database.

In the docs: Writing good prompts and Usage and limits.