Build vs Buy for ERP Extensions: A CTO Decision Guide
build vs buy for ERP extensions and customisations
Also searched as
- should we customize our ERP or buy an add-on
- ERP customization vs ISV solution decision
- build custom ERP extension vs use marketplace app
- ERP side-by-side extension strategy
Short answer
Work down a ladder: configure the standard product, then buy a supported ISV add-on, then build outside the ERP core against its APIs, and only then modify in the core. Each step down raises upgrade risk and lifetime cost. Build only where the capability is a genuine differentiator or no product fits, and keep the code upgrade-safe and owned.
Applies to: Any ERP: NetSuite (SuiteApps, SuiteScript), SyteLine (IDOs, form extensions, event handlers), SAP S/4HANA (clean core, BTP side-by-side), Dynamics 365 F&O (extensions, Power Platform), Epicor, M3, LN.
How to decide build vs buy for an extension
- 1Write the requirement as a business outcome and ask whether standard configuration, a workflow or a report can deliver it. Many gaps are configuration gaps.
- 2Check the vendor roadmap and the next release notes. Building a feature the vendor ships in twelve months creates throwaway work.
- 3Search the vendor marketplace and ISV partners (NetSuite SuiteApps, SAP Store, AppSource, Infor Marketplace) and score candidates on fit, support, update cadence and references you can call.
- 4If nothing fits, prefer side-by-side extensions that use public APIs and events over modifications to core objects, such as SAP BTP extensions or an external service calling NetSuite or SyteLine APIs.
- 5Estimate lifetime cost for each option over five years: licence, build, testing on each ERP upgrade, support, key-person risk and exit cost.
- 6Define ownership before building: source control, automated tests, documentation, a named maintainer and a deprecation date or review cycle.
- 7Gate every custom object with an architecture review that records why standard and bought options were rejected.
- 8Revisit annually: retire extensions the standard product now covers and re-evaluate any ISV add-on whose vendor has gone quiet.
The ladder from least to most risky
Configuration is the cheapest and the safest because the vendor upgrades it with the product. This includes workflow, approval rules, custom fields, saved searches and standard report designers. Exhaust this rung honestly before moving on, since consultants often overlook configurable options.
A bought ISV add-on shifts build and maintenance to someone else, but you inherit their roadmap and viability. Check that it is certified for your ERP version, how quickly it tracked the last two releases, and what happens to your data if the vendor is acquired or exits. Per-user or per-transaction pricing can also exceed a small custom build over several years.
A side-by-side build keeps your code outside the ERP core and talks to it through supported APIs and events. This is the strategy behind SAP's clean core guidance and the extension models in Dynamics 365. It is the best build option for most differentiating needs because upgrades rarely break it. In-core modification of vendor code or tables is the last resort, with the highest upgrade cost.
Total cost of ownership, not build cost
The build estimate is typically the smallest part of an extension's cost. Over five years, testing against each ERP update, fixing breakage, handling security changes, onboarding new maintainers and answering support questions usually exceeds the initial build. A common planning heuristic is that annual maintenance is a meaningful fraction of the initial build, so budget for it rather than treating the project as finished at go-live.
Key-person risk is the hidden item. An extension written by one contractor in a niche language such as SyteLine form scripting, SuiteScript or ABAP, with no tests, is a liability when that person leaves. Require documentation, source control and a second person who can run the deployment.
Include exit cost. A bought add-on that stores data in its own tables can be hard to leave. A custom extension tied to deprecated interfaces needs a rewrite. Prefer options that keep data in standard ERP objects and use documented interfaces.
5-year TCO comparison (fill in per option)
Year 0: licence/setup + build + integration + testing
Years 1-5: subscription or maintenance + upgrade regression testing
+ support effort + enhancement requests
Risk adders: vendor viability, key-person dependence, exit cost
Benefit: hours saved, error cost avoided, revenue enabled (with owner sign-off)When building is the right call
Build when the capability encodes how you win: a proprietary scheduling heuristic, a customer-specific compliance workflow, a configurator tied to your product rules. Generic needs such as expense capture or basic e-invoicing rarely justify custom code, because the market has mature products.
Build also when integration glue is the product, such as connecting a plant-floor system to the ERP in a way no ISV supports. Even then, keep business rules in the ERP where you can, and keep the glue thin, versioned and tested.
AI-assisted development changes the build side of the equation but not the maintenance side. Assistants can draft scripts, reports and integration code faster, which lowers initial cost and makes small extensions more attractive. They do not remove upgrade testing, ownership or review, so apply the same governance to generated code as to hand-written code.
Common pitfalls
- !Comparing a licence quote against build effort only. The five-year maintenance and upgrade testing cost decides the answer.
- !Customising core objects because it looked quicker. Each ERP upgrade then needs regression testing and merge work.
- !Buying an add-on from a vendor you did not check for update cadence. A lagging ISV can block your ERP upgrade.
- !Building without tests or source control. The extension becomes unmaintainable the moment its author leaves.
- !Keeping extensions forever. Review annually and retire those the standard product now covers.
- !Skipping the architecture review for small scripts. Many small unreviewed scripts add up to the real upgrade burden.
How an ERP-grounded AI assistant handles this
AI can reduce the cost of the build option for reports, scripts and integrations, and help audit what you already have. SyteRay provides agents and accelerators for SyteLine customisation, reports and upgrades, while ERPray can answer questions about what an extension touches by querying live ERP data. Generated code still needs the same review, tests and ownership as any other extension.
Frequently asked questions
What does clean core mean in practice?
Clean core is SAP's guidance to keep the ERP core close to standard and place custom logic in side-by-side extensions that use released APIs and events. The aim is to make upgrades routine. The same idea applies to other ERPs even where they use different names.
Is a marketplace add-on always cheaper than building?
No. Add-ons avoid build effort but charge recurring fees, sometimes per user or per transaction, and you depend on the vendor keeping pace with ERP releases. For a narrow need with few users, a small, well-tested custom extension can cost less over five years.
How do I stop customisations from blocking upgrades?
Prefer side-by-side extensions using supported APIs, keep an inventory of every custom object, write automated regression tests, and run them against each sandbox release before upgrading. Retire extensions the standard product now covers. An inventory with owners makes impact analysis fast.
Can AI coding assistants replace ERP developers?
They speed up drafting scripts, reports and integration code, but they do not replace ERP knowledge of data models, security, period rules and upgrade behaviour. Treat their output as a draft that an ERP-aware developer reviews, tests and owns.
Related
ERP Integration Architecture: API vs iPaaS vs ETL
Choose by what the data does, not by tool preference. Use the ERP's own API (or its native bus) for transactional writes that must be validated by ERP business logic, ETL or change data capture for bulk analytical reads, and an iPaaS when you have many endpoints, need monitoring and retries, and lack the staff to run your own middleware. Most real estates need two of the three.
CIO briefingHow to Securely Give an LLM Access to ERP Data
Treat the LLM as an untrusted component. Give it read-only access through a dedicated, least-privilege path that enforces the asking user's ERP permissions, validate and log every query it generates, require human approval for any write, and decide deliberately where the model runs. Security comes from the architecture around the model, not from the prompt.
CIO briefingEvent-Driven ERP Integration: Architecture That Holds Up
Use events when several systems must react to ERP changes quickly and you want to stop polling. Get events from the ERP's native mechanism where one exists, otherwise from change data capture, and design every consumer to be idempotent and tolerant of reordering. Keep the ERP as the system of record and treat events as notifications, not as the ledger.
How-toHow to Run an ERP User Access Review (Quarterly Checklist)
An ERP user access review is a recurring control where system owners confirm that every active user, role and privileged permission is still justified. Extract users and roles from the ERP itself, join them to HR status, send each business owner a scoped list to certify or revoke, record the decisions, and execute the removals with ticket evidence.
How-toHow to Test ERP Backup and Disaster Recovery
A backup is only proven when you have restored it and a user has transacted in the restored system. Define RTO and RPO with the business, restore the full ERP stack (database, application, integrations, attachments, secrets) to an isolated environment, run a scripted smoke test, time every step, and record gaps as action items.
How-toERP Patching Cadence: How Often Should You Patch?
Patch the ERP stack in layers on different clocks: operating system and database monthly or quarterly, ERP vendor cumulative updates quarterly or semi-annually, and security fixes on an emergency path measured in days. Test every patch in a sandbox refreshed from production, with a scripted regression and a tested rollback.
AI for ERPAI for Infor SyteLine and CloudSuite Industrial
Add grounded AI to Infor SyteLine or CloudSuite Industrial: natural-language answers, agents over IDOs and ION, on-prem or CloudSuite deployment.
AI for ERPAI for Legacy Baan IV/V: Capture the Knowledge Before It Walks Out the Door
Use AI to capture knowledge from ageing Baan IV/V systems, document undocumented customisations, and de-risk a future migration to LN or CloudSuite.
Stuck on ERP extensions (vendor-neutral)?
Talk to engineers who work inside ERP extensions (vendor-neutral) every week, and who build private AI that answers these questions from your own ERP data.