The invisible developer

There's a kind of software success that almost never gets applause.

The website loads.

Forms work.

People can sign in.

Backups run.

Nobody mentions it.

Then, one morning, a service goes down.

Suddenly everyone remembers there's an IT person somewhere. 😅

The success nobody sees

When you present a new application, you can show screens, features and animations.

It's tangible.

Maintenance often looks like nothing happening.

A certificate renewed before it expires. A backup restored successfully during a test. An alert caught early. A dependency patched before trouble begins.

These tasks are valuable.

But people mainly notice them when they weren't done.

What “the site works” actually means

An online product doesn't end at deployment.

It depends on hosting, domains, libraries, third-party services, credentials, databases and people who know how to respond.

Take a platform that sends notifications.

If the messaging provider stops working, the interface may still look perfect. But customers no longer receive confirmations.

You won't necessarily see the problem on the homepage.

That's why “Is the website reachable?” isn't always the right question.

Sometimes you need to ask: “Does the essential user journey still work from beginning to end?”

Prevention takes work

A backup isn't enough if nobody has tried restoring it.

Alerts aren't useful if everybody ignores them.

Updating a package isn't enough if the update breaks a critical feature.

Reliability requires habits:

• Identify essential user journeys.
• Test backups and restores.
• Monitor errors, uptime and system resources.
• Test changes before release.
• Document emergency procedures.
• Keep access and responsibilities clear.

You don't need a massive organisation to begin.

But you do need to treat these activities as real work.

Support is a human job too

When something breaks, the user may not want a lecture about servers.

They want to know what happened, what they should do and when the service might recover.

A good response begins with listening and clear information.

Not promising an immediate fix when you don't know the cause is part of being professional.

Support teams know this well: technical problems quickly become communication problems.

Pricing the invisible

Maintenance can be hard to explain in proposals.

Why pay every month if nothing looks different?

Precisely because the goal is often to prevent things from getting worse.

A contract should clarify monitoring, updates, assistance, backups, security, response expectations and exclusions.

Otherwise expectations become impossible to meet.

I also discuss maintenance costs in The tiny SaaS dream.

The next time an app works

I don't expect applause every time someone loads a webpage.

That would get tiring for everyone. 😂

But I'd like us to remember that a reliable system isn't simply one designed well on launch day.

It's a system somebody keeps caring for after launch.

That invisible work deserves recognition in how we plan, value and fund digital products.