Common Objections to Custom Software — Answered Honestly

If you have reservations about custom software, you are right to have them.

Custom software projects have a poor reputation, and for good reason. Industry surveys consistently report that 55–75% of large IT projects fail to meet their objectives. Budgets blow out. Timelines slip. Vendors disappear. Code bases turn into unmaintainable spaghetti.

These are not hypothetical risks. They are real. And anyone who dismisses them with a wave of the hand is not being straight with you.

At Sysgraft, we build custom interface layers over existing ERP systems — modern web applications that sit on top of Business Central, Sage 200, OrderWise, and other systems, connected via their public APIs. We have heard every objection in the book, and we take them seriously because most of them are rooted in real experiences.

This page answers each concern directly and honestly. If one of these resonates with you, it is probably for a good reason. Here is how we address it.

“We don’t have the budget.”

This is the most common objection, and it comes in two forms: either the budget genuinely does not exist, or the budget is allocated elsewhere and the ROI of custom software has not been compelling enough to reprioritise it.

Let us address both.

If the budget genuinely does not exist: Custom software starts at around £20,000–£30,000 for a focused scope, delivered in 4–6 weeks. That is not trivial, but it is also not a £300,000 ERP replacement. We offer a discovery sprint for a fixed fee (£2,500–£4,500 depending on scope) that gives you a detailed specification and fixed-price build proposal. If our price does not stack up against the value, we will tell you. Sometimes the answer genuinely is to wait.

If the budget is allocated elsewhere: Consider the cost of doing nothing. That cost is not zero — it is the cumulative productivity loss of your team wrestling with an interface that fights them every day. Exporting data to Excel. Re-keying information. Multiple calls to track order status. Industry estimates put the cost of poor ERP UX at 20–30 minutes per user per day. For a team of 20, that is £30,000–£50,000 a year in lost productivity alone.

The honest truth: If you cannot afford £20,000 to solve a problem that is costing your business more than that per year, the real issue is probably not the budget — it is the lack of a clear business case. That is why we start with a discovery sprint. If the numbers do not stack up, we will be the first to tell you.

“We don’t want another failed project.”

You should not have to. The statistics are genuinely sobering.

The Standish Group’s CHAOS Report has tracked IT project outcomes for decades. Their most recent figures show that only about 35% of projects succeed on time, on budget, and with the promised features. That means roughly two-thirds of projects experience some form of failure — cost overrun, scope reduction, or outright cancellation.

Panorama Consulting puts the figure similarly for ERP implementations specifically: 60% fail to deliver expected benefits. Gartner says 55%.

These numbers exist for a reason. Most IT projects fail because of three things:

1. Unclear scope — the project starts without a firm specification, so it grows and changes as it goes
2. Poor communication — the vendor builds what they think you want, not what you actually need
3. No fixed price — time-and-materials contracts create perverse incentives for the vendor to take longer

Our approach addresses all three:

Discovery sprint first. We spend 3–5 days on-site, observing your team, auditing your ERP’s API, and producing a detailed specification. You sign off on the scope before we write a single line of code. If the scope changes later, we both agree to it in writing — it does not just creep.

Fixed price. Once the scope is agreed, we quote a fixed price. Not an estimate. Not a “ballpark.” A fixed price. If the project takes longer than expected, we absorb the cost. That aligns our incentive with yours: we want to deliver fast, because every extra day costs us, not you.

Weekly check-ins. You see working software every week. Not PowerPoint slides. Not progress reports. Working software. You can course-correct while the cost of change is still zero.

The honest truth: No process can guarantee a project will not fail. But the main reasons projects fail are well understood, and our approach is designed to mitigate each one. If you want references from clients who have been through the process, we will connect you directly.

“We’ve been let down before.”

We hear this often. Sometimes the previous vendor over-promised and under-delivered. Sometimes they disappeared halfway through. Sometimes they delivered working software but then held the client hostage for maintenance. Sometimes they built something that worked initially but became impossible to maintain.

These are legitimate grievances. Here is what we do differently:

IP ownership is yours from go-live. The source code, the documentation, the deployment scripts — all of it transfers to you upon go-live. There is no ongoing licence fee for the software itself. You pay for hosting, maintenance, and feature development as a subscription. If you decide to leave, you take the code with you.

