Building software for the decisions that keep institutions working

The founding problem was not a lack of data. It was the distance between what organisational systems record and what an experienced person must know to make a workable plan. People, commitments, rules and resources sit in separate places, while real decisions require them to be considered together. The work of reconciling those differences often happens through spreadsheets, repeated conversations and local judgement.

We began with workforce planning because it is a rigorous test of the idea. Availability is not the same as deployable capability. A roster may satisfy its hours and still fail because of qualifications, supervision, fatigue, training or competing responsibilities. Fixing one shift can move a shortage elsewhere. We wanted to build software that understands those interactions rather than simply provides a cleaner place to type them.

Crucible Systems Pty Ltd was established in 2026. Our first engineering direction combines a structured model of operational resources with validated policy constraints and optimisation methods. The immediate objective is a credible way to generate, explain and repair workforce plans. Prediction, simulation, controlled execution and broader resource strategy sit within the longer-term architecture, but must be justified by real operating evidence before they become dependable products.

We do not assume an algorithm should decide an institution's priorities. Leaders and accountable staff define objectives, interpret the rules and retain the authority to act. Our task is to make complex consequences visible, distinguish feasible options from invalid ones and give human judgement something more reliable to work with.

Crucible was founded by Colin Ferreira, Anthony Nieves and Dylan Standon. The team combines responsibility for company and technical direction, the operational detail required to make a product useful, and the commercial and institutional work needed to bring consequential software into practice.

Those responsibilities are deliberately connected. A rule discovered during an operational conversation can change the resource model. A technical limitation can affect what an evaluation should attempt. A procurement or governance requirement can influence architecture long before a system reaches production. The founders work across those boundaries rather than treating engineering, operations and institutional engagement as separate exercises.

We start with the actual process, including its exceptional cases. We want to know what makes a plan invalid, why an experienced user may reject a technically sound result, how approvals work and what happens when the plan meets reality. We then model the constraints, test difficult scenarios and examine whether the resulting recommendations are understandable enough to challenge.

The measures that matter are operational: planning and rework effort, deployable coverage, overtime implications, roster stability, fairness, auditability and the ability to respond to disruption. The specific measures belong in a mutually agreed evaluation, not a marketing claim made before one has occurred.

We also design for the responsibilities of the organisations we hope to serve. That means clear authority boundaries, careful treatment of personal information, traceable changes and compatibility with existing systems where replacing them would create unnecessary risk. The goal is to earn a place in serious operations through demonstrated utility, not through promises of unrestricted automation.