Building an application with PIES Studio

Sign in

Open Studio and sign in with your PIES account. Enterprise installs can also use Sign in with Microsoft when SSO is configured.

The applications list

After signing in you land on your applications. Applications are grouped into workspaces — use one per team or per client. This is where you come back to open, duplicate or delete an app.

One IDE, three things it can connect to

The local IDE is the client, not an edition of the product: it ships in every plan. What differs is what it connects to — nothing at all, a PIES-operated server, or a server your organisation runs.

• Hobby — free, no account, no telemetry. The complete editor, running entirely on your machine.
• Individual and Teams — the same editor, signed in to a PIES-operated server for hosting, storage and collaboration.
• Enterprise — the same editor, connected to a server your organisation installs and controls, including the AI engine if you run it yourself.

What works with no network at all

Everything that makes an application: creating it, designing screens, authoring events and functions, the data model, and building and previewing it locally. The IDE carries its own stack — database, back end, build toolchain and their caches — so a machine that has never been online can create an application, build it and run it.

AI works offline too, against a model on your own machine or in your own network. Nothing you type and nothing your application contains leaves the device.

What a connection adds

Features that are inherently about somewhere else are unavailable offline and shown with a lock: hosting and deployment, boards and team collaboration, mobile publishing, choosing a different language or stack, cloud storage and backup, and the full AI governance surface — policies, audit and knowledge bases. Offline, the AI settings remain so you can point the editor at your own model.

None of this changes the application you have built. Connecting later unlocks those features against work you already did offline.

Enterprise, and the air-gapped case

An Enterprise install puts the server inside your network: your database, your identity provider, your audit trail. Paired with PIES Private AI the whole system — editor, platform and model — runs with no external dependency at all, which is what an air-gapped environment requires. See the installation guide for the platform and the PIES Private AI manual for the model.

New Application

Click New Application, give it a name and pick a workspace (you can type a new workspace name to create one). Names take letters, digits and spaces — hyphens are rejected. From Template starts from a published template instead of an empty app.

The IDE

The app opens in the editor. The left rail is the explorer — every object in your application. The centre is the canvas for whatever you have open. The right is PIES AI and the properties panel, and the bottom is the build console.

Screen → widget → event → function → step

Screens hold widgets (a table, a form, a button, a chart). A widget raises an event — "this button was clicked". The event calls a function, and the function is built from steps: read a record, validate it, write it, return a result. The event then reacts to that result — show a message, navigate, refresh a table.

The division is deliberate, and the build enforces it:

• Functions do data. Record steps — insert, update, delete, retrieve — belong in functions, never in events.
• Events do interface. Show Message, Navigate and the other page steps belong in events, never in functions: a back-end function has no screen to draw on.

The rest of the explorer

Database holds tables and their relationships. Endpoints expose functions as REST APIs. Processes are long-running business workflows rather than single actions. Access Control defines groups and what each may see or do. Resources are things the app needs but does not own — email servers, secrets, environments. Components are your own custom widgets. Artefacts are documents (a BRS, a spec) that PIES AI reads before it builds.

Organising with folders

Screens, functions and events can be grouped into folders in the explorer, and a folder can hold another. The grouping is yours — by feature, by area of the business, by whatever makes the application readable a year from now. Creating a screen inside a folder puts it there directly; dragging moves it later. Folders are presentation only: nothing about the application changes when you reorganise them.

Tables and columns

Open a table under Database to edit its columns: name, type, and constraints such as primary key, auto-increment, required or unique. PIES maintains the key and audit columns it needs, so a table you create is immediately usable by screens and functions. Seed rows can be attached to a table so previews render against realistic data.

Relationships and the ER diagram

Relationships shows the entity diagram: every table and the links between them. Define a relationship here — one-to-many, many-to-many — and PIES creates the keys (and the join table where one is needed), then makes the related data available to widgets: a dropdown bound to the parent, a table showing the child rows. The diagram is the fastest way to see whether a model — yours or one the AI generated — is actually normalised.

