Every flexible platform has a ceiling. You model your data, design your views, build your forms and automations, and for a long way that is enough — further than most teams expect. But eventually a particular workflow, a customer-facing experience, or a genuinely bespoke interface asks for something that configuration alone cannot give. At that point the usual answer is daunting: stand up a separate application. New server, new deployment pipeline, new authentication, new hosting, new place for things to break — and a fresh seam between that app and the data it depends on.
We have removed that wall. You can now deploy fully custom applications on the platform — your own frontend, plus a backend built to serve it — without leaving the environment or assembling infrastructure of your own. This is the most significant step of the period, because it changes what the platform is: not only somewhere you configure an application, but somewhere you build and run one.
Beyond configuration
Configuration is about expressing your needs in the platform's vocabulary — types, views, rules. It is fast and it is safe, and it is the right tool most of the time. A custom app is for the moments when you need your own vocabulary: a tailored interface, an interaction the building blocks were never meant to express, an experience that is unmistakably yours. The point of custom apps is not to replace configuration but to extend past its edge, so hitting the ceiling no longer means starting over somewhere else.
Bring your own frontend
A custom app starts with a frontend you build yourself, with the freedom that implies — your own design, your own interactions, your own user experience. What you do not have to build is everything underneath it. The app lives inside the platform and inherits what already exists there: identity, authentication, and access to your data. You are building the part that is genuinely unique to you, not re-implementing the foundations for the hundredth time.
A backend that fits your frontend
A good frontend needs a backend shaped to its needs — a backend-for-frontend, or BFF. Rather than having your interface reach directly into raw data and reassemble it on every screen, the BFF gives it a clean, purpose-built layer to talk to: the right data, in the right shape, for the screens you actually built. The frontend stays simple and focused on the experience; the backend handles the work of preparing exactly what that experience needs. The two are designed to fit each other instead of being forced together.
Production builds, automatically
Shipping a real application means shipping something optimized, not a loose pile of source files. When you deploy, your app is compiled and packaged into an optimized, self-contained build ready to run. You hand over an application; the platform handles turning it into a deployable artifact. There is no separate build server to maintain and no bespoke pipeline to babysit — the path from "my code" to "running app" is part of the platform itself.
Edit where you already work
The shorter the distance between a change and seeing it live, the better software gets. A code editor built into the platform lets you work on your app and its versions in place, with navigation across files, so making a change does not mean switching to a separate toolchain just to adjust a line. The platform is both where the app runs and where you work on it.
Versioned and reversible
Anything you deploy, you need to be able to reason about and undo. Custom app versions are tracked, so you always know what is running and can move forward deliberately — or step back if a release does not behave as expected. That turns deployment from a leap of faith into a controlled, reversible action, which is exactly what you want from anything carrying real work.
Safe by design
"Custom code" should never quietly mean "unbounded access." Custom backend logic runs within a controlled boundary, so the flexibility of writing your own code does not come at the cost of the safety guarantees the platform is built on. You get room to build what you need, inside limits that keep one app from becoming everyone else's problem.
Part of the workspace
A bespoke app should not feel like a stranger bolted onto the side. Custom apps can be surfaced embedded in the workspace, so they sit alongside everything else as a natural part of the product rather than a detour to somewhere that looks and behaves differently. To the people using it, it is simply part of the platform.
A clean line to your data
The whole point of building on the platform is that your data is already here. A stable internal interface gives your app a sanctioned, reliable way to reach platform data and services — working with them, not around them. Your app is a first-class participant in the system, with proper access to the data it was built to serve.
Why it matters
This is the difference between a platform you configure and a platform you build on. The cases that used to force teams off the platform entirely — the bespoke interface, the customer-facing app, the workflow that needed its own front door — can now be built and run in the same place as everything else, sharing the same data, identity, and operational backbone.
Custom apps slot naturally into the rest of the ecosystem: they draw on your data, lean on automations, integrate through the REST API, and are deployed and versioned with the same care as the platform itself. The ceiling that used to send ambitious projects elsewhere is gone. When configuration is the right tool, you configure. When you need to build, you build — without ever leaving home.