Apps built on everything org.run already knows
Describe the tool the work needs: a portal where vendors upload RFP responses, an approvals dashboard for finance, a status page for a customer. org.run builds and deploys it, wired to your data, your people and your permissions from the first screen. Coming soon.
Describe the app, it builds it
Describe the app
DeployedA portal where vendors upload RFP responses
Northwind Logistics RFP
Responses close 14 Nov 2026
Q4 carrier tender
Upload your response
Submissions
Finance only
Already wired to
Deploy is a one-way action
Approved by Priya. Live for three vendors.
How it works
Describe your requirements and org.run builds it
- 01
You describe the app
In plain language, or org.run proposes one when a run needs a tool that does not exist. Vendors need somewhere to upload RFP responses, so it suggests a portal and asks what the form should collect.
- 02
It builds on the company model
The app is assembled on what org.run already knows: the vendors in this RFP, the fields finance needs, the people who may see each part. No schema to design and no integrations to set up.
- 03
You review it with real data
A working preview with your actual records and permissions. Change the fields, the layout or who can see what, in plain language. A deploy is a one-way action, so it waits for your yes.
- 04
It runs as part of the work
Once deployed, the app is one more surface org.run operates. A vendor uploads a response and the RFP run picks it up, scores it against the brief and moves on.
What it builds
Internal tools and outside-facing portals
Anything the work needs that your existing tools do not already provide.
Vendor and customer portals
A portal where vendors upload RFP responses. A status page where a customer sees where their order or ticket stands. Outside users sign in and see only what is theirs.
Internal dashboards
An approvals dashboard for finance, a renewals board for customer success, a hiring pipeline for the founders. Live from the company model, not a weekly export.
Forms and intake
An expense request, an access request, a change request. Each submission becomes a run, routed by your rules, with a stop for a person wherever you set one.
Off your plate
Stop running the work out of spreadsheets and email
The tool the work needs exists the moment it is needed, and it stays current because the company model is behind it.
- Collecting vendor responses by email and pasting them into a sheet
- Building another internal dashboard from the same three exports
- Writing a brief for a tool, then waiting a quarter for it
- Giving a contractor more access than the task needs so a tool works
- Answering status questions that a status page would answer
- Chasing form submissions that landed in the wrong inbox
- Re-keying data from a form into the system of record
- Retiring tools nobody remembers who built or why
Built for apps that do real work
Everything a tool needs to be trusted
Wired to the company model
Customers, vendors, people, contracts and systems are already there. The app reads and writes the same model the rest of org.run runs on.
Your permissions, inherited
Who may see and do what comes from your org chart and your rules. A vendor sees their RFP. Finance sees the approvals queue. Nobody gets a new set of credentials to manage.
Preview with real data
Before anything is deployed you see the working app with your actual records, so you review the real thing rather than a mock-up.
Deploys with your approval
Shipping an app is a one-way action, so it is set to ask by default. You approve the deploy like any other high-stakes step, and the same goes for changes after launch.
Part of the run
Submissions, approvals and status changes inside the app feed the runs org.run is already doing. The app is a surface for the work, not a separate system.
Every action logged
Who built it, who approved it, who changed what and when, and every record it read or wrote, in the same audit log as everything else org.run does.
Questions about the app builder
Not yet. It is on the roadmap, and the first early-access companies will help shape it. Today org.run does its work inside the tools you already have. The app builder is for the cases where the right tool does not exist.
A general builder starts from a blank page, and you connect it to your data, your users and your permissions yourself. org.run builds the app on a company model it already runs on, so the data, the people and the rules are there from the first screen, and the app becomes part of the work it is already doing.
Your team, and people outside it when the app calls for it: a vendor uploading a response, a customer checking status. Outside users sign in and see only what belongs to them. Access follows the same permissions as the rest of org.run.
It lands in the company model and, where you choose, in your system of record. A vendor response becomes part of the RFP run. An expense request becomes a run routed by your rules. Nothing sits in a separate database you have to reconcile.
Yes, in plain language: add a field, change who can see a section, retire it when the work is done. Changes to a live app are set to ask, so they wait for your approval before they ship.
Early access
Build the tool the work needs
Get early access and be first in line when the app builder opens.
Scoped, auditable and reversible from day one. Your data stays yours.