Pipeline health app
Give a sales or relationship team a focused view of stages, deal value, owner actions and risk.
JRI.AI Apps System
Start with a clear brief—“show me pipeline health”, “surface low stock”, “give our team a cleaner intake”—then build, inspect, version and publish the app inside Amplify with controlled workplace context.
Revenue workspace
The complete build loop
The builder does more than generate a page. It keeps generation conversational, shows file operations as they happen, separates preview from persistence, and keeps every accepted version recoverable.
Start with the operation that is missing—such as a pipeline-health view for deals that need attention. Add workplace house rules and choose JRI Ultra, JRI Lite, or an approved bring-your-own model connection.
The builder plans, writes complete files, makes targeted edits, and streams a live file-by-file task list so progress is visible.
Use Preview, Code, Console, and Problems. Select an element, inspect a diff, change device width, or send a runtime problem back to Fix with AI.
A build remains unsaved until it is accepted. Apply persists the version; Discard leaves the current app unchanged and does not spend another build.
Open file diffs, review build history, restore an earlier version, connect a repository, and keep a visible synchronization trail.
Publish a selected version to a JRI-hosted app URL. Domain, data, and backend settings remain explicit in the workbench.
The workbench
The app stays mounted while you move between views. Device controls, element selection, file diffs, console output, compile errors, media, history, settings, and publishing remain part of the same workbench.
Inventory command
Start well
The Apps dashboard holds app cards, templates, creation, archive controls, and a plan-aware usage meter. Each app opens into its own workbench and version history.
Give a sales or relationship team a focused view of stages, deal value, owner actions and risk.
Turn live workplace records into a focused internal command view.
Inspect products, stock, purchases, and attention states across locations.
Create a guided intake, review, or team process around a repeatable operation.
Internal apps
Internal apps can read bounded JRI data through a purpose-built interface. The runtime deliberately changes based on where the app is opened.
A dedicated token resolves the workplace server-side and exposes only supported record types. It is minted for the member open and is not the member’s JRI session.
Publishing captures a point-in-time snapshot of only the known data types referenced by the app. Public visitors do not reach the workplace’s live private records.
Sensitive fields such as bank account numbers, private document URLs, and social tokens are not part of the app data catalog.
Workbench settings
Settings govern how the app is built, what data it can use, where its source goes, and how the published version is reached.
Choose whether an app reads JRI workplace data, uses a publish-time snapshot, or connects to an external backend.
Set persistent design and product rules for the workplace, select a JRI model tier, or use an approved private key.
Manage the JRI app URL and the custom-domain verification path from the workbench settings.
Connect a repository in the owner’s GitHub account, push, pull, disconnect, and inspect synchronization history.
Publish path
JRI assembles the accepted files into a client-routed application, compiles supported JSX and TypeScript, resolves approved packages, and serves the published version through the JRI app domain.
Styles, modules, imports, and client routes become one serveable application.
The selected version and its permitted data snapshot become the live release.
The hostname resolves only to a published app, with on-demand TLS guarded against unknown slugs.
Product scope
| Capability | State | Practical meaning |
|---|---|---|
| JRI-hosted app URL | Available | Published apps use {slug}.apps.jri.ai with on-demand TLS. |
| Client-routed multi-page experience | Available | Apps are single-page builds with client routing, JSX/TSX compilation, and approved package resolution. |
| Internal workplace data | Available | Team preview uses a scoped read-only token; public publishing uses a bounded point-in-time snapshot. |
| External Supabase | Manual connection | URL and anon key only. One-click OAuth is a later product stage. |
| Custom-domain publishing | Staged rollout | Verification UI exists; production ingress is enabled only when the domain path is confirmed. |
| Serverful applications | Later | The current product is static-first with controlled APIs. Dedicated serverful runtimes are deferred. |
App, deployment, domain, GitHub, and Supabase tool groups sit behind policy states: automatic, user confirmation, owner confirmation, or blocked. Confirmed actions and tool use remain auditable.
Auto
User confirm
Owner confirm
Blocked
Apps availability, build credits, quotas, model access, data connections, and publishing options depend on the workplace plan and configuration.