Picture a Malaysian SME owner who, roughly two years ago, signed the first contract for a custom system that was meant to organise the business once and for all. The vendor delivered. The team went live. The owner signed off on the final invoice with the quiet satisfaction of a project finished. Since then, the same owner has approved three further invoices for what was nominally the same system — a Phase 2 for the approval matrix that no longer fit the team that grew around it, a small adjustment so the chart of accounts could answer the questions the owner had started asking, and an enhancement so the operations team could handle the new branch. None of these were in the original quote. None of them felt unreasonable in isolation. Added together, the budget the owner has actually spent on the system now sits well beyond what they signed for, and there is no clean moment in sight when the spending will stop.

This pattern is not rare. Across the engagements our team has run for Malaysian SMEs, it is closer to universal. Owners rarely talk about it openly because it is awkward on both sides — the vendor does not want to admit that custom systems need ongoing care, and the owner does not want to admit they signed for what they believed was a finished asset. Our consultants have come to recognise this as a structural feature of how SME software is priced and sold in Malaysia, not an unfortunate run of bad vendors. The project-pricing model itself is what produces the second payment, the third, and the fourth. Understanding why is the first step to choosing a different relationship.

Key Takeaways
  • Most Malaysian SMEs pay for the same custom system multiple times across its lifespan, even when the original build was delivered correctly.
  • The reason is structural — the project pricing model treats software as a finished asset rather than a living tool that the business keeps changing.
  • The vendor disappears because that is how the project model works, not because of bad intent; the same incentive that signed them on rewards them for moving to the next deal.
  • A retainer-based partnership keeps the same team responsible for the same system across its lifespan, absorbing change continuously instead of as fresh projects.

The Story Every Malaysian SME Owner Eventually Lives

The first few months after go-live feel like the project succeeded. The team is using the system, the dashboards are populating, and the owner finally has the visibility they paid for. The vendor sends a polite follow-up note at month three offering training top-ups, and everything is on track. Then, almost imperceptibly, the rhythm shifts. Around month four or five, the finance team decides to restructure the chart of accounts so management reports actually answer the questions the owner has started asking. The current ERP configuration was modelled on the chart that existed at sign-off, and the proposed structure does not map cleanly onto it. The vendor is contacted. The vendor confirms the change is real and proposes a small scope of work to remodel the affected modules. The owner approves it because the alternative is the finance team manually reclassifying every report at every month-end.

A regulatory update lands a couple of months later. The e-invoice schema evolves, or a new disclosure category is added, or a fresh compliance category enters the picture for the industry. The system, built against the previous specification, needs adjusting. Another small scope of work, another approval. Sometime around month nine or ten, the operations team asks for what they describe as "a small enhancement" — perhaps a new approval layer because the business has hired a second tier of managers, perhaps a branch-level view because the company opened another location. The vendor scopes it. It is not small. By month twelve, the owner is in conversation about a Phase 2 that, on closer inspection, is largely a reworking and extension of the same system they finished paying for ten months ago. Each individual decision was reasonable. The cumulative trajectory is the pattern. Our team calls it the project-then-disappear cycle, and once an owner has lived through it once, they recognise it everywhere.

What the cycle actually looks like in a calendar

The early months feel like a finished project: training sessions wrap up, the team adopts the new workflow, dashboards become routine. By mid-year, an external change — a regulatory clarification, a supplier portal upgrade, a customer that suddenly insists on a new invoice format — quietly creates the first crack. By the second half of the year, an internal change — a new branch, a new product line, a new role — creates the second. By the time the system’s first anniversary arrives, the owner is reviewing a Phase 2 proposal that touches the same modules they originally signed for. The calendar never showed this. The contract never named it. But the rhythm is so consistent across SMEs that our consultants can predict the months at which each request will arrive.

Why the Project Model Was Never Built for Software That Has to Grow

Project pricing was not invented for software. It was inherited from industries where the deliverable is, in fact, a finished asset. A building has a design, a budget, a handover date, and a defects liability period; once that period closes, the asset stands on its own. A piece of plant equipment is specified, manufactured, installed, commissioned, and then serviced under a separate maintenance contract. The logic of "specify it once, build it once, hand it over, walk away" maps cleanly onto these worlds because the asset itself does not have to keep changing in response to the business that owns it.

