How it works5 stages
An implementation. You don't sign up online.
There is no self-serve checkout. That is deliberate. The product is installed for a known organisation, configured to how it already works, and supported by the people who configured it.
How it works
One codebase. Your brand. Your modules.
Five stages from discovery to ongoing support. You do not sign up online. The product is installed for a known organisation.
- Stage 1
Discovery
Yuma IT maps the operating flow, the people who hold authority, the systems already in place and the constraints that would make YumaOS a poor fit. This comes before scope and before price, because both would be invented without it.
- Stage 2
Per-client implementation
The platform is configured for your vocabulary, branding, identity provider, permissions, integrations and deployment environment. Task labels, expense categories and the other controlled lists are set to what your business already calls things.
- Stage 3
Controlled deployment
A scripted install puts one organisation on customer-controlled hardware, a private server, or Australian-hosted infrastructure we manage: one application, one database. The deploy takes a verified database backup before it migrates, applies the schema, seeds idempotently, and waits on live health checks before it reports success.
- Stage 4
Handover
Your team receives its working environment, administrative ownership, and a clear view of which connectors and operational responsibilities are yours. The admin tier holds every action unconditionally, so nothing about the deployment stays behind a vendor door.
- Stage 5
Ongoing support
Yuma IT supports the implementation over time. The commercial price, scope and support arrangement are agreed per client, not enforced by billing code inside the product.
Who is responsible for what, written down before you start.
Self-hosting means real ownership on both sides. The line below is the one worth agreeing early.
- Workflow and fit discovery
- Deployment configuration and the operational vocabulary
- Branding, identity and access configuration
- Integration setup for the connectors you choose to switch on
- Ongoing support under the agreed engagement
- The host, the network and the operating environment
- Database and document-storage continuity
- Identity and provider accounts
- Connector credentials and the data-sharing decisions that come with them
- Backup and recovery beyond the pre-migration backup the deploy script takes
What runs, once it is running.
A dedicated application, a dedicated database, and a scripted deploy. Nothing here needs a platform team.
Application
The product UI and APIs, with health checks on the running service itself.
Database
Your dedicated database: 94 application tables, plus agent memory stored separately so upgrades cannot drop chat history.
Deploy
One command builds and installs the release, writes a verified non-empty database backup, applies the schema, seeds, and waits on live health checks.
Upgrades
Schema changes are applied as a push rather than as reviewable migration files. If your change control requires reversible migrations, raise it in discovery so it is priced in rather than discovered later.
Before scope, before price, establish that it fits.
YumaOS does not publish a package price, an implementation duration or a supported user count. Any of those quoted before discovery would be a guess dressed up as a number.