PIES Studio 1.7 · Use cases

Five things people actually do with PIES Studio

Each one is a complete journey, not a feature tour: what you set out to do, the steps, and what you should see. The screenshots and the animations are captured from a running Studio, so they show the product as it is today.

A one-minute look at the product

A real recorded session — real navigation and real render timing, not stills. The pointer is drawn in so you can follow what is being clicked.

Sign in, the explorer, a table, the relationship diagram, a screen and its palette — recorded in one pass.

1 · Build a working application from a description

Goal — go from an empty application to something that runs

The fastest route in. You describe the domain, PIES AI builds the data model, screens and logic, and you build and run it. Everything it produces is an ordinary PIES object you can open and change.

Create → describe → build → run: ten steps, 32 seconds, captured end to end. Animated GIF if you cannot play video.
  1. Create the application and open it.
  2. Describe what you want in the PIES AI panel — name the entities and how they relate, not just the theme.
  3. Watch it build. Larger requests are planned first and pause on a Continue gate so you approve the plan.
  4. Read the receipt — exactly what was created, and which model built it. Rewind undoes the turn if it went the wrong way.
  5. Check the data model. The relationship diagram is the quickest way to see whether the model is properly normalised.
  6. Build against the Preview environment and read PROBLEMS. An application with build errors never reaches preview, so clear these first.
  7. Open the preview and use the application — log in, save a record, move between screens.

Build in steps, not in one shot. Each request runs against the application as it stands, so "add a screen that lists books with a search box" lands more reliably than one paragraph describing an entire system. Ask for the data model first, then screens, then the automation.

2 · Change what the AI built

Goal — take generated output and make it yours

Generated objects are not read-only, and not a black box. Open a widget, change a property, save, rebuild.

  1. Open the screen and select the widget on the canvas.
  2. Change what you need in the Config panel — the data it binds to, its columns, its size, its styling.
  3. Save with ⌘S / Ctrl+S. There is no autosave: an edited tab shows a * until you save it.
  4. Rebuild and confirm PROBLEMS has not grown.

The most common surprise for new users is the missing autosave. If a change seems not to have taken effect after a rebuild, check the tab for a * first.

3 · Author a screen by hand

Goal — build without the AI at all

Everything the AI does is available directly, and the manual path is the one to use when you know exactly what you want.

Table → widget → configuration → event → function → step. Animated GIF if you cannot play video.
  1. Define the data first — tables, columns, relationships. Widgets bind to it, so it is easier in that order.
  2. Drag widgets from the palette onto the canvas.
  3. Configure each one in the properties panel.
  4. Wire the behaviour: the widget raises an event, the event calls a function, the function does the data work and returns a result, and the event reacts to it.
  5. Save and build.

Charts warn "Chart Not Bound" until you give them a measure and a dimension — that is the widget telling you it has no data yet, not an error.

4 · Run it and check it behaves

Goal — prove it works, not just that it compiled

  1. Run builds the application and starts a preview.
  2. The preview is the real thing: it has its own database and its own sign-in. Log in with your Studio credentials.
  3. First start shows a short "Preparing your app" warm-up while screens compile.
  4. Walk every screen you changed. A build receipt is not evidence that a screen renders.

5 · Put it in front of users

Goal — get beyond the preview sandbox

  1. Set a deploy target under Resources → Environments — Docker or Kubernetes on infrastructure you control, or AWS or Azure using credentials connected in Administration.
  2. Deploy from the DEPLOY tab of the build console.
  3. Each deployment is versioned: restart, scale, redeploy to a newer build, or roll back by redeploying an earlier one.
  4. For mobile, switch the application to mobile and the same definition generates a native app.

6 · A view PIES has no widget for

Goal — a calendar, board or timeline, with your data in it

Some views have no standard widget: a day schedule, a kanban board, a gantt. Describe the view and PIES writes the component and the data path behind it — the query that reads the rows, the event that runs when the page opens, and the delivery of those rows into the component. What you get is a working view, not a picture of one.

A day-schedule calendar on a PIES Studio screen
One request produced this screen: a titled page with the calendar laid out inside it. The component is yours to edit — its source sits under Components in the explorer.
  1. Describe the view, not the widget. Name the time range, what each column represents and what a single entry shows — for example “a calendar screen showing each doctor’s daily schedule, 07:00 to 18:00, one column per doctor, each entry showing the patient and the appointment type”.
  2. PIES recognises no standard widget fits and writes a coded component for it, placing it on a new screen.
  3. It writes the query too — filtered on the date the view is showing, returning those rows rather than the whole table.
  4. And it wires them together. An event runs when the screen opens, 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.
  5. Everything is editable. The component is a code block, the query is an ordinary function, and the event is an ordinary event — open any of them and change what it reads, or when.
The generated read function: find records filtered by date, then return them
The query behind the view — records filtered by date, returned to the screen. Generated, then yours.

Try it: “create a calendar screen showing the daily schedule of orders by date” on any application with a table that has a date column.

Starting points

These are the domains PIES is regularly built and tested against. Paste one into PIES AI as a first prompt, then refine in steps.

Sales CRM

Build a sales CRM: Account, Contact(→Account), Lead, Opportunity(→Account, →Contact, stage, amount, close_date), Activity(→Contact, →Opportunity), Product. Full CRUD screens, a dashboard with KPI cards, a bar chart of opportunities by stage and a pie of leads by source, a pipeline board, a Convert Lead function, and automation that creates a kickoff Activity when an opportunity is Closed Won.

Inventory and purchasing

Build an inventory app: Warehouse, Product(sku, unit_price, reorder_level), StockLevel(→Warehouse, →Product, qty), Supplier, PurchaseOrder(→Supplier), PurchaseOrderLine(→PurchaseOrder, →Product), StockMovement. CRUD screens, a dashboard, a Receive PO function, and low-stock automation.

Helpdesk

Build a helpdesk app: Customer, Agent, Ticket(→Customer, →Agent, priority, status), TicketComment(→Ticket), SLA, KBArticle. CRUD screens, a dashboard, a function that assigns a ticket to the least-loaded agent, and automation when a ticket is resolved.

Clinic

Build a clinic app: Patient, Doctor, Appointment(→Patient, →Doctor), Encounter(→Appointment), Medication, Prescription(→Encounter, →Medication), Invoice(→Patient). CRUD screens, a dashboard, a function that raises an invoice from an encounter, and automation when an appointment is completed.

HR

Build an HR app: Department, Employee(→Department), LeaveRequest(→Employee), Attendance(→Employee), PayrollRun, Payslip(→Employee, →PayrollRun). CRUD screens, a dashboard, payslip generation, and automation when leave is approved.

Approval workflow

Build a purchase-approval app: a Request model (amount, status, requester) and a multi-step business process with a start event, a manager-approval task, a gateway that routes amounts over 10,000 to a director, and an end event that notifies the requester.

Others that work well as starting points: project management, e-commerce back office, school administration, real estate listings, an advanced search-and-filter catalogue, a multi-step wizard form, computed and formula fields, and an application that consumes an external REST API.