The Risks of Custom ERP Software — An Honest Assessment

If you are evaluating custom ERP software, you have probably heard the horror stories. The six-figure project that never shipped. The shiny platform nobody uses. The development partner that went dark six months after go-live. The codebase so tangled that even a small change costs thousands.

Some of these stories are exaggerated. Many are not. Custom software carries genuine risks, and anyone who tells you otherwise is selling something.

This article is an honest assessment of those risks — the real ones, not the straw men. We run through each risk in detail, explain when it applies, and show you what to look for in a partner to minimise it. We also cover when the risks are worth taking, and when you should walk away.

We are Sysgraft. We build custom interface layers over existing ERP systems. You would expect us to be cheerleaders for custom software. We are not. We turn down work when the risk profile does not suit the client. Read this, then decide for yourself.

Risk 1: Vendor Dependency

You hire a development partner to build your custom ERP interface. They build it. It works. Your team loves it. And then the development partner goes out of business, gets acquired by a company that changes everything, or simply decides ERP interfaces are no longer their focus.

Now you have a codebase that nobody understands, running on infrastructure that only they managed, with no documentation. You are stuck.

This is the single most common fear about custom software, and it is not irrational. The UK has over 180,000 software development companies. A significant fraction will not exist in five years. If you have bet your operations on a tool that only one team can maintain, you have a problem.

Mitigation

• Intellectual property transfer. You own the source code from day one. Full stop. No licence restrictions, no “we retain the right to reuse components.” The code is yours.
• Source code escrow. The code is deposited with an independent escrow agent (such as NCC Group or Escode). If the vendor ceases trading, you get the code. This is standard practice in enterprise software and should be non-negotiable.
• Standard technology choices. If the application is built on React, Next.js, TypeScript, and Postgres, you can find developers anywhere to maintain it. If it is built on a proprietary framework that only the vendor knows, you cannot. Insist on mainstream, well-documented technologies.
• Comprehensive documentation. Architecture decisions, deployment runbooks, API integration details — all documented before go-live. Not as an afterthought, but as a deliverable.

---

Risk 2: Maintenance Burden

Software is not a one-time asset. It needs ongoing work: security patches, dependency updates, API compatibility fixes, browser updates, performance optimisation. A custom application built today will need attention every quarter for as long as it is in use.

Many organisations underestimate this. They budget for the build but not the upkeep. Two years later, the application is running on outdated dependencies, security patches are piling up, and the cost of catching up is eye-watering.

Mitigation

• Maintenance included in a subscription, not billed ad-hoc. If you pay for maintenance separately, it is the first thing cut when budgets tighten — and the application degrades. A subscription model forces both sides to keep the software current.
• Automated dependency scanning. Dependabot or similar tools should alert the team to outdated packages before they become critical.
• Quarterly maintenance cycles. Minor patches every three months, with a defined process for emergency fixes.

At Sysgraft, maintenance is part of our monthly subscription. We do not charge extra for keeping your application secure and up to date. This aligns our incentives with yours — we only get paid if the software continues to deliver value.

---

Risk 3: Technical Debt

Not all code is created equal. Rushed development, tight deadlines, and inexperienced developers produce code that works today but is brittle tomorrow. Every change becomes harder. Every new feature requires untangling the previous mess. Eventually, the codebase becomes so costly to maintain that a rewrite is cheaper than continuing.

This is technical debt. It is invisible to non-technical stakeholders until the bills come due.

Mitigation

• Written code standards. ESLint configuration, Prettier formatting, strict TypeScript mode, consistent patterns. Code should read like a single person wrote it, even when a team did.
• Mandatory code reviews. Every pull request reviewed by at least one other developer. Not a rubber stamp — a genuine review with comments, questions, and sometimes rejections.
• Modern frameworks. React and Next.js have been battle-tested at enormous scale (Meta, Vercel, countless enterprises). Their conventions are well understood. A developer joining a project for the first time can be productive within days, not weeks.
• Automated testing. Unit tests, integration tests, end-to-end tests. Tests are not optional. They are the safety net that lets you change code without fear.

---

Risk 4: Scope Creep

The project starts with a clear scope: build a dashboard for the sales team. Then the warehouse manager hears about it and wants pick lists. Then finance wants reporting. Then the MD wants a mobile version. Before you know it, the project has doubled in scope and the budget has tripled.

Scope creep is the biggest cause of custom software project failure. The “while we are at it” conversations that seem harmless in a meeting add months and hundreds of thousands of pounds to a project.

Mitigation

• Fixed-price contracting, not time and materials. A fixed price forces both sides to agree on scope before work begins. Time-and-materials projects have no natural brake on scope expansion.
• Discovery sprint before the build. A paid, focused engagement (3–5 days) to define scope, map workflows, audit APIs, and produce a fixed-price proposal. This is not a sales activity — it is genuine discovery. At Sysgraft, this sprint frequently reveals that a client’s real need is simpler than they thought, which reduces the build price.
• Strict change control. Once the build price is agreed, any new feature goes through a formal change request process with a separate price. No exceptions. Small items that genuinely improve usability can be included if they do not affect timeline; everything else waits for a subsequent phase.
• Phase-based delivery. Deliver a working product early, then add features in defined phases. This prevents the project from becoming a monolithic “big bang” release that never ships.

