The software you paid for does not change on its own. Everything it depends on does. The language it is written in, the database beneath it, the browsers it runs in, the phone operating systems it ships to and every system it connects to are all on release schedules of their own, and none of them wait for you.
Maintenance is the work of keeping a stationary thing compatible with a moving world. We patch, we watch, we check the data, and we tell you what we found in language you can act on.
Built here. Your data stays here.
A machine on a factory floor wears. Software does not. The file you paid for in 2022 is byte for byte the same file today, and that is exactly the problem. It was written to fit a world that has since moved on without it.
That drift is invisible until it is not. A security hole is found in a library your application uses, and there is no patch for you because the version you are on stopped being supported last year. An app stops appearing in the store because it targets an Android version Google no longer accepts. A sync to your accounting system dies overnight because the platform retired the connection it used, six months after announcing it in a notice nobody read.
None of those are failures of the original build. They are the predictable result of leaving a system alone. And every one of them is cheaper to handle in advance than on the morning it lands, which is the entire argument for maintenance.
These are the release cycles underneath a typical business application. Every one of them is published in advance, which means every one of them can be planned for instead of reacted to.
Every major version of Node.js is supported for around three years and then stops receiving security fixes altogether. PHP gives two years of active support and one more of security patches only. Each .NET long-term release gets three years. None of those clocks stop because nobody is looking at them.
PostgreSQL supports each major version for five years. SQL Server, MySQL and Oracle all run their own lifecycles. Running past the end of one does not break anything on the day. It means the next security hole found in it never gets fixed for you.
Chrome and Edge ship a new version roughly every four weeks, and each one can quietly change how a page behaves. A screen that worked on Friday can be broken on Monday without a single line of your code changing.
Apple and Google both release a major version every year, and both set a floor. Google Play requires an app to target a recent Android version or it stops being offered to new users. Apple requires submissions built against a recent SDK. An app nobody rebuilds eventually cannot be updated at all.
A modern application pulls in hundreds of open source packages. When a serious hole is found in one, the whole industry patches within days. Log4Shell in December 2021 is the one most people remember, and the businesses that were fine were the ones who already knew what they were running.
The security certificate on your site has a hard expiry, and the maximum life has been getting shorter every few years. When one lapses, the site does not degrade. Browsers put a full-page security warning in front of every visitor until it is replaced.
Monitoring is not a dashboard nobody opens. It is a short list of specific things that go wrong in specific ways, checked deliberately and on a schedule. Here is what that covers and why each one earns its place.
When a page fails, most people do not ring. They try once more, give up, and go somewhere else. The error is recorded on the server and, if nobody is reading the server, that is where it stays.
We collect errors as they happen and group them, so a fault that has hit forty people this week looks different from one that hit a single person once. The first gets fixed now. The second gets fixed in the next block of work.
Systems rarely fail suddenly. A disk fills a little each week. A process leaks a little memory each day. A report that used to take two seconds takes nine. Every one of those is visible in the logs months before it becomes an outage.
Reading them is the cheapest work in maintenance and the most commonly skipped, because nothing is broken yet. That is exactly why it is worth doing.
This is the category that costs the most and shows up the latest. A retried request creates the invoice twice. A sync stops halfway and leaves half a record. A date lands in American format and a March job is filed in December. A rounding difference of a cent multiplies across ten thousand lines.
None of that triggers a failure message. The software runs perfectly and the numbers are wrong. So we run checks against the data itself, looking for duplicates, orphans, totals that do not reconcile and records that should not exist, and we look on a schedule rather than when somebody complains.
Nightly syncs, scheduled reports, invoice runs, reminder emails and queued exports all happen when nobody is watching. When one stops, there is no error on anybody screen. There is just an email that never arrived and a report nobody chased.
Every scheduled job is monitored for the thing that matters, which is not whether it ran but whether it finished and produced what it was supposed to produce.
Almost every business has backups. A much smaller number have ever restored one. The gap between those two is where the bad stories live: the backup that had been writing an empty file for eight months, the one that covered the database but not the uploaded documents.
We check that backups are running, and we periodically restore one somewhere safe to prove it actually works. That is the only version of this that counts.
Security certificates, API credentials, signing certificates for mobile apps, domain renewals and payment gateway keys all expire. Each one takes something down completely when it does, usually on a weekend.
Every one of them goes on a register with its date and an owner, and we act on them before they land rather than after.
An integration is the only part of your software where somebody else can change the rules without telling you directly. It is also, on most projects, the part nobody owns once the build is finished. These are the six ways they fail.
Xero, MYOB, Stripe, HubSpot and every other platform version their connections and retire old versions on their own timetable. They announce it in developer notices most businesses never see. If nobody is reading those, the first sign is the day it stops working.
A connection between two systems is authorised by somebody, once. When that person leaves, changes their password, or an administrator tidies up old app permissions, the connection dies. It does not announce itself. Data simply stops moving.
Many integrations rely on one system pinging another when something happens. If your side is down or slow, the sending system retries a handful of times and then gives up permanently. Nothing errors on your end because nothing arrived. Those records are simply missing.
Every platform caps how many requests you may make. A sync that was comfortable at two hundred invoices a day starts being throttled at two thousand. The integration does not break, it starts dropping behind, and the numbers in the two systems slowly separate.
A field that was optional becomes required. A code gains a new value nobody expected. A number arrives as text. The integration keeps running and writes something wrong, which is worse than stopping, because nobody finds out until a reconciliation.
When a sync fails partway, one system has the record and the other does not. Without something that regularly compares the two and reports the difference, that gap never closes on its own. It just grows, until somebody notices the debtors do not match.
Without maintenance
With maintenance
The work is the same either way. The difference is whether it is scheduled or whether it is an emergency.
Talk to us about your systemA tool three people use for an hour a week and an application your field crews cannot work without should not be on the same plan, and charging for the same plan would be the easy thing to do. These are the six things that decide the shape of yours.
A system three people use for an hour is a different risk from one forty people cannot work without. The second one justifies cover the first one does not.
Anything that takes payments, issues invoices or feeds the ledger gets watched harder, because an error there is not an inconvenience. It is a number in your accounts that is wrong.
Every connection is a moving part you do not control. One integration is manageable. Five means something is changing on somebody else timetable most months.
For some systems the honest answer is very little, and we will say so. For a field crew that cannot raise a job or a shop that cannot take an order, it is the number that decides everything else.
Australian privacy obligations do not care how small the business is. If a system holds customer records, the standard of care and the speed of patching both go up.
If there is a capable developer in house, the right package covers the things they cannot do alone, such as out of hours cover and a second set of eyes. There is no sense paying us to duplicate them.
We had not thought about it once since the system went live. The first report came back with an expired certificate two weeks out and a nightly sync that had been failing since June. Neither of those had reached us as a complaint yet, which was the unsettling part.
Because the code is not what changes. Everything underneath it does. The language it is written in, the database, the browsers, the phone operating systems and every system it connects to are all on their own release schedules, and none of them wait for you. Maintenance is the work of keeping a stationary thing compatible with a moving world. The businesses that skip it do not pay nothing, they pay later and all at once, usually at the worst moment.
Support is reactive. Something breaks, you ring, somebody fixes it. Maintenance is the work that happens when nothing is broken: applying security patches, reading the logs, checking the data, watching the integrations, testing the backups and keeping dependencies current. Most maintenance packages include support, but a support contract on its own leaves the preventable failures to keep happening.
It is scoped per system rather than picked off a list, because the right cover for a simple internal tool and for a customer-facing app that takes payments are not remotely the same thing. We look at how many people depend on it, whether money moves through it, how many integrations it carries, what downtime actually costs you, and what skills you already have in house. Then we propose a shape, in writing, with what is in it and what is not.
Yes, and a good share of this work is exactly that. We start by reading the code and the infrastructure and giving you a written picture of what you have, including the parts that are out of support and the risks nobody has told you about. You get that assessment whether or not you go ahead with ongoing work.
We watch the developer notices for the platforms you are connected to, so a retirement or a version change is something we plan for rather than react to. When one is announced, you get told what changes, when the deadline is, and what the work involves, ahead of the date rather than after a failure.
You get a report you can read without a technical background. What was patched, what errors came up and what was done about them, how the integrations behaved, what the data checks found, and what we recommend next. If a month is quiet the report says so in a paragraph. The point is that you can see the work, not take it on faith.
Sometimes not, and we will tell you. A small internal tool with no integrations, no payments and no personal data may genuinely need very little beyond keeping its host patched. The honest version of this service includes saying when the answer is a light touch, because selling cover somebody does not need is a short relationship.
No. We are Perth based and work with businesses across Australia, and this is work that is delivered remotely by nature. Everything is done by our own team in Australia, and nothing is subcontracted overseas.
Sending your details…
You can stay on this page while we send it.
What the system does, roughly how old it is, who built it, how many people rely on it, and what it connects to. We come back with an honest read on what it needs, including when the answer is less than you expected.
Prefer a quick chat? Call 0425 531 127. We answer the phone in Perth.
Thanks for reaching out. We will get back to you within one business day.
See what else we do