No proprietary frameworks. We build in standard technologies: React, Next.js, TypeScript, PostgreSQL. Your code is not dependent on a Sysgraft runtime, a Sysgraft library, or a Sysgraft hosting platform. Any competent development team can take over the codebase.

Fixed-price contracts. The scope is agreed in the discovery sprint. The price is fixed in the build proposal. There are no surprises halfway through.

We are not a body shop. We do not sell you developer-hours. We sell you a built product. If we quote you £30,000 for a customer portal, that is what you pay — not a penny more, even if we spend more time than we expected.

The honest truth: If you have been let down before, you are right to be sceptical. Ask for client references. Ask to speak to a client who had a problem during their build, and how we handled it. Every project has hiccups; the measure of a vendor is how they deal with them.

“What if your company disappears?”

This is a fair question. Sysgraft is a small company (Curavest Ltd, registered in England and Wales, company number 15433116). We are not Microsoft. We are not Sage. The risk of us ceasing to exist is non-zero, and we will not pretend otherwise.

Here is how we address it:

Code ownership. As stated above, you own the source code from the moment we go live. If Sysgraft disappears tomorrow, you have the full codebase, the deployment scripts, and the documentation. You can host it yourself, hire another agency to maintain it, or do nothing and it continues running as-is.

Standard technologies. We build in React, Next.js, and TypeScript — mainstream technologies with deep talent pools. Your code runs on standard infrastructure (AWS or Azure). There is no Sysgraft-specific runtime or proprietary database. Any UK software agency with React experience can take over.

Code escrow (optional). For clients who want additional protection, we offer a code escrow arrangement. The source code and deployment artefacts are deposited with a third-party escrow agent (typically Solicitors in London). If Sysgraft ceases trading, the escrow agent releases the code to you. This adds approximately £500–£1,000 per year to the subscription cost.

IP transfer on go-live. The contract explicitly states that all intellectual property rights in the built software transfer to you on go-live. It is not optional. It is not an add-on. It is standard.

The honest truth: Most software vendors do not disappear. But enough have that the concern is rational. We structure our contracts so that if we do, you are not stranded. If you want the code escrow option, we can add it to your agreement.

“We’re worried about vendor lock-in.”

Vendor lock-in is a legitimate concern, particularly if you have experienced it with an ERP vendor or an ISV add-on where migrating data costs more than buying another year of licence.

We take a different approach.

The adapter pattern. Every integration with your ERP is isolated in a single adapter layer. If you switch ERP systems, only the adapter needs rewriting. The frontend — the application your team uses every day — does not change at all. The cost of switching ERPs goes from “replace everything” to “replace one module.”

You own the code. As covered above, full IP transfer on go-live. There is no licence fee. No per-seat charge. No ongoing royalty. You are not renting the software; you own it.

Standard tech stack. Our applications are built with mainstream, open-source technologies. No proprietary frameworks. No hidden dependencies.

Full documentation. Every project includes architecture documentation, API endpoint inventory, deployment runbooks, and development environment setup guides. You are never dependent on institutional knowledge held by one person.

Compare this to ISV lock-in: Many ERP add-on vendors charge ongoing licence fees that increase year on year. Their software is often tied to a specific ERP version, forcing upgrade cycles. Their code is typically closed-source and not transferable. Our model is the opposite on every point.

The honest truth: Switching costs are never zero. If you decide to move away from Sysgraft’s maintenance service, you will need to find a developer or agency to take over. But you will have the full codebase, standard documentation, and a mainstream tech stack. You will not be starting from scratch.

“Our ERP vendor says we shouldn’t connect third-party apps.”

We hear this primarily from clients using Business Central, Sage 200, and OrderWise. The ERP vendor’s position is usually that connecting third-party applications voids support, risks data integrity, or introduces security vulnerabilities.

Let us examine the actual position for each:

Microsoft Dynamics 365 Business Central: Microsoft actively promotes and documents the REST API v2.0 as the integration surface. There is no support void — connecting via the API is the intended use case. Microsoft’s own documentation provides guidance on connecting external applications. Your support agreement is not affected by API usage.