---

Risk 5: Poor User Experience

This risk is often overlooked because it is not technical. But it is the one that kills adoption faster than any other. If the interface is clunky, confusing, or unintuitive, your team will not use it. They will go back to Excel, back to workarounds, back to the very behaviours the software was meant to eliminate.

We have seen beautifully engineered backends fail because the frontend was designed by developers for developers. Data tables everywhere, no logical flow, too many options, too little guidance.

Mitigation

• On-site observation, not remote requirements gathering. You cannot design a good interface from a spec document. Someone needs to watch your team do their actual jobs — not how the process manual says they work, but how they really work. The workarounds, the sticky notes, the spreadsheets. That is where the real requirements live.
• User involvement throughout the build. Real users (not their managers) should see wireframes, test prototypes, and provide feedback. Not in a workshop once, but repeatedly through the build cycle.
• Task-oriented design, not function-oriented. Instead of “Sales Order screen” (a function), design for “Check order status for a customer who is on the phone” (a task). The interface should minimise clicks, prioritise the information the user needs at that moment, and hide everything else until it is needed.
• Mobile-first where appropriate. If warehouse or field staff will use the application, design for mobile first. A responsive desktop port from a mobile design is far better than a desktop app that technically works on a phone.

---

Risk 6: Integration Failures

Your custom application connects to your ERP via API. That API is maintained by the ERP vendor. When the vendor updates the API — deprecating endpoints, changing response formats, altering authentication requirements — your custom application can break.

This is not hypothetical. Microsoft, Sage, and other ERP vendors publish breaking API changes in their release notes. If you are not monitoring those changes and testing against them, you will discover the breakage when a user reports an error — not before.

Mitigation

• Adapter pattern. The integration with your ERP is isolated in a dedicated adapter layer, not scattered throughout the application code. When the ERP API changes, only the adapter needs updating. The frontend does not change at all.
• API version monitoring. Someone (or something) should watch the vendor’s API changelog and test against new versions before they go live. This can be automated for major vendors.
• Graceful degradation. If the ERP is unreachable, the interface should not crash. It should show a clear message, cache essential data where appropriate, and queue write operations for retry.
• Staging environment. All API integration changes should be tested against a sandbox or staging environment before reaching production.

---

Risk 7: Security Vulnerabilities

Every line of custom code is a potential attack vector. SQL injection, cross-site scripting, insecure authentication, exposed API keys — these are not theoretical. The UK’s National Cyber Security Centre reports that web application vulnerabilities are among the most commonly exploited attack surfaces.

When your custom application connects to your ERP, it is handling your most sensitive business data: customer information, financial records, pricing data, supply chain details. A breach is not just embarrassing — it could put you out of business.

Mitigation

• UK hosting. All application infrastructure hosted in UK-region cloud (Azure UK South or AWS London). Data never leaves UK jurisdiction without explicit contractual provision.
• Microsoft Entra ID (formerly Azure AD) for authentication. Your team authenticates with their existing Microsoft 365 credentials. No separate username/password database for attackers to steal. OAuth 2.0 with short-lived tokens for API calls.
• OAuth 2.0 client credentials flow for service-to-service communication. No long-lived API keys stored in configuration files.
• Data Processing Agreement (DPA). Your vendor must sign a DPA that complies with UK GDPR. This is not optional.
• Regular penetration testing. Independent, third-party penetration tests at least annually. The vendor should share the results (or a summary) with you.
• OWASP Top 10 compliance. The application should be built against OWASP’s latest secure coding guidelines. This should be part of the development standards, not an afterthought.

---

Risk 8: No Out-of-Hours Support

Your ERP does not stop at 5pm. If your warehouse runs a night shift, or a customer in a different time zone needs an urgent order, or a system failure happens at 2am on Saturday, who do you call?

With packaged ERP software, you usually have a support contract. With custom software from a small team, you often do not. You are left waiting until Monday morning, or until the developer wakes up and checks their email.

This is a legitimate concern. Small development teams cannot provide a 24/7 call centre. But they can provide a structured, predictable support arrangement that covers most scenarios.

Mitigation

• Defined SLA. Response time commitments for different severity levels. For example: critical (system down) — 4-hour response, 8-hour resolution commitment during business hours; major (feature broken but workaround exists) — next business day; minor — within one week.
• Business hours support with escalation. Support available during your operating hours (typically 9:00–17:30 UK time, Monday to Friday), with an escalation process for genuinely critical out-of-hours issues. The escalation does not need to be instant — but it needs to be defined and reliable.
• Runbook documentation. Your internal IT team should have a runbook that explains how to restart the application, check logs, and perform basic troubleshooting without involving the vendor.

---

Are the Risks Worth Taking? A Decision Framework