Connecting an existing database

An application is not limited to its internal database: add a source to work against one you already run — MySQL, PostgreSQL, Snowflake and others, plus Zetaris for read-only analytics. Credentials go to the secret store, never into the application definition. Connected tables appear alongside the internal ones and can feed screens, functions and charts.

The widget palette

The palette groups widgets by kind: Input (text, number, date, dropdown, checkbox…), Data (table, form, count card), Visualization (bar, line, pie and the ECharts family), Visual (text, image, divider) and Shape. Drag one onto the canvas to place it.

Configuring a widget

Select a widget and the right panel configures it: which table or query feeds it, which columns show, validation, default values, styling, and its events. A data table takes its columns from the bound table; a chart takes a measure and a dimension. Containers group widgets and lay them out in flex or grid, so a screen keeps its shape at different widths.

Custom widgets

When nothing in the palette fits — a signature pad, a Kanban board, a third-party SDK — build a custom widget in the Widget Designer and it appears in the palette like any other. Custom widgets targeting a screen or event are React and run in the browser; those targeting a function are Go and run on the server. This is what stops a no-code application hitting a ceiling: you drop to code for one component, and everything around it stays generated.

Events — what happens when the user acts

An event is triggered by a widget: a button click, a row selection, a screen load. Its steps call a function and then branch on the result — show a success message, show the error, navigate to another screen, refresh a table. An event must not touch the database directly; it asks a function to.

Functions — the work itself

A function takes parameters, does the work, and returns data. It is drawn as a flow: one start, one end, no orphans — the build rejects anything else. Inside, steps read and write records, call other functions, transform values, branch on conditions, loop, call REST APIs, send email.

Adding and configuring a step