Sage 200: Sage publishes a documented REST API and OData endpoint. Connecting via these documented interfaces does not void support. Issues arise only if you modify the Sage database directly or use undocumented integrations. Our approach uses only the public API.

OrderWise: OrderWise provides a documented API surface. They may recommend their own add-on ecosystem for certain integrations, but the public API exists specifically for this purpose.

The contractual reality: ERP vendors sometimes discourage third-party connections because they have their own add-on marketplace, or because their support team wants to reduce variables. That is their commercial prerogative. But the documentation and API access are there by design. If your ERP has a published API, using it is within the intended use of the product.

The honest truth: If your ERP vendor has a specific contractual clause about third-party integrations (rare for standard API access), we should review it together during the discovery sprint. We have done this with several client contracts and have yet to find a genuine showstopper. But we will not ignore a real contractual restriction if one exists.

“We don’t have internal developers to maintain this.”

This is a common concern, and the answer is straightforward: you do not need them.

Our subscription model includes maintenance. The monthly fee covers hosting, security patching, platform updates, bug fixes, and monitoring. You do not need a developer on staff to keep the application running. You do not need to know how to deploy a Next.js application or configure a Redis cache.

Here is what is included:

• Hosting infrastructure — AWS or Azure, UK region, fully managed
• Security patching — all dependencies updated within 7 days of a CVE announcement
• Platform monitoring — uptime monitoring, error tracking, performance alerts
• Bug fixes — defects in the built software are fixed at no additional cost
• ERP API updates — if your ERP’s API changes, the adapter layer is updated accordingly
• SSL certificate management — automated renewal and deployment

If you do want internal involvement — perhaps an IT manager who wants visibility, or a developer who may take over in future — we provide access to the source repository, deployment pipelines, and documentation. But it is not required.

The honest truth: At some point, you will want to make changes to the application. New features. New integrations. Changed workflows. At that point, you have options: you can continue with our development service (included in the subscription for small changes, quoted for larger ones), bring in a third-party agency, or hire a developer. The code is yours. The choice is yours.

“We’re worried about security.”

Security concerns should be taken seriously, particularly when you are connecting an external application to your ERP — your system of record for financials, inventory, and customer data.

Here is how security works in a Sysgraft deployment:

• UK hosting. All infrastructure is hosted in UK-region cloud (Azure UK South or AWS London). Data never leaves the UK. We have a Data Processing Agreement (DPA) in place as standard.
• Authentication. Staff access uses Microsoft Entra ID SSO — your team authenticates with their existing Microsoft 365 credentials. No separate usernames and passwords to manage. Customer portal users authenticate via secure, role-scoped accounts.
• API security. All communication with your ERP uses OAuth 2.0 with short-lived access tokens. No API keys in configuration files. No shared secrets exposed in code.
• Encryption in transit and at rest. HTTPS everywhere. Data at rest is encrypted using AES-256. Backups are encrypted.
• Field-level data scoping. Customer portal users see only their own data — enforced at the API, application, and database layers. A customer logging in cannot accidentally (or deliberately) access another customer’s data.
• Cyber Essentials. We are working toward Cyber Essentials certification. If your procurement requires it, we can align the timeline with your project.

The honest truth: Any time you connect an external application to your ERP, you introduce a new attack surface. We mitigate it at every layer, but we will not tell you the risk is zero — because no software vendor who says that is being honest. During the discovery sprint, we can walk through the full security architecture with your IT team and address specific concerns.

“We’re too busy to take this on.”

This is the objection we hear most from operations directors and warehouse managers. You are already firefighting. The idea of adding a software project to the load feels impossible.

Here is the reality of what we ask from you during a build:

• Discovery sprint (3–5 days): We come to you. We observe your team. We interview key stakeholders. We need approximately 30 minutes to 1 hour per person for interviews, and access to observe workflows. That is it.
• Build phase (4–12 weeks): One weekly check-in meeting, 30 minutes. Review working software. Provide feedback. That is the extent of your time commitment.
• Go-live: One day of light coordination. We handle the deployment.

Total time commitment from your team: approximately 8–12 hours over the entire project. That includes the discovery sprint, weekly check-ins, and go-live.

We do not need a project manager on your side. We do not need a product owner dedicating days per week. We do not need your team to write specifications or create wireframes. That is our job.