Software, particularly the multi-departmental custom systems that Malaysian SMEs commission, does not behave like any of this. Every regulatory clarification, every approval-matrix revision, every chart-of-accounts restructure, every new customer category, every change in how the operations team prefers to work, is a new requirement that the original contract never imagined and could not have specified. The moment the business that runs the software starts to evolve — which is roughly day one of go-live — the original scope begins ageing. The project model is therefore broken not at the edges but at the centre. It is the wrong shape of contract for the shape of the thing being purchased.

What construction got that software does not get

Construction projects close. The defects liability period ends, the snag list is signed off, and the building stands. The owner does not call the architect every six months to ask for a new room because the business added a department. Software has no such closing moment. There is no defects liability period after which the system stops needing attention, because the system was never sealed off from the business in the first place. The business is constantly pushing change into it from every direction — customers, suppliers, regulators, department heads, staff, owners themselves — and the system has no choice but to absorb those changes or fall behind. Treating it like a building means signing a contract that pretends the changes will not arrive, then absorbing the cost when they inevitably do.

Why Your Vendor Stops Replying to WhatsApp Messages

The hardest part of this pattern for SME owners is the relational element. The senior engineers who built the system, who knew every quirk of the business, who answered every late-night message during go-live, are slowly harder to reach. Messages take days to be returned. Calls are rerouted to a junior team member who is reading the codebase for the first time. The owner reasonably starts to feel forgotten, even abandoned. It would be easy to read this as bad behaviour by the vendor. In our team’s experience, it almost never is. The vendor is responding to the same incentive structure that signed them on in the first place.

That structure is straightforward. Project pricing rewards vendors for closing the next project. Once your system is delivered and the final invoice is paid, every additional hour the senior team spends on your business is an hour that is not closing the next deal. The vendor’s strongest engineers, the ones with the institutional memory of your build, are now allocated to the next client’s go-live deadline. Your account is handed to whoever has bandwidth. That person does not have the same context, does not remember why a particular decision was made, and is solving your problems with a fraction of the visibility the original team had. The slowness is not personal. The thinness of the response is not laziness. It is the predictable output of a pricing model that treats your project as finished and theirs as next.

The hidden cost of vendor churn

The expense most SME owners underestimate is not the next phase invoice itself. It is the cost of context-rebuilding when the relationship with the original vendor cools and a new vendor has to be onboarded to keep the same system alive. Every new vendor must read the codebase, interview the team, retrace the business logic that was obvious to the original builders, and re-learn the integrations that were already working. The owner pays for this learning curve twice when they switch vendors, and a third time when the new vendor eventually drifts the same way. The cumulative cost of churn rarely appears as a line item on any invoice, but it is one of the largest hidden costs of the project-then-disappear cycle — and it lands hardest on the owner who simply wanted the same team to keep looking after the same system.

Where the "Second Payment" Actually Comes From

It helps to break the second payment into the streams it actually arrives through. Across the engagements our consultants have reviewed, the same four buckets recur. Setting them out plainly takes the mystery out of why the owner’s spending never quite finishes:

  • Regulatory updates — e-invoice mandates broaden their scope, BNM publishes a revised guideline, PDPA enforcement tightens around a particular data category, ESG reporting categories evolve, industry-specific regulators introduce new disclosures. Each of these touches the system in ways the original specification could not have anticipated.
  • Master data and configuration drift — the chart of accounts needs restructuring as the business adds revenue lines and cost centres, approval matrices need extending as headcount layers grow, the item master expands as new product categories emerge, the inventory model has to absorb consignment stock or batch tracking that the original setup did not contemplate. Every configuration choice baked in at sign-off ages as the business evolves around it.
  • Internal change — the business opens a new branch, adds a product line, hires a new function, restructures approval limits, splits one role into two. Every change inside the company eventually touches the system, because the system encodes how the company runs.
  • Decay — libraries and frameworks are deprecated, server operating systems reach end-of-support, security patches accumulate, browsers stop supporting older standards. None of this is glamorous, but ignoring it is how a working system becomes an unsupportable one.

None of these streams are in the original contract. None of them are unusual. All of them are inevitable. The honest description is not that the owner is being overcharged for unexpected work; it is that the original contract was written as if the work would never appear, when in fact it was guaranteed to. The second payment is simply the bill for the inevitable, dressed up as a surprise.

What a Retainer-Based Partnership Actually Means