Add a step from the catalogue and configure it: which data source it acts on, where its input comes from (a parameter, an earlier step's output, a literal), and where its output goes. Steps are chained by linking them, and a later step reads an earlier one's result by referencing it. The groups are Record (insert, update, delete, retrieve), Control (if, loop, end), String, Numeric, Date, Communication (email) and Retrieve (queries) — plus Return Data, which hands a result back to whatever called the function.

Processes — multi-step business workflows

A process models work that spans time and people — approvals, onboarding, case handling — rather than a single action. It is a workflow of tasks and gateways, and the engine tracks each running instance. Use a function for "save this record"; use a process for "get this contract approved".

Ask for what you want

Open the PIES AI panel and describe it. Be specific about the shape of the thing — "add a screen that lists books with a search box" beats "make it better". Each request runs against the application as it stands, so you build an application up in steps.

Watch it build

The panel streams each tool call as it happens. Larger requests are planned first and show a Continue gate, so you approve the plan before it runs.

The build receipt

When it finishes you get a receipt: exactly what was created or updated, which model built it, and what it cost. Everything appears in the explorer and is yours to edit. Rewind undoes a build you did not want.

PIE Loop — build, check, fix

PIE Loop takes a larger request, decomposes it into units of work, builds them, then reads the build errors and fixes them — repeating until the application compiles. Use it for "build the whole thing"; use the chat for single changes.

What to ask for

Name the entities and how they relate, not just the theme. “A clinic booking system” leaves every decision open; “patients, doctors and appointments, where an appointment belongs to one patient and one doctor” produces the data model you meant. The same applies to screens: describe what the page is for and what it shows, and say which table it reads.

Ask for one thing at a time. A request that names a schema, four screens and a report is planned as one large job; the same work asked for in three turns is easier to steer, and each turn can be rewound on its own.

Plans, and the Continue gate

A large request is planned before it is built. The plan lists the units of work — tables, then functions, then screens — and pauses for you to approve it. Read it: correcting a plan costs a sentence, correcting a built application costs a rewind. Smaller requests skip the gate and build directly.

The build receipt is the evidence

Each turn ends with a receipt: what was created or updated, counted from the application itself rather than from the model's description of its own work. Where the two disagree, the receipt is right. A turn that reports “0 screens added” did not build a screen, whatever the surrounding text says.

The receipt also names the model that did the work, which matters when an organisation routes some requests to a model inside its own network and others to a cloud provider.

Rewind

Every turn takes a version snapshot before it changes anything, so a turn that went the wrong way costs a click rather than an afternoon. Rewind returns the application to the state before that turn — and closes anything it removed that you had open. Rewinding does not undo work you did by hand afterwards, so rewind before you continue building on a bad turn, not after.

What it will not do

The AI works through the same tools you have — it cannot reach outside the application, and it cannot write code the platform would refuse from you. Where a request needs a component the platform has no widget for, it writes one (see “Views PIES has no widget for”). Where a request is ambiguous about data — which table, which column — it will ask or choose, and choosing is where it most often chooses differently from what you meant. Naming the table removes the guess.

Policies and routing

A policy decides which provider and model serves a request, by request type, tier and data classification: cloud frontier models for the hardest work, PIES Private AI on your own GPUs for anything that must not leave the network, and an air-gapped policy that permits nothing else. Every answer in the chat carries a chip showing which policy routed it, and Why? explains the decision.

Audit, redaction and knowledge

Every governed call is recorded — provider, model, tokens, policy decision and a factuality score — in a signed, hash-chained audit log. Redaction strips sensitive data before it reaches a model. The Knowledge Base holds documents the AI may build against, and per-application Artefacts (a BRS, a specification) are fed into builds so the AI works from your requirements rather than its own assumptions.

PIES Private AI

Point Studio at a model running on your own GPUs and no prompt, application definition or data leaves your network. Installing it is covered in the PIES Private AI manual; connecting it is a URL and a key under Administration → AI Settings.

Integration Center

Connect the platform to the systems around it — source control for generated code, cloud accounts for deployment, messaging and collaboration tools. A connection is made once and reused by every application.

REST endpoints and outbound calls

Endpoints publish your functions as a REST API, so other systems can call your application. In the other direction, a REST Call step lets a function consume an external API with the response mapped into your own model. Credentials for both live in Resources → Secrets, never in the application definition.

Build

Open the build console from ▶ Run, choose the Preview environment and click Build. The PROBLEMS tab groups anything that failed by area — Database, Interfaces, Events, Functions — each with a count. An application with build errors never reaches preview, so clear these first.

Preview the running application

On a clean build, open the preview to get the real application in a new tab — logging in, saving records, navigating between screens. First start shows a short warm-up while screens compile.

What Build actually does

Build turns your definition into a real application — a front end, a Go back end and a database schema — and compiles it. It is not a preview of the canvas: it is the same generation that produces the application you deploy, run against the Preview environment. That is why a build failure is worth reading rather than retrying; it is telling you the application as defined cannot be produced.

Read PROBLEMS before the preview

An application with build errors never reaches preview, so a preview that looks stale is usually a build that failed. PROBLEMS groups every failure by area — Database, Interfaces, Events, Functions — with the object at fault named. Clear it top to bottom: a missing table breaks the screens that read it, so the first error often explains the rest.

The preview is a real deployment

Preview runs your application with its own database, its own sign-in and its own data — not a mock. You can register a user, save a record and see it persist. This is also why it takes a moment to come up, and why a preview left running holds resources until it is closed. Sample data is generated so screens have something to show before you have entered anything.

The change loop

Change the definition, build, look. Small changes rebuild quickly because only what changed is regenerated. If a change does not appear, check in this order: did the build succeed, is the preview session the current one, and is the widget actually bound to the data you changed. In that order the answer is usually the first question.

The Deploy tab

DEPLOY is a tab in the build console, next to BUILD and PROBLEMS. A new application starts with no deploy target and says so — set one under Resources → Environments: Docker and Kubernetes deploy to infrastructure you control, AWS and Azure use credentials connected in Administration. Each deployment is versioned, so you always know which build is live.

Managing what is live

A deployed application can be restarted, scaled, redeployed to a newer build, or torn down, and its logs are readable from the same place. Rolling back is redeploying an earlier version.

Mobile

Switching an application to mobile generates a Flutter application from the same definition — the same data model, functions and events, rendered natively. From there you can preview it, download the APK, or take it through to a store listing. Desktop and mobile stay in step because both are generated from one source.

Ask for the view

Describe the view rather than the widget — the time range, what each column represents, what a single entry shows. You type this into PIES AI exactly as in chapter 3; what follows is what comes back. PIES recognises that no standard widget fits, writes the component, and puts it on a new screen.

The screen it produced

A titled page with the component laid out inside it, the same as any screen you would draw by hand. The component is yours to edit: its source sits under Components in the explorer.

The query behind it

A view is only as good as the data behind it, so PIES writes the read function too — filtered on the date the view is showing, returning just those rows rather than the whole table.

How the data arrives

An event runs when the screen opens: it calls the query and passes the result into the component. This is the step that separates a view that renders from one that shows your data — and it is wired for you. Open it and you can change what it reads, or when.

Access groups

Define groups — Administrator, Manager, Read-only — and grant each one access per screen and per operation. Every application starts with a user model and an Administrator group already wired, so a generated application has working sign-in from the first build.

Authentication configuration

Choose how users of the generated application authenticate — its own user table, or your identity provider. The Login, Register and Forgot Password screens are created with the application and can be restyled like any other screen.

Environments

An environment is a named target — Preview, Test, Production — with its own database connection, variables and deploy target. The same application definition builds to each; only the environment differs, which is what makes a promotion a redeploy rather than a rewrite.

Secrets and email servers

Secrets holds API keys, database passwords and tokens. They are referenced by name from steps and connections, stored in the vault, and never written into the application definition or the generated code. Email Servers configures the SMTP account the Send Email step uses, per environment.

The menu and header

Navigation lives in one shared Menu, not on each screen — add a screen to the menu and it is reachable everywhere. The Header carries the logo, notifications and the user pill with sign-out. Both are locked to the application rather than to a screen, so they stay consistent.

Themes

A theme is a reusable palette and type scale — colours, fonts, radii, button gradients — applied to the whole application and to every screen the AI generates afterwards. Change the theme and the application follows; you are not restyling widgets one at a time.

Branches and commits

The branch selector in the toolbar works the way it looks: build on a branch, commit a set of changes, and compare or roll back to an earlier commit. Every build records which commit it came from.

Source control and generated code

Connect a GitHub or Bitbucket repository under Repositories and the generated code is pushed there — so your engineers can read it, review it, and run it in their own pipeline. Code generation is not a black box: what PIES builds is ordinary Go, React, Angular, Python or Flutter.

Rewinding an AI build

Each AI turn is a version. Rewind to here puts the application back to the state before that turn, so an experiment that went the wrong way costs a click rather than an afternoon.

The activity log

Every change to an application is recorded — what changed, who changed it and when — covering work done by hand and work done by the AI alike. It answers the question a version list cannot: not just what the application looked like at a point in time, but how it got there. An entry can be restored, returning that object to the state in the record.

The PROBLEMS tab

After a build, PROBLEMS groups every failure by area — Database, Interfaces, Events, Functions, Other — each with a count and the specific object at fault. This is the authoritative view: the AI's own summary of what it did is not evidence that the application compiles.

Analyse and fix

When a build fails, Analyse & Fix hands the failure to the AI with the context it needs — the failing object, the error, and the definition behind it — and applies the correction as an ordinary change you can inspect or rewind. It is the same loop you would run by hand, without copying error text into a prompt. Failures it cannot represent as a change to your application are reported rather than guessed at.

What a build error is telling you

Most build failures name the object at fault, and the fix is usually a missing binding rather than anything deep. The ones seen most often:

• “Table Missing Data Source” — a table or list widget was placed but never bound to a table. Open it and set the data source; a widget bound to nothing cannot be generated.
• “Event ‘0’ not found” — a button points at an event that no longer exists, usually after the event was deleted or renamed. Rebind the button, or remove the binding.
• An invalid data source on a joined table — a widget reading from several tables needs the join defined on the data source, not assembled in the widget.
• A screen with widgets but no logic still builds; a screen whose widgets reference functions or events that were removed does not. PROBLEMS names which.

When the preview will not come up

A preview is a real deployment of your application, so it fails in the ways deployments do. 502 Bad Gateway means the preview server is still starting or has stopped — rebuild rather than refreshing. A preview that has been running for a long time can be closed from the preview list, which frees the resources it holds; sessions are not meant to be permanent. If a change you made is not visible, check the build succeeded before assuming the preview is stale — an application with build errors never reaches preview.

Diagnosing a running preview

The preview carries a diagnostic overlay: it reports what actually rendered and, when something is missing, works down the layers — definition, generated code, data, render — to say which one is wrong. It can hand the finding straight to the AI as a fix request.

Templates and published assets

Publish an application as a template and new applications can start from it. Published assets are the smaller units — screens, widgets, functions — shared across a workspace so a team converges on one way of doing things.

Import and export

An application can be exported and imported whole — for moving between installs, for backup, or for handing a build to someone else. Generated code can be downloaded outright, which matters if you ever need to leave: the output is yours.

Users, roles and authentication

Invite users, assign roles, and configure authentication — local accounts or enterprise SSO. Permissions inside an application are separate, under its own Access Control.

Branding and themes

Platform name, logos, favicon and the colour palette used across Studio and the applications it generates. Themes are reusable, so every application in a workspace can share one look.

Tabs on a screen

A tab view holds several panels in one screen: put a form in one tab and a table in another rather than making the user scroll. Each tab carries its own widgets and its own bindings, and the elements list shows them nested under the tab they belong to — expand the tab view to reach a widget inside it.

Showing and hiding widgets

Any widget can be marked hidden, and a rule can reveal it when a condition holds — an approval button that appears only for a manager, a warning that shows only when a field is empty. Hidden is a property of the widget, so it applies in preview and in the deployed application, not only on the canvas.

Selecting and aligning several widgets

Drag a box across the canvas, or shift-click, to select several widgets at once. Their common properties — width, height, position — can then be set together, which is the quickest way to line up a row of cards or give a column of fields the same width. Setting the coordinates directly is exact where dragging is approximate.

Row actions on a table

A table can carry an action column — per-row buttons for View, Edit or Delete. Each action names the screen it opens or the event it raises, and the row's record is passed to it, so an Edit action lands on a form already filled in. This is how a list becomes a working screen rather than a read-only grid.

Binding a widget to data

A widget without a data source renders nothing and fails the build with “Table Missing Data Source” — binding is not optional decoration. A table or list names the table it reads and the columns it shows; a form names the table it writes and the fields it edits; a chart names a table, a column to group by and a measure. Where a widget should read from more than one table, define the join on the data source rather than assembling columns in the widget.

Layout and the drawable area

The canvas is 1920 wide, and the navigation strip occupies the left of it, so the area your widgets actually occupy is narrower than the canvas. Widths are resolved against that same area in the generated application, which is why a widget that fits here fits there. Containers are the reliable way to keep a screen's shape: group widgets in a container laid out as a row or a grid, and the group holds together at different widths rather than each widget being positioned absolutely.

Making a screen do something

A widget's events are configured beside its properties: a button raises an event on click, a screen can raise one when it opens. The event is an ordinary event you can open and edit — see the next chapter. Two patterns cover most screens: a form whose submit button calls a function that saves the record, and a screen whose on-open event loads the rows a table or view displays.