Enterprise platform · deployed inside your perimeter

Own the engine. Stop renting seats.

A single-core enterprise platform deployed on your own infrastructure — the modules your company runs, on one database, with the dashboards already in it. Start per application, or own it outright.

Start a 30-day evaluation See the product

On-premise or your own private cloud · inference runs locally · no record leaves your network

3,843field definitions modelledmeasured in product · Aug 2026

35modules on one corecatalogue · Appendix D

100k+records at 60 fpsproduct spec · verifiable on your data

<15 minwritten requirement to live appproduct spec · verifiable in evaluation

The product

Records, lists and reports — already built

Not a toolkit you assemble. The screens your teams work in, the filters they need, and the charts a manager asks for, over the same records.

Employee list: photo, status, code, name, contact and department columns with search, filter, export and paging — A record list — filter, search, export, and an inline chart from the same toolbar. Every module works this way, because there is only one implementation of it.

Four analytics cards: enrolment by status, progress by month, progress by context and courses by context, each linking back to its records — Reports are part of the app, not a separate BI product. Every chart says which records it drew from, and opens them.

Why this instead of more seat licences

A rising rent with no residual value

Seat-based spend recurs indefinitely, rises with headcount and at every renewal, and leaves no asset on the balance sheet when it stops. Each additional system adds an integration surface, an identity boundary and an audit gap.

No rates are published here. The comparison is run against your own invoiced subscription spend, not against a market average. What is argued against is seat-based rent that leaves no asset — a GimCore subscription is priced per application, never per seat, and the fees credit toward the licence.

Integration debt

Point-to-point APIs between CRM, HR, finance and GRC. Every schema change is a project.

Identity boundaries

Each system has its own users, its own roles, and its own idea of who may see what.

Audit gaps

The trail stops at each system edge, which is exactly where an auditor asks the question.

Architecture

A single core, not a suite of connected products

Application behaviour is defined in metadata over one database, so a record written by one module is natively readable by every other — without an integration between them. That is why the catalogue is this wide.

The module catalogue: thirty-five modules from CRM and HR to manufacturing, healthcare, legal, insurance and ESG, each with a one-line description — The catalogue, in the product. Four groups — governance & compliance, human capital & finance, operations & sales, industry & engineering. Screen counts are what each module models; depth of seeded data is agreed in scope.

Extending it

What the catalogue does not cover, you describe

The thirty-five modules are the starting point, not the ceiling. A plain-language description is analysed, modelled and deployed as screens, fields, relationships and workflows — on your server, by a model running on your hardware.

Describe

The AI acts as a business analyst and deduces the requirements you did not state.

Review

It proposes the screens it heard — and the ones you forgot — and waits for approval.

Deploy

Screens, fields, relationships and workflows are created on your server.

The conversational architect turns one sentence into four proposed screens plus two suggested add-ons, and waits — One sentence in. It proposes the screens it heard, adds two nobody asked for — Attendance and Payroll — and waits for approval before building anything.

Screen architecture for the approved app: twenty-six screens with field counts, field types and parent lookups, plus the workflow pipeline — What approval produces: 26 screens, each field with its type and its lookups, and the approval pipeline across the top. Reviewable before a single table is created.

Under 15 minutes from written requirement to live application is a product specification, verifiable in a supervised evaluation — not a measured average.

Watch it happen

One sentence, one application

A recording of the build described above — a plain-English requirement typed in, the screens, fields and relationships proposed for review, and a working application at the end of it.

The GimCore AI Architect with a business requirement typed in, ready to build

Watch on YouTube — opens in a new tab

The video is linked rather than embedded, so this page makes no request to YouTube or Google unless you choose to watch. That is the same rule the platform follows with your records.

Adoption

Your staff work the system from the chat app

The hardest part of any platform is getting people into it. Records are created, found and summarised from the messaging app they already have open.

How the agent works →

