# Build vs Buy for ERP Extensions: A CTO Decision Guide > Source: https://netray.co/erp-help/cto-build-vs-buy-erp-extensions > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## 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. ## Kind cio ## System it-leadership ## Erp ERP extensions (vendor-neutral) ## Module Extensions and Customisation Strategy ## Query build vs buy for ERP extensions and customisations ## Alternate Queries - 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 ## 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. ## Steps ### How to decide build vs buy for an extension **Items:** - Write the requirement as a business outcome and ask whether standard configuration, a workflow or a report can deliver it. Many gaps are configuration gaps. - Check the vendor roadmap and the next release notes. Building a feature the vendor ships in twelve months creates throwaway work. - Search 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. - If 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. - Estimate lifetime cost for each option over five years: licence, build, testing on each ERP upgrade, support, key-person risk and exit cost. - Define ownership before building: source control, automated tests, documentation, a named maintainer and a deprecation date or review cycle. - Gate every custom object with an architecture review that records why standard and bought options were rejected. - Revisit annually: retire extensions the standard product now covers and re-evaluate any ISV add-on whose vendor has gone quiet. ## Sections ### The ladder from least to most risky **Body:** 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 **Body:** 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. **Code:** 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 **Body:** 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. ## 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. ## Ai Angle 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. ## Faq ### What does clean core mean in practice? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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. ## Search terms build vs buy ERP extensions, ERP customization strategy, ERP clean core, ISV add-on vs custom development, ERP extension TCO, side-by-side extension ERP, ERP customization upgrade risk, SuiteApp vs SuiteScript custom, ERP technical debt, ERP extension governance --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json