Machine learning development in Brisbane
An unplanned stop on a haul truck, a crusher or a conveyor costs a mine far more than the part that failed, and the machines already report the vibration, temperature and pressure readings that come before most failures. Brisbane's METS firms are well placed to turn that data into a product, because they understand the equipment. What they often lack is the engineering to run a model reliably across many customers' sites.
We build that: models trained on your equipment history, features computed the same way in training and on live data, per-site monitoring for drift when conditions change, and alerts in a form a maintenance planner will act on. On FM360 we took repeat-fault clustering from an experiment to production, and the lesson carries: engineers trust a prediction only when they can see what it is based on.
The state is one of Brisbane's largest software buyers. The Queensland Government, its departments and its hospital and health services run a large share of the city's technology work, directly and through the consultancies and suppliers around them. They need public services that work for someone on fibre in the inner city and someone on a weak mobile signal in a remote community, and internal systems that let a small team look after a very big state.
Mining services are the second pillar. Queensland's mining equipment, technology and services firms sell into the Bowen Basin and to mines around the world, and many run their engineering and head offices from Brisbane. Their software problems come from distance: equipment reporting over intermittent links, maintenance data from sites hours from the nearest city, and field crews working on rosters. Health adds a third: a large public health system spread across the state, where a clinician in a regional town and a specialist in Brisbane need the same record. Looking further out, the Brisbane 2032 Olympic and Paralympic Games are already driving infrastructure work across the south-east, and the tourism, events and food businesses around them are planning for demand their systems have never seen.
Hiring costs less than in Sydney or Melbourne. Indeed puts the average base salary for a software engineer in Brisbane at A$101,980, from 87 reported salaries. Specialist skills are the harder part: an engineer who has built for remote sites, offline field work or a booking spike is a rare hire in any city. That is where we fit: senior engineers on a defined piece of work within days, with the code in your repositories from the first commit.
Our four hours of daily overlap land in your afternoon, moved to suit your team. Neither Queensland nor India changes its clocks, so the window sits at the same point in your day all year round. Your morning belongs to your own team; the afternoon is for stand-ups, reviews and decisions with the engineer who writes your code, and runbooks and architecture notes are written as we go.
We are the right fit when a system your team has no time to build has a clear shape, when you need senior engineers on it within days, or when a hire is still months from starting. Begin with a fixed-price two-week piece and judge us on what ships. Agencies and consultancies can put the work under their own name.
Four ways this arrives.
Someone got good results on a laptop and nobody can reproduce them. We turn it into a training pipeline with pinned data and versioned artefacts, put a serving endpoint in front of it, and record what it was evaluated on so the next version can be compared.
Hundreds of conditions routing tickets or flagging risky orders, each added after an incident. We measure what the rules get wrong on your labelled history, then test whether a classifier beats them. Sometimes the answer is fewer, better rules, and we say so.
Demand, load or staffing estimates that miss often enough to be ignored. We start with a plain seasonal baseline, backtest against the periods you actually plan around, and add complexity only where it beats that baseline on those periods.
Duplicate records, recurring faults, near-identical products under different names. Embeddings group text by meaning where keyword matching cannot, and we build the screen that lets a person correct a group rather than trust it blindly.
Repeat-fault detection that began as UMAP and HDBSCAN over 33,000 work orders and shipped as nightly incremental clustering on the same embedding model.
Read the write-up →Asked by Brisbane teams.
How do you work with teams in Brisbane?+
We are in Bengaluru, and four hours of every working day overlap with your afternoon, moved to suit your team. Neither Queensland nor India changes its clocks, so the window stays put all year. Stand-ups, code reviews and design calls happen live in it. We work in your tools, whether that is Slack, GitHub or Linear, and the person on every call is the engineer who writes the code.
Do you build for mining and METS companies?+
Yes. Brisbane's mining equipment, technology and services firms need software around their equipment, and that is what we build: backends that accept late and out-of-order data from remote sites, models that predict failures from vibration and temperature readings, offline apps for field crews, and roster and competency tools for contractors. We work inside your codebase and your cloud, starting with the problem that costs you most on site.
How does your rate compare to hiring in Brisbane?+
Indeed puts the average base salary for a software engineer in Brisbane at around A$102,000. Our published rate is $35/hour with a $5,000 minimum, or $5,400 a month for one embedded engineer. There is no recruiting time and no employment overhead, and work can start within days of the call. The first piece is a fixed-price two-week engagement at $2,800, so you can judge us on what ships.
Can you add capacity while we wait for a hire?+
Yes. If a Brisbane role is open and the roadmap is still moving, we can take a defined piece of it now. Start with a fixed-price two-week piece, or embed one engineer at $5,400 a month. Runbooks and architecture notes are written as we go and the code sits in your repositories from the first commit, so when your hire starts, they inherit work they can read and extend.
Do we need machine learning, or is a rules engine enough?+
Often a rules engine is enough, and it is cheaper to run, explain and audit. If the people who make the decision today can write it down, write it down. A model earns its place when the rules keep multiplying, the inputs are messy text or images, or the pattern shifts faster than anyone can edit the rules. We check against your history before recommending either.
Why not just call a hosted model API?+
Sometimes you should. With low volume, messy language and no labelled data, a hosted model and a good prompt ship quickly. A trained model wins when per-call pricing starts to hurt at your volume, when latency matters, when data cannot leave your systems, or when you have labelled examples a small model can learn from. We price both paths before you commit.
How much data do we need?+
For classification, usually fewer labelled examples than people fear, and embeddings can group text with no labels at all. Forecasting is the opposite: you need enough history to cover the cycles you plan around, and a single year says little about a yearly pattern. We give you an answer after looking at your data, not before.
What happens when the model gets worse?+
It will, because the world it learned from changes. We log inputs and predictions, compare them with outcomes as they arrive, and alert when accuracy or the input mix drifts past a threshold you agreed. Retraining is a scripted pipeline with an evaluation gate, so a new model replaces the old one only when it does better on the same test set.
Can you build a recommendation system?+
Yes, and we would start without a learned model. Co-occurrence and embedding similarity, served from Postgres or a vector index, beat a most-popular list for most catalogues and are easy to debug. A learned ranker comes after that, once you have enough interaction data to train and evaluate one. A learned ranker is something we build from our work with embeddings and clustering, starting from a simple baseline you can measure it against.