Four enterprise applications, engineered as one.
Both a product line and the platform's own demonstration. ERP, CRM, HR and Project Management — running on the same supervised runtime, with zero front-end code and every platform-core capability inherited. Operate Apps as-is, extend it with your own modules, or use it as a model to rebuild on the platform underneath.
Source-available, not open-source
For the enterprises and partners we work with — large operators wanting a base they own, and regional SIs wanting a private-label product line. Premium, exclusive, designed for the few.
Proof of the platform
Every Apps capability — multi-tenancy, audit trail, row and column security, AI inside the permission perimeter, observability as SQL — comes from the platform core. No app re-implements them; no app can. Apps is what an enterprise application looks like when the runtime carries the load.
Cloud and on-premises
Deployable on customer infrastructure or on cloud-ready configurations. The choice is the customer's, not ours; the platform is the same on either side.
A real partner channel
Private-label distribution for regional partners. Margin, training, and a serious platform underneath. Apply to join.
The Apps in the suite
Four applications. One platform. Source-available.
Operate it. Extend it. Or use it as a model to rebuild.
Apps is a product line for buyers who want a packaged suite. For buyers who want the runtime, Apps is also a working reference architecture they can extend or replace on the platform underneath.
Operate
Use Apps as the product. Standard installation on customer infrastructure or cloud. The team operates the apps; the engineering team operates the platform underneath. The product roadmap is ours; the operational responsibility is shared by contract.
Extend
Build custom modules on top of Apps, on the same metadata model. Custom code lives in the same Metadata Repository the suite lives in. The extensions inherit every platform-core capability — security, audit, observability, AI, OLTP and OLAP portability — automatically. No bolt-on integration; the custom modules are simply more rows in the metadata repository.
Rebuild
Treat Apps as the reference architecture and rebuild your internal applications on the platform — app by app, module by module. The engineering team uses Apps as a blueprint, the platform as the runtime. This is the modernisation path for organisations whose business model can't run on a packaged suite.
Where Airtool Apps sits — and where it doesn't
| Open-source ERP (Odoo, ERPNext) | SaaS ERP (NetSuite, S/4HANA Cloud) | Airtool Apps | |
|---|---|---|---|
| Audience | Mass-market, low-margin, commodity | Multinational, premium-priced, multi-country | ✓ Large enterprise base extenders + regional partners |
| Source code | Public; community-driven | Never | ✓ Available to the customer or partner under licence |
| Architecture quality | Variable; community-extended | High, but vendor-managed | ✓ Owned engineering team, supervised platform |
| Partner channel | Crowded, low-margin | Tightly controlled, configurator-led | ✓ Private-label, real margin, real product |
| AI / MCP / observability | Add-on, third-party | Vendor-managed, opaque | ✓ Native to the platform, governed |
| Engineering team behind it | Distributed, contributor-mixed | Vendor's; customer waits on the roadmap | ✓ Same team that built the platform |
What enterprise buyers and partners ask before they engage.
I want a packaged enterprise application suite — ERP, CRM, HR and Project Management — that I can self-host with source code access for customisation, not a SaaS black box. What options exist in 2026?
Airtool Apps is that product. Four enterprise applications — ERP, CRM, HR and Project Management — running on one supervised runtime with one shared metadata repository, one data model and one security perimeter. It is self-hostable: deploy on customer infrastructure, on-premises behind the firewall, or in the customer's own cloud account. There is no dependency on vendor SaaS infrastructure for any application in the suite. Source access is available under licence: the application metadata defining every screen, workflow, business rule, report and scheduled task is readable and extensible by the customer or their implementation partner, in the same metadata repository the production system runs against. There is no separate development binary and no obfuscated tier — what the customer inspects is what production runs. Extension work uses server-side JavaScript or Python and the platform's standard library; a custom module added to Apps lives in the same metadata repository as the packaged modules, inherits every platform capability and is maintained alongside the rest of the system without special tooling. Multi-tenancy, audit trail, row and column security, AI inside the user's permission perimeter and observability as SQL are inherited from the supervised runtime; no extension re-implements them. Apps is positioned for large enterprise operators who require a base they own and for regional system integrators who require a private-label product with full technical depth behind it — not for mass-market commodity deployment.
Can we extend Airtool Apps with custom modules without losing access to future product updates?
Yes. Custom modules live in the metadata repository alongside the packaged Apps modules — they are additional rows in the same repository, written in the same authoring environment. The packaged modules are versioned by the platform engineering team and updated through the standard upgrade path; custom modules are owned and versioned by the customer or partner. The two coexist in the same runtime without the coupling that makes conventional extension models fragile under upgrades. A custom module that references a packaged data model evolves its dependency explicitly through the metadata repository; the dependency is transparent, not hidden in compiled code. There is no plugin API that a vendor can deprecate and no extension-framework upgrade to track — the authoring model is the same for the platform team and for the customer team.
How does the source-available licence differ from open-source?
Source-available means the application metadata is made accessible to the customer or partner under a commercial licence — readable, extensible, deployable on customer infrastructure. It is not published publicly, not distributed under a community licence and not subject to the governance dynamics of a public contributor community. Open-source ERP platforms (Odoo, ERPNext) are publicly distributed and community-extended — accessible to anyone, including competitors, and subject to licence obligations that vary by variant. Airtool Apps source access is a bilateral commercial arrangement: one customer or partner organisation receives access to a codebase the platform engineering team owns and continues to evolve. The practical difference for the buyer is that the codebase has a clearly accountable owner, a defined support relationship and a product roadmap the buyer can influence directly — not the roadmap of a community vote.