Priority Console · App Generator

Describe the app.
Get it working — against your live Priority.

One sentence in, a real app out. Every screen is discovered from your own Priority forms, tested against your server before you ever see it, and delivered where you want it: in the browser chat, on your own machine, or in claude.ai.

It stops if your Priority is unreachable — it never invents field names Smoke-tested against your server before handoff Contacts and warehouse staff sign in with their own identity

App Generator plugin v0.54.0 · also a route in Priority Console

stock-count — Priority Console
▸ You  Build a mobile stock-count app for the warehouse.

 Checking your Priority connection    reachable
 Planning the app                     phone · count · submit
 Discovering your Priority forms      parts, warehouses, count doc
 Designing the look                   your brand colours
 Writing the app                      single file, no build step
 Testing the app                      count landed in Priority
 Launching the app                    preview is live

# Ready. Publish it, or download the folder.

The build panel: the app, its files, and its logs — while it is being built.

Why the app you need never gets built

Not because nobody wants it. Because every version of it starts as an integration project.

The people who need it are not at a desk

Warehouse staff, field technicians, and your customers' own buyers all need a phone-shaped screen. The Priority client is a desktop application, built for the people who work inside it all day.

Every app idea dies on the integration

A three-screen tool turns into a project: reach Priority, learn the right forms, handle the sub-tables, keep credentials safe, deploy it somewhere. The idea is small. The plumbing is not.

Generic AI builders guess at your data

A tool that has never opened your Priority will invent field names that look right and fail on your server. What comes back demos beautifully and cannot be shipped.

The App Generator starts by reading your Priority — and refuses to continue if it cannot.

From one sentence to a working app

Every stage announces itself in plain language while it runs. You watch the app get built, not a spinner.

Build a mobile stock-count app for the warehouse
  • Checking your Priority connection No connection, no app. It stops here rather than guess.
  • Planning the app Screens, flow, and what the app is allowed to write.
  • Discovering your Priority forms Live fields, dropdown values, sub-tables, and who may see what.
  • Designing the look Your brand, or colours read from your website.
  • Writing the app A real multi-file project, not a snippet.
  • Testing the app Run against your server. Apps that write get tested on writing.
  • Launching the app Handoff names which part of Priority feeds each feature.

The app that sentence produces. Runs on a phone browser, writes straight into Priority.

What you can ask for

Six named starters are built into the chat, and each one is a starting point rather than a fixed form. Ask for something that is not on the list and it is planned from scratch the same way.

Phone Works offline
Mobile stock count

One file, no install. Scan or search a part, enter the count, submit the sheet.

Counts done on the floor, straight into Priority.
Dashboard Read-only
Orders dashboard

A live order list with type-ahead search and a row of headline numbers across the top.

The order book on a screen, without a report request.
Web app Sign-in
Employee order entry

Staff sign in, add parts to an order, submit it, and print the confirmation as a PDF.

Order taking outside the Priority client.
Web app Contact login
Service-calls portal

Your customer's contact signs in and sees only their own calls, with attachments and a comment box.

Customers stop phoning to ask for status.
Web app Full editing
Records screen for any form

Browse, filter, create, edit and delete — including on forms that Priority's own REST interface does not expose.

A working screen for the form you were told was off-limits.
Scheduled job No screen
Invoice export

A command-line job that exports invoices for a date range to CSV, built to run on a schedule and report failure properly.

Nightly exports that the scheduler can actually monitor.
config.json

Finished apps are packaged as a plain folder: the app, its files, and one settings file read at run time. Drop it on your own IIS server, or run it with the small server that ships alongside. Point that settings file at a different Priority server and the same folder works there — no rebuild, no developer.

Who is allowed to log in

Every build asks this before a screen is drawn, because the answer changes the whole app. There are four answers.

Who signs in Checked against What they get
A Priority user Their real Priority username and password A genuine Priority session, with their own permissions
A customer or supplier contact The contact records on the customer or supplier card PHONEBOOK PHONEBOOKA A portal scoped to that account — their orders, their calls, their documents
An employee The employee records in Priority USERSB Warehouse and field screens for staff who never open the Priority client
Nobody No sign-in screen at all A wall-board, a kiosk, or a scheduled job with nobody in front of it
scoped access

Each person signs in as themselves and sees only what belongs to them. A customer contact gets their own account's orders and documents, an employee gets the warehouse screen. That scoping is decided by one question at the start of the build, not bolted on by a later migration.

It refuses to fake it

A demo that impresses and then fails on your server is worse than no demo. Four rules keep that from happening.

