Give AI a business problem.
Give it a working foundation.

THE EXAMPLE

A service-request tracker for a small team.

A facilities team currently loses requests in email. They want a shared list of requests, a priority, a due date and an Open / In progress / Done status. English-speaking and Italian-speaking staff need the same workflow in their own language. Each customer must see only their own records.

Keep the first version focused. Add attachments, outbound notifications or external integrations only when their storage, delivery and permissions have been designed.

01 / PREPARE THE ENVIRONMENT

Ask the agent to set up the workbench.

Obtain an agreed KAXXIS developer preview kit. Open its extracted folder in your desktop coding agent and give it the kit README, kit-info.json and the module instructions. For Codex, open the local project/folder and start a coding task. See the official OpenAI quickstart for current sign-in and project setup. Your coding-tool account and usage are separate from KAXXIS.

For the Docker route you need Docker with Compose, PowerShell 7 and a .NET 8 SDK to compile modules. The runtime uses compiled KAXXIS: module development does not require platform source. Check that kit-info.json declares ModuleSdk API 1; an older runtime cannot gain that capability just by receiving a newer starter script.

Read the supplied kit README and kit-info.json first. Check Docker/Compose, PowerShell 7 and the .NET 8 SDK. Tell me which prerequisites are missing and guide their installation using the current vendor instructions. Confirm this runtime supports moduleSdkApiVersion 1.

Start the kit with its documented Start.ps1 command. Keep it local. Help me complete the administrator setup myself and verify login and host readiness. Do not copy production data or put credentials in source control. Report the working URL and the checks you actually ran.

dotnet --list-sdks
pwsh --version
docker compose version
pwsh ./Start.ps1

Run these from the extracted Docker kit folder. Start.ps1 prepares local configuration, starts PostgreSQL and KAXXIS and waits for initial migrations. Complete the first administrator setup at http://localhost:7080/setup with the generated setup key. If the default port is occupied, use the port instructions in the kit README.

Success looks like: a local host you can sign into, a compatible kit version and a compiler that can build the starter. A blank Core installation is expected; LeatherIQ is a separate product.

A Windows preview installer also exists. Its runtime and a development SDK are different things: you still need the SDK to compile modules. The documented unsigned Windows preview has fresh-install/repair limitations and does not provide a supported different-version in-place upgrade. Use the instructions shipped with your exact kit.

02 / GENERATE, THEN BUILD

Start with a module that already has structure.

Generate a full-stack starter called ServiceDesk with the stable product ID service-desk. It contains Client, Server and Shared code, a manifest, SDK metadata, tests, a README and AGENTS instructions. The starter demonstrates a persisted background job; your agent adapts it into the request workflow.

pwsh ./scripts/sdk/New-KaxxisServerModule.ps1 -Name ServiceDesk -ProductId service-desk
pwsh ./modules/ServiceDesk/Build.ps1

The build compiles the client and server, runs the supplied tests and writes the installable ZIP to modules/ServiceDesk/packages/. Build the unmodified starter first so you can distinguish an environment problem from your later changes.

Read modules/ServiceDesk/README.md and AGENTS.md. Build the unmodified starter and report its result before changing it. Then implement a service-request tracker with title, description, priority, due date and status. Add list/filter, create and edit screens inside the KAXXIS module route and retain its manifest navigation.

Use product-owned storage and migrations. Authorize every endpoint with IModuleAccess and filter every record query by the verified actor's tenant. Define view/manage permissions in the manifest and apply them consistently. Never trust a tenant ID supplied by the browser. Keep platform implementation assemblies and platform database tables out of the module.

Use translatable strings from the start. Add tests for validation, persistence, permissions and tenant isolation. Run Build.ps1, fix failures, and report changed files, test results and the exact package path. Do not deploy to production.

Give the agent acceptance criteria, not only a visual request. A request title should be required, status changes should be validated, and attempts to read or edit another tenant’s record must fail. Keep the screen usable with a keyboard and at narrow widths.

The saving: the task is a bounded business module. The agent can work against a supplied project, access contract and build command instead of creating a new SaaS host, account system and deployment format.

03 / INTERNATIONALISATION

Make language part of the first release.

KAXXIS has a shared language selector and saved preferences. Its current localisation client contract lists English, Italian, Spanish, French, German, Portuguese and Chinese. That gives compatible modules a common language context; it does not mean arbitrary new text is translated automatically.

Make the ServiceDesk interface work in English and Italian, including headings, navigation labels where supported, form labels, buttons, statuses, empty states and validation messages. Keep an English fallback and test missing translations.

