Kaze
in developmentSix modules. One system underneath.
Most teams run a service desk, an asset list, a project tool, a CRM, a password manager and something for signatures — six products that do not know each other exist. Kaze is one platform where those are modules on a shared spine, and you turn on only the ones you need.
minatolabs.
Modules
Today14 August 2026
- SLA · Service Desk
- Expiry · Assets
Renewal — 24 seats
- Meeting · CRM
Friday15 August 2026
- Sprint · Projects
- Due · Sign
Master services agreement
- Window · Assets
one calendar · five modules · concept preview
01 — what is in the box
Six modules, each one a product in its own right.
Service Desk
itsmTickets with queues, approvals and SLA timers, plus a self-service portal with a knowledge base for the people you support.
/itsm · tickets, approvals, portal, kb
Assets
itamHardware and licence inventory with assignment and custody history, a CMDB view, and printable asset labels.
/itam · assets, cmdb, licenses, labels
Projects
projectsProjects and ordered tasks, created by hand or spun up from a template when something upstream closes.
/projects
CRM
crmLeads, contacts, accounts and an opportunity pipeline with a board view, forecasting and duplicate detection.
/crm · leads, contacts, accounts, opportunities, forecast
Vault
vaultTeam credentials encrypted in your browser — the server only ever stores ciphertext. Shared through collections, with password health checked locally and a break-glass path.
/vault · sharing, health, provisioning, emergency
Sign
signPrepare a document, send an envelope, and let a signer complete it from a link — with an append-only event trail.
/sign · prepare, envelopes, signer link
Dashboard and Calendar are not modules — they belong to the platform itself and are always there. The calendar is the clearest example of the shared spine: it collects what the enabled modules put on it, so ticket SLAs, licence expiries, project dates, CRM meetings and signature deadlines land on one calendar instead of five.
02 — one system, not six tools
One event, acted on across every module.
Every module publishes its domain events to a shared outbox, and every dispatched event is offered to the automation engine. A rule is a trigger, a condition over that event, and a list of actions — and the actions can belong to any module you have switched on.
So one deal closing raises the project, the tickets, the credential request and the agreement together, in one rule, instead of one person noticing and telling four others. Each action reads the event that triggered it. Nothing is copied between systems, because there is only one system.
- Test it before you trust it
- Rules dry-run against a sample event and show you which steps would fire and which would be skipped, without executing anything.
- It degrades quietly
- If a rule names an action from a module you have turned off, that step is skipped and recorded — the rest of the rule still runs.
- Stages, when you need them
- Actions publish their own events, so a rule's result can trigger the next rule. Each action is configured on the rule and reads the event that fired it — steps do not read each other's output.
Automation · rule
enabledWhen
crm.opportunity.closed_won
Condition — amount is at or above the onboarding threshold
Then, in order
projects.create_from_templateProjectsSpin the onboarding project up from a template, so the plan is the same every time rather than rebuilt from memory.
itsm.ticket.createService DeskRaise the tickets the rollout actually needs — the account, the mailbox, the kit — in the queue that owns them.
itam.asset.assignAssetsAssign the kit named on the rule to its holder, and record the custody change rather than leaving it in a spreadsheet.
vault.request_provisioningVaultOpen a provisioning request for the credential against the right collection and assignee. It raises the request for a human to fulfil — it does not mint a secret on its own.
sign.send_from_templateSignSend the agreement to the named recipients from a template, and track the envelope until it is signed.
itam.asset.set_statusAssetsskipped · module offAn example of the gated state: this tenant has the Assets module switched off, so the step is skipped and logged rather than failing the rule.
concept preview — Kaze is being built right now
03 — only the parts you want
A module you have not bought is genuinely not there.
Modules are licensed and toggled per tenant. Turning one off is not a hidden menu item — it is enforced at the API, so the module is absent everywhere at once.
01
In the API
Requests to a disabled module's endpoints are refused with a 403 and an explicit module_disabled reason, not a generic error.
02
In search
Search only looks at providers for modules the tenant has enabled, so results cannot leak from a module that is switched off.
03
In automation
A rule step belonging to a disabled module is skipped with the reason recorded, and the remaining steps still run.
A smaller team's workspace
Three modules on, three off. The navigation, the search index and the automation actions all narrow to match — and the calendar simply has less on it.
04 — underneath all of it
One tenant boundary, one audit trail, one identity.
Tenant isolation in the database
Every module's tables carry row-level security, so separation is enforced by Postgres rather than by remembering a WHERE clause.
Roles across modules
People, groups and role assignments live in the platform, so access is granted once rather than six times.
Signed webhooks
Automation can call out to your own systems, HMAC-signed with a secret you set on the rule.
Append-only history
Audit entries, asset custody and signature events are append-only at the database level, not just by convention.
in development
Kaze is being built right now.
Modules are licensed per tenant and priced by quote, so there is no self-serve signup yet. Leave your email and we will get in touch when it is ready for your team.