24 reasons Malaysian businesses change their software vendor

Where does this list come from?

The list combines what business owners tell Macoin when they ask us to look at an existing app, website or system with public reports and official rules. We found no Malaysian survey that ranks why companies leave a developer, so the 24 signs are grouped by type and are not ranked.

Slow delivery, slow follow-up and no response are the complaints we hear most. Clients have moved to Macoin from other vendors for these reasons, and owners increasingly describe AI-built projects that were left half finished. Those are our own observations, not survey results.

Where a sign has outside evidence, we name the source and its limits. Most of that evidence is international, and some of it comes from security companies that sell related services. Read each figure as a sign of the risk, not as a measurement of Malaysian projects. One bad week is not on this list: each sign describes a repeated pattern.

Which delivery problems make owners leave a vendor?

Owners leave when dates keep moving without explanation, replies take days, and nobody technical can be reached. The cost is rarely one late release. It is the loss of any reliable date to plan staff, marketing or a launch around. Late projects are common, so a pattern of unexplained delay is the warning sign.

Late delivery is common across the industry. Standish Group's CHAOS Report 2020, as summarised by OpenCommons, classed 31% of projects as successful, 50% as challenged and 19% as failed. Those figures are international and cover projects of every size, so they say little about any one vendor. What separates a healthy project is whether the vendor explains a delay before the date passes and gives a new date you can check.

• 1. Deadlines keep movingDates slip more than once, and each new date arrives without a reason or a revised plan.
• 2. Follow-up is slowSimple questions take days to answer, and you are the one who has to chase every time.
• 3. Messages stop being answeredReplies stop after the deposit, or after launch, and the vendor reappears only when an invoice is due.
• 4. You can only reach salesThe person who sold the project cannot answer technical questions, and you never meet the developer.
• 5. Charges appear outside the quotationWork you assumed was included returns as an extra, because the scope was never written clearly.
• 6. The project stays almost doneIt has been nearly finished for months, and you still cannot see a version running that you can test.

When does poor quality become a reason to switch?

Quality becomes a reason to switch when each fix creates a new fault, real use breaks what the demo showed, or small changes are quoted like rebuilds. These are signs that the system is hard to change safely. The cost then falls on every future feature, and not only on the current bug list.

McKinsey calls this tech debt. In a 2020 survey of 50 CIOs at large financial services and technology companies, respondents estimated tech debt at 20 to 40 percent of the value of their technology estate. They also said 10 to 20 percent of the budget for new products was diverted to resolving it. A small business has far smaller numbers, but the mechanism is the same: money meant for new features goes to working around old decisions.

A system that cannot connect to something the business needs is often the moment owners act. LHDN e-Invoice, payment and WhatsApp connections all depend on a backend someone can change. Our e-Invoice readiness checker covers the phase dates by turnover.

• 7. Old bugs keep returningA fix in one screen breaks another, which usually means there is no repeatable test before release.
• 8. The demo works, real use does notThe system behaved in a meeting but fails with real data, real staff or several people at once.
• 9. It slows down as you growPages and reports get slower as customers and records increase, and nobody can explain why.
• 10. Small changes are quoted like rebuildsA new field or report costs far more than expected, because one change touches too many places.
• 11. New integrations are refusedThe vendor says e-Invoice, a payment gateway or an accounting link cannot be added to what they built.

What ownership problems trap a business with one vendor?

A business is trapped when the vendor holds the source code, the domain, the hosting or the app store accounts, and only one person understands the system. Leaving then means rebuilding. Read your contract before assuming you own anything, because paying for software does not always settle who owns the code.

Ask for a written list of every account and who controls it: domain, DNS, hosting, database, source repository, Apple Developer, Google Play, payment gateway and analytics. If the answer takes a long time to arrive, that delay is useful information. For apps, our handover guide lists what to request.

Macoin's own terms keep materials as ours until final payment. On full payment you receive the source code, the documentation and the deployment setup, with no recurring licence for core functionality you paid us to build. Ask any vendor to state its position just as plainly, and get legal advice if a dispute has already started.

• 12. The vendor keeps the source codeYou paid for a system but have no copy of the code, or the contract does not mention it.
• 13. Accounts are in the vendor's nameThe domain, hosting or app store listing belongs to the vendor, so leaving could take your product offline.
• 14. Only one person understands itThere is no documentation, and the system depends on one developer staying available.
• 15. You pay rent on what you commissionedRecurring licence fees cover functionality you paid to build, and the contract has no exit terms.

Which security gaps should worry a business owner?

Worry if nobody can tell you who can see which records, whether a backup has ever been restored, or what happens after a breach. Under Malaysia's PDPA, a data controller must notify the Commissioner within 72 hours of a notifiable breach, so a vendor who cannot answer leaves you exposed.

The breach notification rules took effect on 1 June 2025. DLA Piper's summary of the guideline says the Commissioner must be told as soon as practicable and within 72 hours, and affected people within seven days of that notice, where a breach causes or is likely to cause significant harm. The controller must also require its processor by contract to report breaches promptly and to assist. If your vendor hosts your customer data, check that your contract says so.

