What does maintaining custom software actually involve after it launches?

Four categories of ongoing work

• External change absorption. APIs deprecate endpoints, change field types, tighten rate limits and rotate authentication schemes. This is the largest bucket and it is entirely outside your control.
• Security and dependency upkeep. Runtime versions reach end of life, libraries publish advisories. Skipping this for two years turns a routine update into a migration project.
• Business rule drift. The pricing tiers changed, a new location has different rules, a form needs another field. This is healthy work — it means the system is being used.
• Actual defects. Real, but usually the smallest category after the first few months of a well-built system.

Why integration-heavy systems cost more to keep alive

There is a useful rule of thumb here: your ongoing maintenance load scales with the number of systems you depend on, not with the number of features you shipped.

A self-contained internal tool with no external dependencies can genuinely sit untouched for a long time. The moment it consumes somebody else's API, it inherits that vendor's release cadence.

This is a real argument for consolidating integrations rather than letting each department wire up its own. Five departments each maintaining their own connection to the same platform is five copies of the same upkeep. One integration layer that everything else reads from concentrates that work in a single place where it can be monitored and tested properly.

What to insist on so maintenance stays cheap

A few engineering choices dramatically change ongoing load. Ask for them explicitly, because they are invisible in a demo.

Structured logging that records every external call and its response. Alerting on failed syncs rather than waiting for a user to notice. Automated checks that hit each dependency and verify the response shape. Configuration held in settings rather than hardcoded, so a rule change does not require a deployment. Credentials stored where they can be rotated without touching code.

The neglect pattern to avoid

The expensive failure is not steady maintenance. It is deferred maintenance that arrives all at once: three years of skipped updates, an expired credential nobody documented, and the original developer unreachable. At that point what should have been routine becomes an archaeology project.

Treat custom systems the way you treat vehicles — small scheduled attention rather than heroic repair. That is also the honest framing for any AI system you build, since model providers and platform APIs both move faster than traditional software.