THE PLATFORM / FEATURES & BENEFITS
More of the platform.
Less to build again.
44 capabilities and practical examples across customer management, access, module development, AI workflows, deployment, support, appearance and internationalisation. See what you can reuse—and what your team adds.
READ IT BY THE JOB YOU NEED TO DO
WHAT YOU ARE BUYING
The foundation, plus the tools to extend it.
KAXXIS supplies the platform
A licensed runtime and Module SDK, with deployment scope, support and updates agreed in your proposal. Platform capabilities may need configuration and compatible versions.
Your modules supply the business
Your screens, workflows, data model and integrations. The examples below describe realistic uses, not additional finished applications automatically included in the licence.
Services are agreed separately
AI subscriptions, external provider usage, hosting, payment integrations and bespoke development are separately configured or scoped.
01 / BUILT TO SERVE CUSTOMERS
A shared foundation for every customer you bring on board.
Your product may be unique, but organisations still need accounts, administrators, branding and access to the products they have licensed. KAXXIS puts those capabilities in one place, so your modules can concentrate on the service you sell.
Platform capability
Multi-tenant platform
Manage customer organisations within one platform.
Why it matters. Reuse one application foundation as your customer base grows.
In practice. Bring a second customer onto the same platform while keeping each module query scoped to its verified tenant.
Platform capability
Tenant and user administration
Manage organisations and their user accounts through platform screens.
Why it matters. Avoid building routine customer administration from scratch.
In practice. Onboard a customer administrator and let them manage their team without asking a developer to edit account records.
Platform capability
Tenant branding
Configure customer logos, labels and background imagery.
Why it matters. Give customer environments their own identity without maintaining a separate UI fork.
In practice. Give a customer their own logo and terminology while keeping your product on one release line.
Platform capability
Product access and licensing
Control access to enabled products through platform entitlements and licence checks.
Why it matters. Make product availability an administration decision rather than a custom code change.
In practice. Enable a licensed operations product for one customer while another uses a different set of products.
Platform capability
Plans and subscription records
Manage plan configuration and subscription state.
Why it matters. Start with the structure for commercial access; payment collection and billing integrations are separately scoped.
In practice. Record which plan a customer uses, then scope the payment-provider integration separately.
02 / ACCESS YOU CAN ADMINISTER
Put the right people in front of the right functionality.
Account security and permissions are part of operating a business application, not a finishing touch. KAXXIS brings the account controls and a common access model together so administrators can manage access and developers can connect their modules to it.
Platform capability
Sign-in and account recovery
Platform login, password changes and password-reset flows.
Why it matters. Avoid creating a new account-management experience for every module.
In practice. A new module opens inside the signed-in application instead of requiring another login system.
Platform capability
Roles and permissions
Role-based access with declared module permissions.
Why it matters. Give people access to the work they need through a shared permission model.
In practice. Let coordinators manage work while colleagues have only the permissions their jobs require.
Platform capability
Authenticator-app MFA
Account MFA setup and configurable tenant policies.
Why it matters. Add another layer of account protection without building an authenticator workflow yourself.
In practice. Apply an authenticator policy to accounts that administer the customer environment.
Platform capability
Verified tenant and user context
The SDK checks identity, tenant, product access and declared permissions.
Why it matters. Connect your endpoints to established access checks. Your module still enforces tenant filtering on its own data.
In practice. Reject a request for another customer’s record even if someone changes a record ID in the URL.
Platform capability
Platform activity logs
Review recorded actions with time, category, user and entity information.
Why it matters. Give administrators a place to investigate platform activity; custom business events need appropriate instrumentation.
In practice. Investigate an administrative change from recorded activity, and add module-specific business events where needed.
03 / YOUR PRODUCT, IN MODULES
Build the business workflow. Reuse the application around it.
A module can contain the screens, APIs, data changes and background work for a useful business feature. The SDK gives that work a defined home inside KAXXIS, rather than making your team assemble another standalone application for every idea.
SDK / developer workflow
Blazor module screens
Add business screens inside the shared application interface.
Why it matters. Keep a consistent experience across your modules instead of assembling separate apps.
In practice. Put an equipment register beside existing business modules in the same navigation.
SDK / developer workflow
Starter module generators
Generate a module folder with examples, metadata and build instructions.
Why it matters. Start from a working structure rather than an empty project.
In practice. Generate a working project before asking an agent to implement your request workflow.
SDK / developer workflow
Backend HTTP APIs
Register module-owned ASP.NET Core controllers and services.
Why it matters. Build the business endpoints your UI and integrations need.
In practice. Expose your module’s approved operations to its own screen or a separately configured integration.
SDK / developer workflow
Data persistence and migrations
Own your module data and register migration work through the SDK.
Why it matters. Evolve your product data with the module. Database design, credentials and recovery remain under your control.
In practice. Add a due-date field through a module-owned migration without changing platform tables.
SDK / developer workflow
Background workers
Use standard .NET hosted services for background processing.
Why it matters. Support jobs and recurring business work without inventing a separate module execution model.
In practice. Process a queued report or calculation while the user continues working; implement retries appropriate to its side effects.
04 / A BETTER STARTING POINT FOR AI
Give your coding assistant a smaller, clearer job.
AI-assisted development works better with a concrete project structure, examples and boundaries. KAXXIS supplies those starting materials so the brief can describe the business feature you want instead of asking an assistant to design an entire SaaS platform.
SDK / developer workflow
AI development instructions
Starter folders include agent guidance and a development prompt.
Why it matters. Give an AI assistant project context and boundaries instead of asking it to invent the whole platform.
In practice. Give Codex the generated README and AGENTS instructions before asking it to change the starter.
SDK / developer workflow
Your choice of coding assistant
The workflow uses ordinary .NET and Blazor code.
Why it matters. Keep the tools your team prefers; AI subscriptions are separate from KAXXIS.
In practice. Use an agent to implement .NET code, then inspect the diff with your normal development tools.
SDK / developer workflow
Source-free module development
Develop against the supplied SDK without platform source.
Why it matters. Bring in developers and agencies without needing to share the platform implementation.
In practice. Hand the generated module folder to a contractor without handing over the private platform repository.
SDK / developer workflow
Working backend example
The backend starter demonstrates UI, API, persistence and a background job.
Why it matters. See how a useful feature fits together before extending it.
In practice. Queue a sample job, see the result and restart the host to verify that it was persisted.
SDK / developer workflow
Build and validation commands
Starter workflows build, validate and package the module; backend examples include persistence, API and job tests.
Why it matters. Give developers a repeatable way to check their work. Review and application-specific testing are still required.
In practice. Ask the agent to run Build.ps1 and report the test result and exact package path instead of stopping after editing files.
05 / A PRACTICAL PATH TO PRODUCTION
Turn a finished feature into a release you can identify and deploy.
Building a feature is only part of the work. Versioned packages, validation and staged activation give your team a repeatable way to move a module into a compatible environment, with a record of which artifact is being installed.
Operator workflow
Versioned module ZIPs
Package a module with a manifest and declared payloads.
Why it matters. Hand over a specific release rather than a loose collection of files.
In practice. Hand an operator one named version of the module with a traceable artifact hash.
Operator workflow
Compatibility and checksum validation
Package Manager checks compatibility, contents and file hashes.
Why it matters. Catch incompatible or damaged packages before activation; validation is not a security review of the code.
In practice. Detect a package targeting an unsupported host before activating it.
Operator workflow
Staged installs and updates
Upload, validate and stage a release before a controlled restart activates it.
Why it matters. Use an explicit deployment workflow instead of replacing active files by hand.
In practice. Upload during preparation, then activate during an agreed restart window.
Operator workflow
Independent module releases
Ordinary module updates do not require rebuilding the KAXXIS host.
Why it matters. Keep routine feature releases focused on the product you changed; new platform capabilities may require a host upgrade.
In practice. Release a new module field and screen without rebuilding the KAXXIS host when its existing SDK capabilities suffice.
Operator workflow
Previous-version recovery
Retain prior module artifacts and stage a rollback when appropriate.
Why it matters. Have a defined route back to earlier code. Database migrations and data restoration need their own recovery plan.
In practice. Stage the prior code version if an update fails, checking database compatibility before recovery.
06 / TOOLS FOR THE LIFE OF YOUR APP
Keep supporting customers after the feature has shipped.
Customers need help, administrators need delivery settings, and developers need an environment in which to try their work. KAXXIS includes platform tools around those needs, alongside deployment and implementation options you can agree for your project.
Configured service / agreed offer
Shared support centre
Platform support tickets, conversations, attachments and support-desk workflows.
Why it matters. Give users a route to help and your team a shared place to handle requests.
In practice. A user raises a support request from the shared application rather than finding a separate help site.
Configured service / agreed offer
Configurable support AI
Platform support includes AI provider configuration and assistance workflows.
Why it matters. Add assistance to the support process when configured; provider usage and product-specific integration are separate.
In practice. Configure a provider to assist support workflows, with its usage costs and product integration agreed separately.
Configured service / agreed offer
Email delivery configuration
Platform email services include SMTP and Resend implementations.
Why it matters. Reuse delivery infrastructure for supported platform workflows instead of setting it up separately for each one.
In practice. Configure delivery for supported platform notifications through an existing SMTP or Resend service.
Configured service / agreed offer
Windows and Docker developer previews
Existing preview distributions pair a runtime with development resources.
Why it matters. Evaluate the platform in a development environment; the supported release and production setup are confirmed with you.
In practice. Start an evaluation host and compile a starter before deciding whether the platform fits your project.
Configured service / agreed offer
Self-hosting and implementation options
Discuss a licensed deployment in your environment, with optional custom development and implementation.
Why it matters. Choose who builds and operates your solution; hosting, support and delivery scope are agreed in the proposal.
In practice. Agree who runs backups, updates and support before putting the licensed deployment into service.
07 / THE APPLICATION EXPERIENCE
An application that feels connected.
Shared navigation and appearance make multiple business modules feel like one product. Your module still owns the usability of its screens.
Platform + module integration
Shared navigation
Declare module navigation in the package manifest.
Why it matters. Give users a consistent route into the work you add.
In practice. A Requests item opens your module inside the same header and sidebar as other products.
Platform + module integration
Permission-aware entry points
Navigation entries can declare required permissions.
Why it matters. Present relevant destinations while enforcing access again at the endpoint.
In practice. An ordinary user sees the routes their role allows; hiding a link alone is never the security check.
Platform + module styling
Light and dark appearance
The platform exposes selectable themes, including the real Material Light and Dark views shown on our homepage.
Why it matters. Start with a shared visual language across screens.
In practice. Build the new form with theme-compatible styling and review its contrast in both modes.
Module development
Custom business interfaces
Blazor modules can provide specialist screens within the host application.
Why it matters. Choose an interface that fits the work instead of limiting every workflow to a basic form.
In practice. LeatherIQ demonstrates a visual recipe builder and Hide Studio; those specific tools are separate product functionality.
08 / LANGUAGES & INTERNATIONALISATION
Build for the people using your product.
Internationalisation (i18n) prepares an application for different languages and conventions. Localisation supplies and validates the actual language content. KAXXIS provides shared capabilities; each module needs its own coverage.
Platform capability
Shared language selection
The platform has a language selector and a supported-language catalogue.
Why it matters. Avoid designing a separate language preference interface for every compatible product.
In practice. An English-speaking coordinator and an Italian-speaking colleague choose their own interface language.
Platform capability
Saved language preference
The host has a user locale service that saves the selected language.
Why it matters. Keep the experience consistent across visits.
In practice. A returning user can keep their preferred language instead of changing each screen individually.
Version-dependent client integration
Locale context for compatible product UIs
Client localisation contracts expose current culture, supported languages and a locale-change event.
Why it matters. Give a compatible module a way to react to the host’s language choice.
In practice. Refresh your module labels when the locale changes; check which client contracts your supplied kit supports.
Platform + configured terminology
Customer terminology
The terminology service resolves active tenant-aware labels with a supplied fallback.
Why it matters. Use the customer’s vocabulary without maintaining another application fork.
In practice. A workflow might call a record a Request or a Work item using agreed terminology keys and configured overrides.
Platform catalogue; module coverage varies
Seven-language catalogue
The current client contract lists English, Italian, Spanish, French, German, Portuguese and Chinese.
Why it matters. Plan a multilingual rollout against an explicit set of language codes.
In practice. Start a new module in English and Italian, then add reviewed language resources for the markets you serve. The catalogue is not a claim of complete translation in every screen.
Configured service / administrator integration
Administrative translation capability
A platform translation endpoint accepts text and target languages for authorised tenant/system administrators.
Why it matters. Support translation workflows where the service is configured and the product integrates with it.
In practice. Prepare a draft translation of product content, then have a speaker review it. It does not automatically translate arbitrary module UI or customer data.
09 / DEPLOYMENT CONTROL & OWNERSHIP
Know what is running. Know how to change it.
A release process matters after the first successful build. Keep product data, deployment history and activation checks part of your operating plan.
SDK + operator configuration
Persistent module data location
The backend context supplies a product data directory; the kit uses persistent product storage.
Why it matters. Keep business records outside replaceable version folders.
In practice. Install a new module release and verify that earlier records remain. Configure persistent volumes and permissions for the host.
Operator configuration
Explicit product approval
Hosts restrict installable product IDs; the local kit installer can approve its local module.
Why it matters. Control which business extensions a host accepts.
In practice. A production operator approves the product ID and release before staging; local developer convenience is not production approval.
Platform administration
Installed and staged version visibility
Package Manager shows active, staged and prior versions and activation failures.
Why it matters. Give the operator a concrete view of the deployment state.
In practice. Check that version 0.2.0 is active after restart instead of assuming an upload means it is running.
Platform + release verification
Readiness and product health
The host exposes readiness and product-health endpoints.
Why it matters. Include repeatable activation checks in your release process.
In practice. Check health, then sign in as an ordinary tenant user and exercise the upgraded workflow. Health alone does not prove every business rule.
A PRACTICAL FIRST STEP
Choose one workflow. Build a module.
Start with a small business problem and evaluate the platform around it. The developer walkthrough uses a service-request tracker to show environment setup, module design, translations, testing and the next release.