Create a record, list and search them, ask for a summary, or attach an invoice and have it become a claim — from the messaging app, without opening the platform. GimBot and the AI agent ship as part of GimCore: no separate product, no separate licence.

A chat message asking for last week's work, answered with a task summary drawn from live records — Asked in the chat app, answered from live records — with the record ids, so the answer can be checked.

The agent

An agent is assembled from steps you can read

This one reviews contracts. It reads the screen, OCRs the signed PDF, extracts the fields with an AI step, then checks three rules — the advance is 50% or less, payment is due 30 days or more after invoicing, and a confidentiality clause is present. Compliant contracts are approved; a breach escalates to Legal.

An agent flow: read screen, OCR the contract, an AI model extracts the fields, three conditional rules feed two decisions, and each decision sets a workflow status — Every rule is written in plain language, so a reviewer can audit what the agent will do before it does it — and the last step is a workflow action, not a message: the record itself moves.

The conversational agent ships today. The multi-step builder shown here is in build and is demonstrated on a development deployment. Claim register →

Data sovereignty

Where the AI actually runs

Every component sits inside a boundary you control. The model runs on your hardware, so a prompt never becomes an outbound request.

Local inference — Ollama or LM Studio, inside your perimeter
Three-tier audit trail — interface, API controller and database
ISO 27001 / SOC 2 / GDPR — architecture and control design alignment
Your database — SQL Server, primary and optimised
Source transfer — available under Tier 2

"Design alignment" is stated as design alignment, not as certification. The distinction is the deck's own, and it belongs on the page too.

Risk Overview dashboard: total risks, inherent and residual scores, distribution by level and by category, and a score trend — Governance is a module on the same core, not a bolt-on — risks, controls, findings and corrective actions against the same records the business runs on.

Evidence

Every figure, with its status

The briefing deck carries a claim register. Putting it on the website is the cheapest trust you can buy — and it is what stops a number going stale in silence.

Statement	Source	Status
3,843 distinct field definitions	GimCore metadata dictionary	Measured · Aug 2026
Under 15 minutes from requirement to live app	Product specification	Verifiable in evaluation
100,000+ records rendered at 60 fps	Product specification	Verifiable on your data
ISO 27001 / SOC 2 / GDPR	Architecture and control design	Design alignment
Migration window	Import engine, in build	No figure asserted
Record-creating conversational agent	Creates, finds and summarises records from chat; an attached invoice becomes a claim	Shipping
Multi-step agent builder	Assembles an agent from screen reads, an AI step, rules and workflow actions; audited before it runs	In build
SAML 2.0 single sign-on	OIDC today (Entra ID, Google Workspace)	Delivered on request
PostgreSQL	SQL Server today, primary and optimised	Delivered on request

Every row above carries how it is known. Anything not measured says so.

Commercial models

Three levels of ownership, and a way in

Start per application and let the fees credit toward a licence, or go straight to ownership — from a licensed deployment to a complete transfer of the source.

Start here

Annual subscription — priced per application

Pay for the applications you actually run, on your own infrastructure, with no seat metering at any headcount. Every fee paid credits toward a Tier 1 licence, so nothing is lost if you decide to own the engine outright.

Tier 1

Enterprise licence

Organisations of 100+ users needing a unified operating platform.

On-premise or your private cloud
Unlimited module access
Standard support SLA

Talk to us

Tier 2

Source code licence

Complete source transfer for internal use. Priced against what building it would cost you — not per seat and not per year.

Air-gapped deployment
Full source transfer
Internal use, no resale

Request an architecture review

Tier 3

Acquisition

For holdings and venture builders wanting the engine itself.

Full buyout
Vertical cloning rights
Unrestricted commercial IP

Discuss options

No savings percentage is presented. The cost comparison is a structure we populate jointly during the evaluation, from three inputs: your current annual licence spend, your internal delivery cost, and the systems in scope.

The next step

A 30-day technical evaluation

No commercial commitment. The purpose is to replace every claim on this page with a measurement taken on your own data and your own infrastructure.

Request a sandbox instance