Your App Is Live. Who Is Looking After It Now?

Launch day tends to feel like the end of a project. The contract is signed off, the developers move on to their next job and the owner goes back to running the business. For an Australian small business that has just spent months getting a booking app or customer portal built, that is a reasonable thing to feel.

The trouble is that a live app keeps changing even when nobody touches it. The services it relies on are updated, the phones it runs on get new operating systems, and the number of people using it rises or falls. Most of the problems that follow are ordinary and fixable. What makes them expensive is that nobody was asked to look for them.

Someone has to notice when it breaks

The most common surprise is also the simplest. A customer tries to pay, the payment fails, and the business finds out days later from an annoyed email, or not at all. Without monitoring, the users are the alarm system.

Monitoring does not need to be elaborate. At a minimum, someone should get an alert when the app goes down, when errors jump above normal, or when a key action such as checkout or sign-up stops completing. The question to settle is not which tool to use. It is whose phone the alert goes to, and what that person is expected to do at nine o'clock on a Saturday night.

The parts you do not own keep moving

Few modern apps are built from scratch. Payments, maps, logins and messaging usually come from outside providers, and each of them changes its service on its own timetable. When an older version of a service is switched off, the feature that relied on it can stop working with no warning inside the app.

The app stores add their own deadlines. Google Play's target API level rules, for example, require existing apps to keep up with recent Android versions in order to remain available to new users on newer devices. An app left alone for long enough can quietly stop reaching new customers even though nothing in it is technically broken.

Code libraries age in the same way. Security patches pile up, and a small upgrade put off for a year or two can turn into a far larger piece of work. Regular small updates are dull, but they are what keeps that from happening.

Check who actually holds the keys

Ask a business owner who controls their app store listing, domain name and hosting account, and the answer is sometimes a developer they have not spoken to in a year. If those accounts were opened under the first team's name, then changing supplier, renewing a certificate or pushing an urgent fix turns into a negotiation.

This one is cheap to fix, and best done before a project ends. Make a list of every account the app depends on, including email sending, analytics and any paid services. Each should sit under a company email address, with the business as the owner and the developers added as users. Keep the logins in a shared password manager rather than in one person's inbox.

Hosting bills grow with success

Cloud hosting, databases and usage-priced services are often cheap when an app launches, because few people are using it. They are charged by consumption, so the bill rises with the customer base, sometimes faster than revenue. A business that budgeted only for the build can find that its best month of sales is also its most alarming invoice.

Treat this as a normal cost of running the product, in the same way as rent or insurance. Set a budget alert with the hosting provider, review the bill each quarter, and ask the developers what would happen to it if usage doubled.

Warranty is not the same as maintenance

Many owners assume a bug found after launch will be fixed free of charge indefinitely, as though software were a fridge. A warranty period usually covers defects in what was delivered, for a set time. It does not cover a provider changing its service, a new operating system or a feature that customers have started asking for. Clearing that up early prevents an awkward conversation later.

Before signing off on a project, it is worth asking the developers for a plain list: what they will keep doing, what it is likely to involve and what the running costs of an app usually include. A good team will have a ready answer and will not be offended by the question. Some work on retainers, while others are simply paid for the hours they spend when something comes up. Either can work, provided the arrangement is written down while everyone is still on good terms.

An app that is looked after tends to stay useful for years. One that is not usually stays online right up to the moment a customer says it has stopped working.