Inspect the exact client localisation capabilities supplied by this kit. Where supported, use the host locale context and terminology integration and refresh labels when the user switches language. Do not add a private platform reference or assume the public backend SDK exports client localisation contracts. If a compatible client integration is missing, report it and propose a supported approach before changing dependencies.

Keep entered request text unchanged. Test accented characters, long Italian labels, date display/input, keyboard access and both light/dark themes. Provide a short list of strings for a native speaker to review.

For compatible product UIs, IKaxxisLocaleContext exposes the current culture, supported languages and change notifications; IKaxxisTerminology resolves terminology with a fallback. These are client contracts: the backend API 1 starter does not automatically wire up every localisation capability. Confirm the supplied client integration before using them.

The platform also has an administrative translation endpoint for configured translation workflows. Provider configuration, authorisation, product integration and language review remain necessary. Translation coverage and right-to-left layouts must be verified for the actual module and release.

04 / CHECK THE RESULT

A package that builds is the start of verification.

Review the agent’s changes and run the module tests. Then exercise the installed result with real development accounts. Test the workflow users will run—not only the happy path as a SystemAdmin.

The starter’s tests cover its example behaviour. They are not proof that your new request rules, translation coverage or deployment are correct. Ask the agent to report failed and unrun checks alongside passing ones.

05 / INSTALL THE MODULE

One package. A defined activation path.

For the supplied local Docker kit, install the ZIP produced by the build. The initial generated version is 0.1.0; use the exact filename for the version you actually built.

pwsh ./Install-Module.ps1 -ArtifactPath ./modules/ServiceDesk/packages/ServiceDesk.Product.0.1.0.public-server.kaxxis-product.zip

This kit helper validates the package, approves its product ID locally, stops the local host, installs it and restarts. It is a development convenience, not permission to deploy arbitrary code to a production host.

Next configure the application licence for the development tenant and grant the module’s declared permissions to an ordinary test user. Installation alone does not grant access. Open /products/service-desk and run the acceptance checks.

For a managed test or production host

An authorised operator uses Platform Admin → Package Manager on a host where module management is enabled and the product ID is approved. Upload the ZIP, review compatibility and checksum validation, record the production backup reference, then stage the install or update. A controlled host restart activates the staged release.

Verify /health/ready and /api/platform/products/health, the active module version and the ordinary-user workflow. Keep the approved artifact and release notes. Package validation checks structure and compatibility; module code is trusted in-process code and needs review.

Build the approved ServiceDesk version and report its exact ZIP path and SHA-256. Summarise its manifest version, permissions, migrations, required configuration and test evidence. Prepare the operator's staging/restart, health-check and ordinary-user acceptance steps. Include data backup and recovery requirements. Keep production deployment as a separately scheduled operator action.

06 / THE NEXT RELEASE

Add a feature. Upgrade the module.

For version 0.2.0, add a category filter and a short resolution note. Existing requests must still load. The new fields need sensible defaults, new translated labels and additional tests. This is ordinary product development: it should not require rebuilding the KAXXIS host if the existing SDK capabilities are sufficient.

Extend ServiceDesk with a category and resolution note. Preserve existing request records with an idempotent, transaction-safe migration and sensible defaults. Add English/Italian strings and upgrade tests using 0.1.0 data.

Increase manifest.product.version to 0.2.0. Keep ModuleSdk 1.0.0 and the Contracts envelope requirement unchanged unless an evidenced new capability requires otherwise. Build the package, report tests and hash, and write release notes. Document whether the prior code can read the new schema and what recovery needs a data restore. Do not overwrite a released package under the same version.

pwsh ./modules/ServiceDesk/Build.ps1
pwsh ./Install-Module.ps1 -ArtifactPath ./modules/ServiceDesk/packages/ServiceDesk.Product.0.2.0.public-server.kaxxis-product.zip

Those install commands are for the local Docker kit. On a managed host, stage the update through the same operator workflow, then restart and verify. Each changed release needs a new version; deployment history rejects different content presented as the same version.

Recovery is explicit. Package Manager can stage the previous immutable artifact for a restart. That changes code, not the database. A migration may require a compatible schema or restoration from a verified backup. Plan and test that path before a production update.

Module upgrades and platform upgrades are distinct. A feature using a newly introduced host capability may need a compatible KAXXIS release. Module activation currently requires a restart; this is not a promise of hot-swapping or zero downtime.

OTHER STARTING POINTS

The same approach, different business work.

These are example briefs for custom modules, not included out-of-the-box products. Start with one useful workflow, prove it with users, then extend it through versioned module releases.