Customers
ModuleEvery customer, deal and quote in one place, from the first call to the signed contract.
- People
- Companies
- Deals
- A sales agent
One platform made of modules: start with the ones you need, shape them to your business, and add your own.
Build with the agent
Describe your business in your own words. The agent proposes the objects, fields and views, shows each one as it goes, and changes nothing until you approve it.
Start from the modules you need, shape them, and add your own.
Read it, run it, change it. AGPL-3.0, with an MIT toolkit.
Your data stays with you, in a database you control.
Modular by design
Every business runs differently, so Devias is not one fixed app. It is a core, and a set of modules you put together. The ones that ship are where you start, not where you stop.
Records and views, workflows, tasks, documents, search, roles and the agent. Each module gets them for free, and the agent works across all of them.
Customers, invoicing, inventory: each a package of objects, fields, views and actions. Install what you need, update it, remove it, and the rest keeps working.
Add a field in the app, ask the agent for a view, or write a module in code. What you add is a first-class part of the workspace, not an add-on.
What you get
This is the core: what every module stands on, and what you build with. What is particular to a business comes from modules.
Text, numbers, dates, selects, relations, members and rich text.
The same records as a table, a kanban board or a record page.
Saved views for each object, and pages composed from blocks.
Match the columns, check the file without writing, then import.
On any record, and linkable from tasks and documents.
One search box across your records.
Link records across objects, and across modules.
A trigger, then steps that update records, run actions, notify or branch.
A record change, a button on a record, a schedule, or a module’s event.
Every run of every workflow, step by step.
For people and for agents, as a list or a board.
Rich text with comments and mentions.
From workflows, modules and agents, behind the bell.
Server functions a module ships, run from a button, a workflow or the agent.
The default one, working in the context of your own model.
Their instructions, their tools, and which tools ask first.
Anything that changes your data waits for a yes.
Hand one a task; it works it and gives it back for review.
Procedures you write once. Agents load them when a request matches.
When it is unsure, it asks you instead of guessing.
Choose which provider the agents run on with one setting.
Install, update or remove an area of the business from Settings.
Decide who can see and change what.
An API key for the workspace, or each person’s own account.
Every route described in OpenAPI.
HTTP and live events from TypeScript, with a query builder.
Plan, apply, run and uninstall modules from a terminal.
One server and one database. Postgres, or embedded to try it.
Modules
A module is one part of the business, ready to use: its records, views and routines. These ship today. They work from the same records, so nothing is typed twice, and they are examples of what a module can be.
Every customer, deal and quote in one place, from the first call to the signed contract.
Invoices with PDFs and payment tracking, and a Money in overview on Home.
A payment link on every invoice through Stripe, recorded the moment it is paid.
Stock as a ledger of moves, so you always know what is on hand, and where.
The routine on autopilot: a trigger, the steps, and every run shown step by step.
Every business
No two businesses need the same thing. Here is how a few might start: from the modules they already have, plus one they would add. Examples, not limits.
Starts from
Adds its own: Projects and timesheets
Starts from
Adds its own: Suppliers and orders
Starts from
Adds its own: Jobs and schedules
Starts from
Adds its own: Objects, fields, views
The agent
Ask for it in plain words. It works across every module you install, and it checks with you before it acts.

Create, update, search and invoice with the same actions as the app, and the same permissions as you.
Reading and searching happen right away. Anything that changes your data waits for a yes.
Hand it a task and it works it on its own, then gives it back for review.
Write down how you close out a deal once. It loads that when a request matches.
Every change shows who made it and when, on the page it touched.
Make it yours
Change how Devias fits your business by asking. The agent builds it on your data and shows you what it will change first. You can edit all of it by hand too.
For developers
A module is a few lines of code: its objects, fields, views, actions, even an agent. Describe something once and it shows up everywhere, in any workspace you install it in.
import { defineAction, defineModule } from '@devias/core';
export const manifest = defineModule({
id: 'renewals',
version: '0.1.0',
actions: [
defineAction({
id: 'renewals.schedule',
label: 'Schedule a renewal',
input: [
{
name: 'deal',
label: 'Deal',
type: 'record',
objectId: 'crm.deal',
required: true,
},
],
}),
],
});Schedule the renewal for Acme Hub rollout.
A button on the deal’s page, with a form built from the input.
A tool it can call, and it asks first when you want it to.
A step to run after a deal changes, or on a schedule.
A typed route for the action, and a call for it in the SDK.
Questions
A module is one part of the business, packaged: its objects and fields, its views and pages, its actions, and sometimes an agent and the procedures it follows. Customers, Invoicing and Inventory are modules. You install the ones you need from Settings, add your own fields and views beside them, update them, and remove them without touching the rest.
No. The modules that ship today are starting points. You can use some of them, build on any of them, or begin with none and model your own objects and fields. What you add sits beside them and uses the same records, views and actions.
Yes. A module is a few lines of code: its objects, fields, views, actions and agents. Install it in your workspace like any other. You can also add fields, views and routines in the app, or ask the agent to build them and approve the change.
Yes. The code is on GitHub and runs on your own server. It is young and still changing quickly, so if you want a guided start, get a demo and we will help you set it up.
Yes. The whole platform is on GitHub under the AGPL-3.0: the server, the web app, the agent and every module. The toolkit for building on it from outside (the SDK, the UI kit and the CLI) is MIT. A hosted cloud version is planned for those who would rather not run a server.
On your own server, in a database you control. Nothing leaves it unless you turn on something that needs to, such as sending email, taking card payments or the agent’s language model.
The software is free: you can run it on your own server, and you pay only for that server and for anything you connect, such as email or the agent’s language model. A hosted version is planned and has no price yet.
A server of your own. The web app and everything behind it ship together, and you add modules to your workspace from inside the app.
Not yet. Connecting other agents through MCP is planned. Today you work with the agent inside Devias, which uses the same actions as the app.
It uses the same actions as the app, with the permissions of the person it works for. Reading and searching happen right away; anything that changes your data waits for approval, and every change is logged on the record.