Architecture and governance
Everything created on nexxcite, whether built in the editor or implemented by the AI, sits in the same model, runs on the same runtime and passes through the same central permission check. For operations, this means you run, update and back up one platform, even when twenty business applications run on it.
Founding decisions
Every platform rests on a few founding decisions that are hard to change later. These three let you judge whether nexxcite fits your organisation.
Architecture
Whether your team builds in the editor or AI delivers a draft, everything lands in the same model, runs on the same platform and passes the same permission check. That is why the twentieth application also fits into the existing system.
| One-off solutions, coded or generated | nexxcite | |
|---|---|---|
| Result | Another codebase someone has to understand, test and run | Building blocks on the platform, readable and editable in the editor |
| Security | Each application has its own permission checks, sometimes none at all | One central permission check for everything that gets built |
| Consistency | Every solution is built a little differently | The same building blocks and patterns in every application |
| Change | Redevelop, retest, redeploy | Change in a draft, review, approve and undo if needed |
| Operations | The landscape grows with every application | One platform, updated and run as a whole |
| Knowledge | Lives in source code or in individual people's AI chat histories | Lives in the model, visible to the whole team |
The key point
Many systems that have grown over time have a user interface and, next to it, an API that was added later, with its own query logic and its own permission check. This leads to a typical security gap: a record correctly hidden in the UI can be fetched through the API because a check is missing there.
In nexxcite, that second route does not exist. The API uses the same translator and the same query layer as the UI. A record a user may not see is reported through the API as "not found". The message "forbidden" would already reveal that it exists.
The same goes for the AI. The assistant's tools have no separate, extended access to the database. They take the same route, in the security context of the person asking. That is the technical precondition for a data protection officer to approve an assistant.
Governance
Every change is traceable and can be undone
Whether your team builds in the editor or the AI implements it, only what a person has seen and approved is published.
Changes under control
A field here, an automation there, by different people and with no documented reason. With AI, this happens even faster.
Changes go into a draft, are visible individually there and are published together once someone approves them.
The layers
What happens when a user opens a form, and why no code is created along the way that someone has to maintain later.
Your application's configuration: entities and their fields, relationships, forms, lists, dashboards, flows, rules, calculations, roles and permissions. All of it is records in the same database as your business data.
At runtime, definitions are translated into executable instructions: a query definition becomes a database query, a flow definition a sequence of steps, a formula a value.
The evaluated definition becomes a view model that the interface renders. The display components contain no business logic. They show what the model hands them.
The UI, the API for connected systems, the assistant's AI tools and background processing for schedules, thresholds and mailboxes all use the same layers.
Technical foundation
A .NET application shipped as a container. The interface is rendered on the server; the browser runs no application logic, only the display.
A relational SQL database for configuration and business data. Files in the file system, Azure Blob Storage or S3-compatible storage, as you prefer.
Several instances behind a load balancer share the same database. For background processing, it is defined which instance takes it on.
Connects to your existing identity management. nexxcite manages roles and permissions; authentication itself can happen entirely outside.
Operations
Forms, lists and dashboards are built from the platform's building blocks. If you need an interface with its own interaction design or pixel-level styling, a development platform is the better choice. Embedded content and custom HTML in dashboards are possible, but they do not replace application development.
Within one environment, changes go through draft, approval and rollback. Between separate environments, definitions are exported and imported. nexxcite does not offer a continuous approval process spanning several environments of the kind development platforms provide. In heavily regulated settings, raise this point early.
The platform is not built for optimisation, heavy algorithms or large-scale data processing. It can trigger such processing and use the result, but it does not run it itself.
FAQ
No. Every change the AI makes lands in a draft and only takes effect once someone approves it. The assistant acts with its user's rights: if you may not change roles, you cannot do it through the AI either.
Definitions are data and can be exported and imported. The usual route: configure in a test environment, check there, then transfer the checked definitions. How strictly that route is followed is up to you.
In a cluster, the load balancer takes over. Sessions on the failed instance drop and are re-established; data is unaffected because it lives in the database. For schedules and mailbox polling, the designated instance applies.
A new entity or field is a configuration change; the platform maintains the underlying structure. For you, that means no migration script and no reconciling model and database.
For reading and reporting, yes; the schema is documented. For writes, we strongly recommend using the API. Otherwise you bypass the rules and checks that the shared runtime is there to enforce.
They are managed centrally and have their own permissions. Flows refer to them but do not contain them.
Technical session
Availability, data storage, sign-in, backup, updates and governance are the points where a platform decision has to prove itself technically. We go through them with you before you commit.