The honest truth: If you are genuinely too busy to spare 8 hours over 3 months to solve a problem that is costing your business tens of thousands per year, the issue is probably not the project — it is that the problem has not reached crisis point yet. That is fine. We will be here when it does.

“Our users won’t adopt it.”

User adoption is the silent killer of software projects. You can build a technically perfect application, spend £100,000 on development, and if users do not adopt it, it is worth nothing.

User resistance to new software is almost never about “not wanting to learn.” It is about the new software being worse than the old software for the tasks they actually perform.

Here is how we address it:

On-site observation. Before we design anything, we watch your team do their jobs. We see the workarounds they use. We see the Excel exports. We see the post-it notes on monitors. We design the interface to match how they actually work, not how the process document says they should work.

User involvement in design. During the discovery sprint, we show rough wireframes to the people who will actually use the system. Their feedback shapes the design. We do not design in a vacuum and deliver a finished product without user input.

Familiar interaction patterns. Modern web interfaces built with React follow patterns users already know from consumer software. There is no 3-day training course required. The learning curve is measured in hours, not days.

Minimal training needed. Most of our projects go live with a 1-hour walkthrough for the team. If we have done our job right, that is all that is needed. Users self-discover the rest.

The honest truth: No software has 100% user adoption, and anyone who promises it is selling something. There will always be one or two people who prefer the old system. But if you have involved users in the design, if the interface actually solves their real problems, and if the training burden is measured in hours not days, adoption will take care of itself. We can show you adoption metrics from existing clients.

“We tried Power Apps / low-code and it didn’t work.”

This is increasingly common. Low-code platforms like Microsoft Power Apps, Mendix, and OutSystems promise rapid development without traditional coding. In practice, they work well for simple internal forms and dashboards, but hit hard ceilings for complex business applications.

The typical complaints we hear from clients who have tried low-code:

• Performance degrades as the application grows. A simple sales dashboard that worked with 10 records becomes unusable with 10,000.
• Complex business logic (BOM explosions, multi-tier pricing, inventory allocation rules) is difficult or impossible to express in the low-code platform’s visual programming model.
• User interface limitations mean every screen looks like a low-code screen — generic, boxy, and not tailored to the task.
• Vendor lock-in is severe. Your application is built on a proprietary platform. Migrating off it means starting from scratch.
• Customer-facing portals require capabilities that most low-code platforms do not provide out of the box (custom authentication, branding, responsive design, SEO).

When low-code is the right choice: Internal tools for 5–10 users. Simple approval workflows. Quick prototypes. Basic data entry forms. If that is your use case, low-code is often the right answer and we will tell you so.

When custom code is the right choice: Customer-facing applications. High-volume transactional interfaces. Complex business logic. Performance-sensitive operations. Applications that need to last more than 2–3 years.

The honest truth: We have no inherent bias against low-code. We recommend Power Apps when it is the right fit. But if you have already tried it and hit a ceiling, that ceiling is real. Full-code development does not have that ceiling. The trade-off is that full code takes longer and costs more upfront. We can help you assess which is right for your specific situation.

“We’re waiting until next year.”

Waiting is a valid strategy in some circumstances. If you are mid-way through a major ERP upgrade, or if your business is about to undergo significant restructuring, or if you simply have more pressing priorities, delaying a software project can be the right call.

But consider what happens while you wait.

Every month you delay, the cost of doing nothing accumulates:

• Your team spends another 20–30 hours per month on workarounds and manual processes
• Your customers continue to get slower service because your team cannot find information quickly
• Your ERP vendor releases another version, and the gap between your interface and what is possible widens
• The cost of the project next year will be higher — development rates rise, and the scope may have grown as you identify more pain points

More importantly, most businesses find that the problems they hoped would resolve themselves by next year have not. They have gotten worse. The team has developed more workarounds. The Excel spreadsheet has become the de facto system of record. The data quality has degraded further.

The honest truth: If the timing genuinely is not right, we will tell you. We have told potential clients to wait when their business was in flux or when the ROI case was marginal. But if the pain is real today, it will almost certainly be worse next year. The cost of waiting is not zero — it is the cost of another year of lost productivity, frustrated teams, and missed opportunities.

Summary: Each Objection in One Line

---