All posts
Product updates

Build the app, not the stack: Custom Apps in Volobox

8 min read

The Volobox Builder: the agent's summary of a change on the left, the new Send a quote form in the live preview on the right.

Every team runs something on a spreadsheet that should have been an app a long time ago. Purchase requests in a shared sheet, an approval that lives in someone's email, a vendor list nobody trusts. The app is never the hard part. The stack around it is: a database, sign-in, permissions, hosting, and a way to tell the right person that something waits for them.

Custom Apps in Volobox skip the stack. You describe the app, an agent builds it, you watch it in a live preview, and when you publish, the app is part of your workspace. Same people, same Inbox, same agents. Nothing to host and nothing to deploy.

Here is one real change, start to finish. We started an app from the Purchase Requests template with its sample data and asked for one thing it did not do yet.

Describe it

Apps are built in the Builder, a chat with a coding agent beside a live preview of the app. We wrote one message:

Suppliers should be able to send us a quote without signing in. Add a public quote form: they enter the request number, their company, a contact email, the amount and a short note. Save it on that request so buyers see the quotes on the request page.

A few minutes later the agent was done. It added a table for supplier quotes that only the app's buyers and finance can read, a rule that checks the request number and saves the quote, a public Send a quote screen, and a quotes section on the request page. Then it checked its own work and saved the result as draft version 2.

You choose the coding agent when you start: OpenCode on your organization's models, or Cursor or Codex on a person's own subscription. If the agent needs a decision in the middle of a turn, it asks and waits. Several people can build the same app; one of them holds the session and another can take it over.

Preview it, and see what changed

The preview is the app itself, running on the draft's own data, so you click through it instead of reading about it. Switch it to phone, large phone or tablet width to see how a screen holds up on the device people will use.

Every turn also says what it touched. Open its details and you see the files it added and changed, and the log of building and mounting every screen.

Review it before anyone sees it

Nothing the agent does reaches people until someone publishes. The draft is a separate version of the app, with its own data, that only the app's Builders and Admins see.

The Publish tab compares the draft with the published app and lists every change in plain words, grouped by who can do what, data, rules and screens. Some changes are marked needs attention. Ours had two: the new endpoint and the new screen both open to anyone, signed in or not. The review shows each one with the reason the app gives for it, so opening something to the public is always a decision someone read.

The review also flags a field whose type changes and a field removed and added back. Publishing never deletes data: a removed field keeps its values and gets them back if it returns.

Publish it. That's the deploy.

Choose Publish and the draft becomes the version people use. There is no restart and no separate hosting. People get the new version the next time they open a screen.

A supplier opens the form at the app's address without an account:

And the buyer sees the quote on the request it belongs to:

Built into the workspace, not bolted on

This is where an app in Volobox stops looking like a form builder. It does not sit next to your tools. It is one of them.

  • Same people. Members, Builders and Admins, plus the app's own roles, given to people and groups you already have. An app can be public to the whole workspace.
  • Same Inbox. A rule can send an Inbox card with the app's own buttons, and pressing one runs the app's action as the person who pressed it. Rules can also send bell notifications and raise alerts.
  • Your work, linked. Records can link to projects, tasks, requests, pull requests, tickets, meetings, Docs pages and more, and open them. An app reads Volobox items; it does not change them.
  • Reacts to what happens. Rules can react to Volobox events, such as a task closing, a pull request merging or a ticket arriving, and the app's own events can start Volobox workflows.
  • On a schedule, and beyond the workspace. Rules run on a timetable and call other systems over REST, with credentials an Admin binds under Secrets.
  • Agents use it too. Assistants and agents can look records up, add and change them, and run the app's actions, under approval cards like everything else.

In our workspace, Leo sent three purchase requests to Maya. The template's own rule put a card in her Inbox for each one, and the app's Approvals screen lists what waits for her:

Apps that work together

One app can build on another. The app that owns the data writes a share: which records and fields, which events, which endpoints. Its Admins decide which apps get it. A sales app can then pick a customer from your CRM app, react when a customer is added, and call the CRM's endpoint when a deal is won. A share can also go to Insights, so your dashboards chart an app's records.

Files you can read

If you write code, you can open the hood. An app is a small set of files: app.json for the data, roles and access, rules in JavaScript, and screens in React. The Structure tab draws them as tables, rules, events, schedules, access and screens, so anyone can see what an app is made of without opening a file.

You can export an app as a zip and import it, into another workspace too, and its screens follow each person's Volobox language.

Start from a template

You do not have to start blank. Every template is a complete, working app, with its data, roles, rules, screens and a dashboard, and you can add sample data to try it before your own records go in.

More templates arrive with the product. Start from one, describe your own, or import an app someone else built.

Volobox is built by the team behind the ABP Framework. More on Custom Apps is on the product page. If there is a process your team still runs on a spreadsheet, request a demo and bring it along.

See Volobox on your own work.

Request a demo and watch an agent take a task from your backlog to a pull request.