Why Indonesian SMEs Should Care About Software Maintenance, Not Just Build

Most discussions about custom software focus on the build. The vendor’s pitch, the timeline, the price. The build is exciting. The build ships in a few months and there’s a launch.

The thing nobody really wants to talk about: 70% of the lifetime cost of custom software is the maintenance, not the build. SMEs that don’t plan for it consistently end up with software that quietly rots — still running, but increasingly fragile, expensive to change, and eventually replaced at considerable pain.

Worth understanding what maintenance actually is and what it costs before you commit to building anything custom.

What “maintenance” actually means

Maintenance isn’t just bug fixes. It’s a category that covers:

• Security updates. The libraries and platforms you build on get security patches monthly. Skipping them creates vulnerabilities. Applying them sometimes breaks things.
• Compatibility with services your software depends on. When Tokopedia’s API changes, your integration breaks if nobody’s watching. When Stripe deprecates an endpoint, your checkout stops working.
• Bug fixes for issues that surface in production. Things you didn’t catch in testing because they only happen with real customer data at real scale.
• Small feature additions. Almost every “we shipped it” eventually gets “can it also do X?” The smaller version of those needs to be cheap and predictable.
• Documentation updates. As the team that built it changes (and it always does), the people now maintaining need to understand what was built.
• Performance tuning. As data grows, queries that were fast at 10,000 rows are slow at 1,000,000.

Skip any of these for too long and the software degrades. The first time something breaks, you’re paying emergency rates to fix it.

The realistic ongoing cost

For Indonesian SME custom software in 2026:

• Light maintenance (~5% of build cost annually): security patches, occasional small bug fixes, minimal feature work. Software essentially frozen. OK for a stable system that doesn’t need to evolve.
• Active maintenance (10–15% of build cost annually): patches, regular small features, bug fixes, dependency updates, occasional minor performance work. Right for most SME systems.
• Heavy maintenance / continuous improvement (20–30% of build cost annually): regular new feature work, architectural improvements, performance tuning, ongoing UX iteration. Right when the software is core to the business and competitive position depends on continuous evolution.

A project that costs Rp 150 juta to build typically needs Rp 15–22 juta a year in active maintenance. Skip it and you’re saving Rp 15 juta a year for two years, then paying Rp 80 juta to dig out of accumulated technical debt in year three.

What goes wrong when SMEs skip it

Patterns we see consistently:

Year 1: nothing visible

Software runs fine. Nobody touches it. Owner congratulates themselves on the savings.

Year 2: small annoyances

Some integrations stop working. Performance gets sluggish on certain pages. The team works around it. Owner thinks: “we’ll get to it eventually.”

Year 3: a real problem

Something breaks at a bad moment. A payment integration fails during a flash sale. An audit log gap causes a compliance issue. The original vendor is unreachable or has moved on. Emergency rates apply, panic sets in.

Year 4: replacement decision

The system has accumulated enough technical debt that fixing is more expensive than rebuilding. The SME ends up paying for the same software twice in five years.

This pattern is so common we’ve started building maintenance contracts into every initial build proposal — not because we’re trying to upsell, but because the alternative outcome is predictably bad.

How to think about maintenance during the build

Three things to lock in before signing the build contract:

1. A maintenance retainer with clear scope

Define what’s included monthly: security patches, dependency updates, X hours of feature work, response SLA for emergencies. Define what’s excluded: major architectural changes, new product modules.

Typical SME monthly retainer: Rp 5–18 juta covering 8–25 hours of work per month plus on-call availability for critical issues.

2. Documentation as a deliverable

The build isn’t done until the documentation is done. At minimum: architecture overview, deployment instructions, environment variables, third-party service dependencies, runbook for common issues.

This sounds boring. It’s the difference between being able to switch maintenance vendors in a week vs three months.

3. Code ownership and access

You should own the code, not the vendor. Source code in a repository you control. Production access through accounts you own. Domains, hosting, and services in your name.

Vendors who push back on this are creating future leverage over you. Walk away.

When to invest more in maintenance

Three triggers that should bump your maintenance investment:

• The software starts handling more revenue or operations. If the system was processing Rp 1 miliar/year of orders at launch and Rp 10 miliar/year now, the cost of an outage is 10x. Maintenance should scale up before something breaks.
• The team that built it has fully turned over. New people maintaining old code need more time to understand it. Budget accordingly.
• The technology stack is aging. A 4-year-old stack starts to need real refresh work. Plan for it.

The honest framing

Building custom software is like buying a building. The construction cost is significant, but if you don’t budget for the roof, the plumbing, the periodic refresh — the building deteriorates and eventually has to be replaced. The structures that last decades are the ones whose owners budgeted for upkeep from day one.

If you’re approaching a custom software project and want to plan the full lifecycle realistically, an hour of conversation usually clarifies what the maintenance picture should look like for your specific case. We do those at no cost.