Custom ERP software is not right for every situation. Here is a framework to help you evaluate whether the risks are worth it for your organisation.

Custom software is probably the right call if:

• Your current ERP interface is causing measurable productivity loss — minutes per transaction, delays in order processing, errors from manual data entry
• You have tried configuring your existing ERP and hit the limits of what it can do
• You need a customer-facing portal that integrates with your ERP in real time
• Your team has unique workflows that packaged software cannot support without extensive customisation anyway
• The cost of the custom build is less than 20–30% of the cost of replacing your ERP, and the interface layer solves 80% of the problem

Custom software is probably not the right call if:

• Your current ERP processes are largely standard and your team is broadly satisfied with the interface
• You are planning to replace your ERP within 12–18 months anyway
• You have no budget or appetite for ongoing maintenance costs
• Your organisation cannot commit to being actively involved in the design process
• The vendor cannot demonstrate clear mitigations for the risks above

The “interface layer” option changes the calculus

An interface layer (what Sysgraft builds) sits between your team and your existing ERP, rather than replacing it. This significantly reduces several of the risks above:

• Integration risk is lower because the interface connects to the ERP via its published API, with no database access or core customisation
• Vendor dependency is easier to manage because the interface layer is smaller and more standardised than a full ERP replacement
• Technical debt is contained within the interface layer — if the code degrades, your ERP data is unaffected
• Scope creep is easier to control because the ERP remains the system of record; the interface layer only changes how users interact with data, not the data itself

This is not to say an interface layer is risk-free — the risks described in this article still apply. But the magnitude is smaller, and the mitigations are more achievable.

---

Mitigation Checklist: What to Look for in a Partner

When evaluating a custom software vendor, use this checklist to assess how seriously they take risk mitigation. A good partner will welcome these questions. A bad one will deflect them.

Risk	What to ask	Red flag
Vendor dependency	"Who owns the IP? Is code escrow available? What tech stack do you use?"	"We licence the code to you" — you must own it
Maintenance burden	"How is maintenance priced? What is included? What is excluded?"	Ad-hoc hourly maintenance with no cap
Technical debt	"What are your code standards? Do you do code reviews? Testing?"	"We trust our developers" — no formal process
Scope creep	"Fixed price or time & materials? What is your change control process?"	"We will estimate as we go"
Poor UX	"How do you design interfaces? Do you observe users? How many iterations?"	"We have a standard template we use"
Integration failures	"How do you handle API version changes? Is there an adapter layer?"	"We call the API directly from the UI"
Security vulnerabilities	"Where is hosting? What auth do you use? Pen testing? DPA?"	"We use shared hosting" or "we do not have a DPA"
No support	"What is your SLA? Out-of-hours coverage? Escalation process?"	"We are always available on Slack" — not a guarantee

---

Frequently Asked Questions

1. Is custom ERP software always more expensive than packaged software?

Over the short term, yes. The upfront build cost of custom software is typically higher than buying a licence for packaged software. Over the long term (5+ years), the picture is more nuanced. Custom software eliminates ongoing licence fees for features you do not use, reduces workaround costs, and can be more efficient for your specific workflows. But it also carries ongoing maintenance costs that packaged software bundles into its licence fee. Run a total-cost-of-ownership calculation for both options before deciding.

2. What happens if my custom software vendor goes out of business?

If you have followed the mitigations above — IP ownership, source code escrow, standard technology, documentation — you can take the code to another development team. The transition will not be painless, but it is manageable. If you have not taken those precautions, you are in a difficult position. This is why code escrow and IP transfer should be in your contract from day one, not something you negotiate later.

3. How long does a custom ERP interface take to build?

For an interface layer (not a full ERP replacement), a typical first phase takes 4–12 weeks from discovery sprint to go-live. A staff dashboard can ship in 4–6 weeks. A customer portal with read-only access takes 6–8 weeks. A full platform with write-back and complex workflows takes 10–12 weeks. A full ERP replacement, by contrast, takes 9–18 months.

4. Can’t I just configure my existing ERP to get the interface I need?

It depends on your ERP and what you need. Many modern ERPs offer customisation options: personalised role centres, custom pages, Power Apps integration. These are worth exploring first. They are cheaper and lower risk than custom software. The limitation is that you can only go as far as the platform’s configuration surface allows. If you need a customer-facing portal with complex authentication, real-time data, and a mobile-first design, you will hit those limits quickly.

5. How do I know if a vendor is any good before I commit?

Ask for references from clients with similar projects. Speak to those references directly — not via the vendor. Ask specifically about delivery timelines, budget adherence, post-launch support, and what went wrong. A good vendor will have happy clients who are willing to talk. A vendor without references is a risk.

6. What is the most common mistake companies make with custom ERP software?

We see two tied for first place. One: skipping the discovery phase and going straight into build with an incomplete understanding of the requirements. Two: treating custom software as a one-time project rather than an ongoing relationship with maintenance and evolution built in. Both mistakes are avoidable with the right process and the right partner.

---