[data-reveal]{opacity:1!important;transform:none!important}
AntelopeJS DMS
Back to the overview

Use case You're building a new product

Write your product.The back office is already written.

A marketplace, a booking app, an internal tool, a SaaS: every product ends up needing a back office. With the DMS it lives in the same project as your business logic, on the same tables, shipped in the same deploy.

01 The back office, in action

Build it in the dashboard. It stays code.

Enter edit mode, resize a block, add a form and a chart, let the assistant rebuild the page, then publish a version. Every change is TypeScript in your repository.

02 One project

Your product and its back office, side by side.

  • Same tables, both sides. The table classes your API uses are the ones the back office shows. Add a field once; your routes and your admin pages see it.

  • The back office, done. Sign-in, members, invitations, roles down to each block, admin pages and dashboards over your own tables.

  • Building a SaaS? It's one module away. Tenants, self-service sign-up, Stripe plans and invoices, added from the CLI the day you need them.

  • AntelopeJS, or the framework you prefer. Run it as an AntelopeJS app, or embed it with createRuntime() in a framework that owns the process, like the AdonisJS template.

03 What you don't write

The half of the product nobody sees.

  • Auth and members

    Sign-in, profiles, invitations and security settings from day one.

  • Roles and permissions

    Down to each block of each page, edited from the roles screen.

  • Admin pages

    Tables, forms and drawers declared from your data controllers.

  • Dashboards

    KPIs, charts and period filters over the tables your product writes.

  • Translation

    Locales and keys for the dashboard and the apps it serves.

  • SaaS, if you need it

    Tenants, plans and invoices from the SaaS module.

    /modules#saas