MyCERT recorded 195 data breach reports in the first quarter of 2025, up from 151 in the previous quarter, as reported by The Star. This is general information, not legal advice. Our PDPA guide explains what the amendments mean for business systems.

• 16. Nobody can explain access rightsStaff and customers may be able to see records they should not, and no one has checked.
• 17. Backups are unprovenBackups may exist, but nobody has restored one or can say how much data you would lose.
• 18. There is no breach planThe vendor cannot say how it would detect an incident, inform you or help you meet the PDPA deadlines.

Why are AI-built apps a new reason to change vendor?

AI tools build a working demo quickly, but owners often find the last stretch is missing: security controls, proper data rules, testing and a safe release process. The risk grows when nobody on the project can read the code. A vendor who uses AI is fine. A vendor who cannot check its output is the problem.

Tenzai asked five AI coding agents to build the same three apps, and SecurityWeek reported 69 vulnerabilities across the 15 results, including critical ones. The tools avoided exploitable SQL injection and cross-site scripting. They were weak on authorization logic and business rules, and in almost all cases they did not attempt security controls that were not requested. Tenzai sells security testing, so read it as one test with a commercial interest.

Our guide to AI-built apps covers what to check before real customers use one.

• 19. The AI build stalled near the endThe prototype impressed everyone, but login, payments, roles or deployment were never finished.
• 20. Keys or data are exposedSecret keys sit in the code that browsers download, or database rules let outsiders read records.
• 21. Every AI fix breaks something elseEach prompt solves one problem and creates another, and nobody can review the change.
• 22. The AI can reach live dataA tool or agent has direct access to production, with no separate test environment or tested restore.

What pushes mobile app and landing page owners to switch?

Mobile app owners switch when the app falls behind store rules and the vendor has gone quiet. Landing page owners switch when pages load slowly, forms fail or nobody can show where leads came from. Both problems can stay invisible for months, because existing users and the owner's own phone may not show them.

Stores keep moving. Google Play says new apps and updates must target Android 16 (API level 36) from 31 August 2026, and existing apps must target at least Android 15 (API level 35) to stay available to new users on newer Android versions. Existing users keep the app, which is why owners often miss the problem. Apple says apps not updated for three years, with extremely few downloads over a rolling 12 months, can be flagged for removal, with 90 days to submit an update. Apps that crash on launch are removed immediately.

Speed affects revenue on landing pages. On Google's web.dev case studies page, Vodafone Italy reports 8% more sales after improving Largest Contentful Paint by 31%. That is one large company's result, so treat it as direction and not a forecast. Test your own page on a mid-range phone over mobile data, and submit the form yourself.

• 23. The app is falling behind store rulesNobody has updated the app, and you may not know who holds the store accounts or signing keys.
• 24. The landing page leaks leadsIt loads slowly on phones, the form fails silently or tracking cannot show which ads produce enquiries.

Should you fix the relationship, change vendor or rebuild?

Try fixing the relationship first if the code is yours and the vendor still responds. Change vendor if replies have stopped or trust is gone. Rebuild only after a review shows the existing system cannot support what the business needs. A rewrite is expensive, and it can lose rules that the old system handled correctly.

Send one written message listing the problems, what you need and a date. A vendor worth keeping will reply with a plan. Many relationships recover at this point, and recovery costs less than any move.

If you do move, keep working features where they are sound. The usual options are to stabilise and continue, replace one module at a time, or rebuild. Ask for a review that explains the risks of each, and be wary of any new vendor who recommends a rebuild before reading the code.

How do you change software vendor without losing your system?

Secure access first, then bring in the new team. Collect the code, the accounts and a full backup before you announce anything, and keep paying for hosting. Then get a technical review, agree a written scope, and test one release before the outgoing vendor's access is removed. Order matters, because lost access is hard to recover.

Do these steps in order. Remove the old vendor's access only after the new team has deployed successfully, and rotate every password and API key once they have left. Review your contract and any money still owed first, because payment disputes are the most common reason a handover stalls.

• Step 1: Read the contractCheck ownership, notice period, outstanding payments and what the vendor must hand over.
• Step 2: List every accountDomain, hosting, database, code repository, app stores, payment gateway and email service.
• Step 3: Secure a copyGet the current code and a database backup, and confirm that the backup can be restored.
• Step 4: Get a reviewAsk the new team to build and run the system from what you hold, then report the risks.
• Step 5: Agree a written scopeSeparate urgent repairs, maintenance and new features, with acceptance checks for each.
• Step 6: Release once, then close accessAfter one tested release, remove the old vendor's access and rotate all credentials.

Why do businesses in Puchong move to Macoin?

Macoin is a registered Malaysian software company with an office in Bandar Puteri, Puchong, where owners can meet the team. We reply to enquiries within one business day, quote against a written scope and hand over source code on full payment. We price for Malaysian businesses and build systems meant for daily commercial use.

We cannot name the clients who moved to us, but you can check what is public: our SSM registration (1545756-H), our team page, and live products such as the Jian Pilates app on the App Store and Google Play.

We take over existing systems after reviewing the code and setup, and we do not promise that every codebase can be supported. WhatsApp us what you have and what went wrong. Remove passwords and customer data from anything you send. If your current vendor is still the better option, we will tell you.