The structural answer to the project-then-disappear cycle is a different shape of contract entirely. A retainer-based partnership replaces the one-off project with an ongoing engagement, in which the same team that built the system continues to own its evolution. From the owner’s point of view, the change is less about the technology and more about the relationship:

  • The same team that built the system keeps building on it. Institutional memory is preserved by contract design, not by goodwill.
  • The cost shape changes from surprise-shaped phase invoices to a predictable monthly engagement that can sit comfortably in the annual budget.
  • When something changes — a regulation, an approval rule, a process — there is someone to call who already knows the system, instead of a new SOW to negotiate from scratch.
  • Regulatory updates, small enhancements, integrations, and bug fixes are absorbed continuously across the relationship rather than billed as fresh projects each time they arrive.
  • The vendor’s incentive is aligned with the long-term health of the system. Their success is measured by stability and continued usefulness, not by closing the next project.

The shift is not cosmetic. It changes who carries the risk of the inevitable. Under project pricing, the owner carries every surprise. Under a retainer-based partnership, the partner carries the responsibility of keeping the system aligned to the business, and the owner carries a predictable cost. This is the model our team designed our IT outsourcing engagement around — because every consulting engagement our consultants have run for Malaysian SMEs eventually reveals the same structural mismatch between project pricing and software reality.

The principle: The right pricing model is the one that matches the shape of the work. Project pricing fits work that finishes. Retainer pricing fits work that keeps living. Custom SME systems do not finish, so the contract should not pretend otherwise.

What Business Owners Get When They Stop Paying Twice

The shift away from the project-then-disappear cycle is best described not as a list of features but as a change in what the owner experiences day to day. The technology underneath may look similar; the ownership experience does not. The most consistent changes our team observes across owners who move into a retainer-based partnership are:

  • The annual IT budget becomes predictable. The owner can plan against a known monthly figure rather than bracing for the next surprise phase invoice.
  • Regulatory updates land without panic. When a new mandate is announced, there is already a team responsible for absorbing it, not a fresh negotiation to start.
  • The owner can plan the business against the system, rather than planning the business around the system’s limitations. New branches, new product lines, and new roles stop being software events.
  • The system grows with the business instead of becoming a constraint on it. The conversation shifts from "what will this cost to change?" to "how soon can we ship it?"
  • The internal team stops being the buffer between the business and an absent vendor. Finance is not chasing the vendor to remodel the chart of accounts each quarter; operations is not improvising around an approval matrix that the new headcount layers outgrew.

These are not technology outcomes. They are ownership outcomes. The same custom system, looked after under a different contract shape, produces a different daily reality for the owner who is responsible for it.

The owner’s reframe: The question is no longer "how much will the next phase cost?" The question becomes "how is the system evolving alongside the business?" That is the conversation a healthy software ownership relationship is supposed to be having.

The Honest Closing

The project-pricing model was not a mistake. It worked, and still works, when the software being purchased is simple, single-purpose, and genuinely one-time. A static informational website, a one-off data migration, a fixed-scope integration with a clearly bounded outcome — these still fit the project shape comfortably, and a retainer would be the wrong instrument for them. Most Malaysian SMEs, however, are no longer buying that kind of software. They are buying multi-departmental ERPs that sit at the centre of how the business runs, integrate with regulators and suppliers and customer-facing systems, and have to evolve continuously alongside the company. For systems of that shape, the model has to catch up to the reality, and the retainer-based partnership is how that catching-up looks in practice.

The owner’s real job is not to pick a vendor. It is to know which shape of work they are actually buying, and to choose the contract shape that matches it deliberately, rather than by default. For some businesses, that means a retainer-based partnership from the start. For others, it means a clean project engagement for a clean project need. What is no longer reasonable is signing a project contract for work that everyone, quietly, knows will never finish, and then paying for the same system twice while pretending to be surprised. Our team’s IT outsourcing model is built around the retainer-based partnership for exactly this reason. For a deeper walk-through of how to choose between project, retainer, or a hybrid approach, the companion piece at project, retainer or hybrid IT spending sets out the decision framework our consultants use with owners considering the question.

Bottom line: Paying for the same custom system twice is not a sign that the owner chose the wrong vendor. It is a sign that the contract shape did not match the work. The fix is structural — a retainer-based partnership that keeps the same team responsible for the same system across its lifespan, so the second payment, and the third, simply stop arriving as surprises.