Other cookies are configurable.
Incoplax platform
Builder: low-code and vibe-code development of business applications
Describe what your business works with: customers, tickets, campaigns, visits. Builder turns that description into a working application with database tables, a REST and WebSocket API, web screens, access rights and background services.
You can click it together, write it in TypeScript, or have an AI coding assistant generate it.
What Builder is
Builder is the development environment of the Incoplax product layer, the part that turns the communications platform into an information system (how it fits into the architecture).
The contact center, Meet and other Incoplax products are themselves product-layer packages built on the same model, so you get the same tools our own teams use.
Applications see calls, chats and agents. IVR scenarios can read, create, change and delete any object of your application while a call is in progress.
Typical applications
- Call cards and customer directories
- Ticketing and helpdesk
- CRM, ERP and project management
- Industry solutions
- Analytics and dashboards on contact-center data
- New communication channels for agents
Start from a data model, get a working system
The core idea is simple: an information system is built on a data model. Describe four classes for a veterinary clinic, activate the package, and Builder checks it for errors such as broken references, then generates everything else.
- First name
- Last name
- Phone number
- Type
- Name
- Owner → Client
- Last name
- Specialty
- Time
- Status
- Animal → Animal
- Doctor → Doctor
- Storage
- A table for every class and the data-processing services that serve it.
- API
- REST endpoints for every class (/rest/v1/model/
<package>/ ) and real-time WebSocket subscriptions to changes.<Classes> - Screens
- A table and a card for every class, a drop-down list for every enumeration and a lookup list for every class.
- Code
- TypeScript classes and interfaces for applications and server services, compiled and bundled automatically.
- Applications
- Web applications assembled from these screens and published to the users whose roles allow it.
A “Clinic administrator” application with Clients, Animals, Doctors and Visits is now one menu definition away.
The low-code toolkit
Everything in Builder is a typed entity that you edit in a table and a card. Builder is itself built with Builder.
Data model
- Packages
- Group everything for one business area, declare dependencies, then activate, deactivate, export and import.
- Enumerations
- Fixed option lists with a caption and colour for each value, shown in tables and charts.
- Classes
- Properties, inheritance, calculated and joined fields, actions, validation, access rules.
- Fixtures
- Reference data installed and removed together with the package.
- Constants
- Translations of every caption, so one package serves users in any language.
Interface
- Editors
- How a value is entered: text, number, date, duration, drop-down, lookup, file, HTML, colour and more.
- Controls
- Tables, trees, cards, pivot tables, charts, funnels, gauges, dashboards, calendars, chat, layouts and filters.
- Applications
- A menu of controls published to selected roles.
- Public links
- Open an application for external users without a separate sign-in.
Logic
- Services
- Background logic on the server or in the browser, triggered by data changes, timers or API invocations.
- Handlers
- Logic that runs on insert, modify or delete in any class, including classes from other packages.
- Shifts
- Replace a class, control, editor or application of another package with your own.
Access and operations
- Roles
- Who can see which applications, classes, rows and fields.
- REST sandbox
- Build and run HTTP and WebSocket queries for any class: filters, grouping, aggregation, sorting.
- Backups
- A copy of the package is saved on every activation, so any change can be rolled back.
A separate application documents every class and enumeration of the active packages. It is the reference for developers and for AI assistants alike.
Low code where it is enough, code where it matters
Most applications need little or no code. When they do need it, the code lives in the same package as the model.
- Expressions. Default values, links, visibility and filters are set with constants, field references, system and user settings, or relative dates such as “today” and “start of month”.
- TypeScript hooks. Code that runs before insert, modify or delete can validate data or cancel the operation with a message for the user.
- Server services. Services are written in TypeScript and run as Node.js microservices under platform supervision. Builder can download a service as a ready project: run it on your own computer against a live domain, with code completion for the whole data model, then put the code back into the package.
- SQL data sources. A report can be built on any SQL query against PostgreSQL, not only on a single class.
Storage that fits the data
For each class you choose where it lives:
| Memory only | live state |
|---|---|
| Memory with a copy on disk | fast data that must survive a restart |
| PostgreSQL | reference data |
| PostgreSQL history tables, partitioned by date | logs and archives |
Per class you can also turn on caching, change history, real-time updates and automatic deletion after a set lifetime.
Extend the platform without forking it
Your packages do not change the standard ones; they sit on top of them.
- Dependencies. A package can build on the contact-center package and add its own classes, reports and screens.
- Handlers. Add your own logic to operations on standard classes. Handlers run in priority order after the class's own logic.
- Shifts. Replace a standard class, screen, editor or application with your own version. Standard applications and services then use your version.
When the product layer is updated, your project packages are backed up and kept, so upgrades do not overwrite customisations.
Security is part of the model
Access rules are set on the classes themselves, not in each screen.
- Roles decide which applications a user sees and which classes they can read or write.
- Row filters limit which records a role can read or change: an agent sees only their own customers, a supervisor sees their team's.
- Bulk operations run with the rights of the user who started them.
- A security log records who listened to or downloaded a recording and who exported a table. Your packages can add their own events.
The same rules apply to everyone who uses the API: users, integrations and AI agents.
Vibe coding: describe it, let AI build it
Builder was not designed for AI coding assistants, but its design suits them well. An assistant works with Builder the way an engineer does: it reads the model, changes it through the API and checks the result.
- Everything is data
- A package, with its model, screens, roles, services and reference data, exports to a single JSON file. An assistant can read it, write it and compare versions.
- Everything goes through the API
- Import, activation, data queries and checks use the same REST API as Builder's own interface. Nothing is available only behind a button.
- Readable names, stable IDs
- Entities refer to each other by full names such as callcenter/
connections/ , not random IDs. An ID is computed from the full name, so the same package gets the same IDs on every installation.ArchiveConnection - A safety net
- Activation validates the package and reports broken references. A backup is saved on every activation, and the assistant works with only the rights its token grants.
A typical session
- 1You describe the task“A ticket system for B2B customers: tickets linked to customers and calls, SLA timers, a second-line escalation queue and a dashboard for the support manager.”
- 2The assistant studiesIt reads the documentation and the object model of the active packages.
- 3The assistant writes the packageA small script generates enumerations, classes, screens, reports, the application, roles and reference data.
- 6You reviewIn the browser, and ask for changes. Every step is versioned in Git and backed up on the platform.
- 5The assistant checksIt runs the report queries against the live domain and reads the service state.
- 4Import and activateThrough the REST API. The platform validates the package and generates storage, API, screens and services.
The package lifecycle
A package is the unit you build, ship and roll back.
- 01CreateBuild the package in Builder, in TypeScript or through the API.
- 02ActivateValidate, generate code, publish classes, applications and services.
- 03ApplyApply small changes quickly, without rebuilding applications and services.
- 04Export / importMove the package between domains and installations as one JSON file.
- 05Back upAutomatic copies on every activation and every product-layer update.
- 06ScaleRun many small tenants economically: system services can share one microservice instead of running per domain.
Build your first application
Bring a process your team runs in spreadsheets or a legacy system. We will model it with you and show it running on Incoplax, built in Builder or by an AI assistant.