These are not separate products with separate teams behind them. They are four ways of applying one skill set to the same problem: understanding how your operation runs, writing the application it needs, connecting it to everything already in place, and keeping it healthy afterwards. Which leads depends on where you are today — most clients use all four eventually.
This is the work most people mean by custom software: applications that exist because nothing on the market fits. We begin by mapping the process as it is really performed — especially the exceptions, which is where generic tools break — and turn it into a domain model neither too rigid to change nor too loose to report against. It is built for real conditions: cracked tablets on remote sites, sign-offs between jobs, audit trails that survive scrutiny.
Integration is where operational data quietly goes wrong. A nightly file that fails unobserved becomes a week of mismatched invoices discovered at month end, so we replace fragile point-to-point connectors with a governed layer: versioned contracts, observable pipelines and reconciliation proving both sides agree. We work with whatever your platforms expose — REST and SOAP endpoints, database views, SFTP drops, EDI files, occasionally a legacy screen where no interface exists.
A system nobody maintains degrades quietly: dependencies age out of support, restores stop being tested, whoever understood the nightly job moves on. We run structured support for software we wrote and for inherited systems passing a takeover review, starting with an audit of environments, credentials and deployment path.
Cloud work is mostly not lift-and-shift; it is making releases routine and cost predictable. We build and migrate on AWS and Azure with infrastructure as code and tagging discipline, so staging mirrors production and the monthly bill can be explained line by line. Migrations move in stages, old and new running in parallel until reconciliation agrees, then read traffic switched before write.
Engagements rarely stay inside one category. Below is a pattern we see repeatedly among Australian mid-market operators.
A national logistics operator asked us to stabilise the connection between dispatch and accounting: orders were dropping overnight unnoticed. Surveying first showed fourteen point-to-point jobs written by three people over eight years. The integration work was genuine and delivered first — reconciliation reporting, retry logic, alerting.
Once the data flowed, something else became obvious. The same operator carried a spreadsheet-only process for customer approvals, existing purely because nothing connected dispatch to the customer record. That became a portal for orders, documents and approvals, built on the integration layer already in place. Proposing it in week one, before anyone trusted the numbers, would have been premature.
The portal later moved to cloud hosting with infrastructure as code, initially so releases could run fortnightly without downtime, then because reporting load justified separating it from transactional traffic. Two years on it is mostly a support retainer: patch windows, restore drills and small improvements from daily users. That sequence — integration exposing the gap, a build filling it, cloud making it operable, maintenance keeping it trustworthy — is typical. Each phase is scoped alone, so commissioning the first never commits you to the fourth.
These bands describe work delivered for Australian mid-market organisations. They help you decide whether a conversation is worth having; they do not price your project.
These figures are indicative only. Every engagement is quoted against a written scope after inspecting your data and constraints, with assumptions and exclusions stated. Amounts exclude GST, and exclude cloud consumption — compute, storage, licence and data transfer billed to you directly by AWS or Azure, reported monthly rather than marked up. Fixed-price, time-and-materials and retainer structures are all available; we recommend whichever suits the certainty of the work.
The same six stages sit behind every engagement, whichever service leads. You can stop after any one and still hold something useful.
We agree what is broken and what success measures — cycle time, error rate, hours recovered — before discussing features. Outputs are a problem statement and boundaries.
Data extracts and platform access are inspected, then options costed with assumptions named. Some ideas die cheaply here, which is why it comes first.
Data model, API definitions, permissions and integration boundaries agreed and documented, so dependent teams can work in parallel without guessing.
Fortnightly increments deployed to a reviewable environment, each carrying tests. Progress is judged on working screens rather than reported percentages.
Migration dry runs, a rehearsed AWST window, a rollback point and parallel running until reconciliation agrees on both sides.
Monitoring, patch cadence, restore drills and a rolling backlog, handled by engineers who built the system.
Describe the problem in plain language. We will tell you which discipline applies, and whether software is the answer.