No connection, no app

Before anything is planned, it opens your Priority. If the server is unreachable it stops and tells you, rather than continuing on invented field names that would fail the first time someone pressed a button.

It builds what you asked for

Ask for a search-and-view screen and you get a search-and-view screen. It will not pad the app with create and edit forms nobody requested, and it will not run write tests against your data for an app that only reads.

Tested before it reaches you

Every build ends with a run against your own server, and the depth of that test matches what the app does: an app that writes is tested on writing, all the way to the record landing in Priority.

Checked by machine, not by mood

Eleven automated gates check the finished app against its own specification, a second check makes sure no error is being quietly swallowed, and a scan confirms no secret ever made it into the package.

Built in a conversation, in your browser

The App Generator is a route inside Priority Console. You sign in, connect your Priority once, and describe the app. Nothing to install.

A short wizard, then it goes

Start from a template or from nothing. Say whether the app should use your brand or take its colours from your website. Say what kind of app it is, who logs in, and whether it must keep working when the connection drops. Confirm the Priority it will talk to, and the build begins.

Watch it, open it, download it

Three tabs sit next to the conversation: the running app with start, stop and download; the file tree, updating as files are written; and the logs, streaming the build, the preview server, and any error the app hits while you click through it.

Publish where your users are

Publish to a Windows share that your own IIS server picks up, or to Vercel for a public address. Targets are saved and re-used, each one can be tested before you publish to it, and the result is verified after the upload rather than assumed.

Hand the whole project over

Export a project as one file that carries the source, the briefing the AI worked from, and the conversation that produced it. Share it with a colleague on your team, or hand ownership over entirely. Passwords, settings files and build output are left out, and the transcript is cleaned before it ships.

Your machine does the building; the browser just drives it. A one-line install starts a small local helper, pinned to the exact version the site expects.

Three ways to run it

Same discipline, same phases, same tests. Pick the one that matches how your team already works.

No install

Priority Console

The browser chat at chat.flow-chain-ai.com. Sign in with your company account, connect Priority through a popup, and build.

  • Intake wizard and live preview
  • Publish to your IIS server or Vercel
  • Export, share and hand over projects
  • Fully bilingual, English and Hebrew
On your machine

Claude Code plugin v0.54.0

For teams that live in a terminal and want the projects on their own disk, in their own repository.

  • Seven build stages, each its own specialist
  • Four more that improve the generator itself
  • Real multi-file projects and real test runs
  • A fast path that skips rediscovery on a repeat build, saving around ten minutes
Inside claude.ai

claude.ai skill

A single installable skill for people who already work in claude.ai and want the result as an artifact they can open immediately.

  • Four phases, run inline in the conversation
  • Web apps come back as one self-contained file
  • Needs your gateway connected to claude.ai first

Your Priority password is never in the app

This is the part your IT reviewer will ask about first, so it was designed first.

A token, not a password

A generated app never talks to Priority directly and never carries Priority credentials. It holds a connector token that can be revoked in seconds, and the Priority Gateway decides on its own side who that token is.

Connecting is a popup

You connect your Priority through a popup window, and the credentials are exchanged between the two servers. There is no password box inside the chat, and nothing sensitive is typed into the page you are looking at.

Exports carry no secrets

When you export or share a project, settings files, downloaded libraries, build output and repository history are all excluded, and the conversation is cleaned first. What arrives is the app, not a copy of your keys.

The console you build in runs on Amazon Web Services, in Amazon's Tel Aviv region, with Cloudflare in front of every request: TLS, DDoS protection, a web application firewall, rate limiting and bot filtering. The servers accept no inbound connections — they dial out to Cloudflare and traffic comes back down that tunnel, so there is no public port to scan, and admin surfaces sit behind a second gate. Secrets are held encrypted in AWS Parameter Store, never in a database or a config file, and deploys run from a versioned pipeline.

What sits behind the sentence

The generator does not improvise from a blank page. It works from a written body of Priority app-building knowledge.

6
named starters in the wizard
9
complete example apps that actually run
53
recipes for specific jobs
168k
words of reference material

Including four sign-in recipes, eight documented app patterns, and five guides for the kinds of app it can produce. Quality is measured the same way: a scoring harness grades both how the app was built and what came out, against a published rubric — offline behaviour, queued writes, an explicit commit step, and the write landing in Priority.

Part of the Priority AI-Tools suite

One registration connects your team to Priority through AI. The App Generator shares its console, its connection and its licence with the rest of the family.