PIES Studio 1.9 · Documentation
Ten minutes, one working application, no prior knowledge. The user manual is the reference; this is the shortest path through it.
You need a PIES Studio to work in, and there are two ways to get one.
Download the local IDE from pies.io/download — macOS, Windows or Linux. It runs entirely on your machine, needs no server and no account, and everything in this guide works in it. That is the fastest start.
Or sign in to a server your organisation runs. If nobody has set one up yet, see the installation guide.
The editor is the same either way; see the manual, chapter 2 for what a connection adds.
Sign in. On the workspace, choose New application and keep Blank App (start from scratch). Give it a name, and in Workspace pick one or, on a new account, type a name to create one. Leave the theme as it is and create the app. (If you open From Template to browse the templates instead, Back at the top of the template list returns you to this screen without closing the dialog.) You land in the editor with a blank application: only the built-in sign-in screens (Home Page, Login, Register, Forgot Password, Set Password) and the system user and role tables, nothing of your own yet.
Open the PIES AI panel and describe the application in plain language. Be specific about the things it manages and what you want to do with them:
Create a client tracker. Clients have a name, company, email, status and the date we last spoke. I want a list screen I can filter by status, and a form to add and edit a client.
PIES AI replies with a plan before it builds anything. Read it. If the plan is wrong, say so in the same conversation and it will revise — correcting a plan costs seconds, correcting a built application costs minutes.
When the plan is right, press Continue.
The panel shows each step as it happens: tables created, screens laid out, events and functions written. When it finishes you get a build receipt — the list of exactly what changed. That receipt is your evidence; the prose summary above it is a description, the receipt is the record. After a screen change the receipt lists the widgets Saved on screen, and if the summary names a widget that was not saved it says so (Named above but NOT in the saved screen) so you can ask again. If you asked for a change but the save stored nothing (no table added or updated, no rows added), the answer starts with ⚠️ No changes were actually made instead of a success line, so ask again or rephrase. When you ask what a button should do (when Greet is clicked show a message), PIES adds a click event to that button and leaves the rest of the screen alone; if the button does not exist yet, the receipt says the event was NOT applied, so add the button first and ask again. When you ask to add a number of records (add 5 records to the table books), PIES adds exactly that many, and the answer ends with the count the server actually stored, for example Rows stored (counted by the server): 5 new record(s) in table "books". Trust that line over any count in the summary.
While it builds, the canvas stays on the screen you had open. A new screen opens as a tab in the background, so click its tab when you want to look at it.
When you ask for a whole app (for example build me a tetris app), the starter Home Page of a new app becomes the app's real landing screen: a dashboard built from your data, or a welcome screen with a clear call to action when the app has no data yet. The screen keeps its place as the landing screen and in the menu, but takes the name the AI planned for it (such as Dashboard or Play Game), and the menu item follows the new name. The receipt says Home Page replaced with …. A Home Page you have already edited is left as it is. Every other screen the AI creates, in a whole app or when you ask for one more screen later, is added to the app's menu too; sign-in and sign-up pages are left out. A dashboard opens with a compact page header, not a tall landing-page banner, so your figures and tables start near the top of the screen.
PIES AI also gives a new app a look that suits it: it picks a design preset (such as Clinical for a clinic or Vibrant for events) and saves it as the app's theme, so every screen matches. The same happens when you ask for a single screen in a style (make it vibrant): the preset is saved as the app's theme, not painted onto that one screen, and form Save and Cancel buttons follow the theme too. Asking for a colour such as purple, soft pastels or brand green (restyle the page in purple, use our brand green and white) switches the app to the matching look (Design: Purple, Design: Pastel, Design: Green: green #2E7D32 on white). You can pick a different theme for the app afterwards; a theme you made yourself is never replaced.
Asking for icons (add icons to make the page easier to scan) adds sections that carry icons: feature cards, or count cards for your key figures when the screen shows data.
When your request names buttons or columns (a table of data sources (name, kind, status, last sync) and buttons Test Connection and Sync Source), PIES AI keeps every column you listed and adds every button you named, even if its first pass left one out.
When the app is a game or needs a coded view (the game board as a custom widget), PIES AI puts exactly one custom widget for it on the gameplay screen it planned. The board sits directly under the page header, full width and centred, sized to fit the game grid, with the rest of the screen below it.
When a list screen shows a column that points at another table (an event's venue, say), the list shows the venue's name, not its number. Such a list has a filter box on each column instead of a separate search box and Apply Filters button; View, Edit and Delete still open the right record.
Open the explorer on the left and you will see the same things: your tables under the data model, your screens under Screens.
Open a screen. The canvas shows the real layout — widgets bound to real columns, not a mockup. Click a widget and the right-hand panel shows what it is bound to.
This is the moment to change anything you do not like. You can do it by hand on the canvas, or ask PIES AI in the same conversation ("make the status a dropdown, not a text field"). Both edit the same application.
Asking for a single control on an existing screen (add a button labelled Greet to the home page) adds just that control to the screen and saves it.
When a follow-up adds a field to an existing table and also asks for a chart or screen of it (add a priority field to jobs and a chart by priority), PIES AI fills sample values into the new field on the rows you already have, so the chart has something to show. Asking for just the field leaves it empty on existing rows; fill them in yourself on the Data tab.
Press Build. PIES Studio generates a complete application — front end, back end, database schema — and compiles it.
Read the PROBLEMS panel before you look at the preview. A clean build means what you see next is real. If there are problems, the error reference says which ones you can fix and which are ours.
Then press Run to open the preview. This is not a mockup: it is your application, deployed and running, with a real database behind it. Add a client. Refresh. It is still there.
Change one thing — add a column, add a screen, reword a label — then Build and Run again. That loop is the whole product: describe, build, look, adjust.
Each preview Build resets the preview's data to the rows on your Data tab, so records you added or changed in the preview are lost. Studio asks before it does this (tick Don't show again to skip the question for that application; Profile → Show dismissed warnings again brings it back). Rows you want to keep belong on the Data tab.
| If you want to | Read |
|---|---|
| Understand the pieces you just used | User manual, chapter 4 |
| See fuller worked examples | Use cases |
| Know what a word means | Glossary |
| Work faster | Keyboard shortcuts |
| Understand what the AI is doing | How PIES AI works |
| Put this on your own infrastructure | Installation guide |