Build, buy or integrate: deciding on custom business software

Most operations leaders do not set out to commission software. They start with a problem: quotes take three days because pricing lives in a spreadsheet, onboarding a customer takes five logins, or finance rekeys orders from the CRM into the ERP every morning. Whether to buy a product, connect the systems already in place or build something new is the second question, and it is easy to answer it by habit rather than by evidence. This guide sets out the options, the criteria that should decide between them, and the mistakes that make each option expensive.

What are the three options: buy, integrate or build?

Every software decision for a business process sits somewhere on a spectrum. At one end you adopt a product as it comes. At the other you commission code that exists only for you. Most real answers mix the two, but it helps to define the pure forms first.

Buy: software as a service or a packaged product

Buying means licensing a product that many other companies also use. Today that usually means software as a service (SaaS), which is software the vendor hosts and updates while you pay a subscription. HubSpot or Salesforce for sales pipelines, NetSuite for finance and Microsoft 365 for documents and email are typical examples.

You get a working product quickly, and the vendor carries hosting, security patches and new features. In exchange you accept the vendor's data model, its assumptions about how the workflow runs, its pricing changes and its roadmap.

Integrate: connect and extend what you already have

Integration means making the systems you already pay for work together, and extending them where they fall short. That can be a connection that moves orders from Salesforce into your ERP, an automated workflow that routes approvals across Microsoft 365, or a small module added inside a platform that supports extensions. Most integrations run through APIs (application programming interfaces), the documented way one system lets another read or write its data.

This option is often overlooked because it does not feel like a project with a product at the end. The gap it addresses is large. The 2025 MuleSoft Connectivity Benchmark Report found that the average enterprise manages 897 applications and only 29% of them are integrated.

Build: custom software you own

Building means commissioning software designed around your process: an internal tool, a customer or supplier portal, a pricing engine or a mobile app for field staff. You decide the workflow, the data model and the priorities, and you can own the code outright if the contract says so.

The price of that control is responsibility. Someone must host, secure, update and improve the software for as long as the business relies on it.

Which criteria should decide between build, buy and integrate?

Eight questions do most of the work. Answer them for the specific process in front of you, not for your software strategy in general, because the right answer for quoting may be the wrong answer for payroll.

1. How differentiating is the process?

Start here. Martin Fowler's utility versus strategic distinction is a useful lens. Utility functions, such as payroll or expense claims, must work reliably but give you no advantage over competitors. Strategic functions are part of how you win. Fowler's view is that for a utility function you buy the package and adjust your business process to match the software, and he cautions that genuinely strategic projects are rare: the usual 80/20 split "may be more like 95/5."

A practical test: would a customer notice or care if you ran this process exactly the way your competitors do? If not, it is probably a utility, and building it is hard to justify.

2. How well does standard software fit?

Map your process against two or three leading products before anyone writes requirements for custom work. Score the fit honestly: what works out of the box, what needs configuration, what needs a workaround and what is missing.

Good fit on the core steps with gaps at the edges usually points to buying and integrating. Poor fit on the core steps, where every workaround adds manual effort or risk, is the signal that custom software deserves a closer look.

3. What does it need to connect to?

List every system the process touches and the direction the data moves. A quoting tool may read customer records from the CRM, prices from NetSuite and stock levels from a warehouse system, then write the accepted quote back to the CRM.

Check whether candidate products have maintained connectors for those systems, whether your existing systems expose usable APIs, and who is allowed to grant access. Integration effort is one of the most common hidden costs on both sides of the decision.

4. What is the total cost of ownership over 3 to 5 years?

Total cost of ownership (TCO) is everything you spend to acquire, run and change a system over its useful life. Compare options over 3 to 5 years and include:

• Licenses or subscriptions, including growth in seats and price rises at renewal.
• Implementation, configuration, data migration and training.
• Building and maintaining integrations.
• Hosting and cloud usage for anything you build.
• Maintenance: security updates, upgrades of the libraries the code depends on, bug fixes and small enhancements.
• Internal time: the administrators, product owners and support staff each option needs.

Running costs dominate over time. The US Government Accountability Office reports that federal agencies spend more than $100 billion a year on IT and cyber-related investments and typically report spending about 80 percent on operations and maintenance of existing IT. A government portfolio is not a 150-person company, but the lesson carries: the build is rarely the largest part of the bill.

5. How quickly do you need value?

A SaaS product can often be live for a first team within weeks, while custom software needs design, development and testing before anyone uses it. If the problem is urgent and a product covers most of it, buying first and revisiting later is often the pragmatic choice.

Time to value also depends on adoption. A tool that fits how people already work gets used sooner, which sometimes favors an integration or a small custom layer over a large new product that changes everyone's routine.

6. Who owns the code, the data and the intellectual property?

With SaaS you should own your data (check the contract), but not the software, and exporting data in a usable form can be harder than importing it. With custom work, ownership depends entirely on the contract. Confirm that intellectual property transfers to you, that the code lives in a repository you control and that you hold the cloud accounts or can take them over.

Ownership matters most when the process is strategic, or when the software encodes pricing, eligibility or scheduling logic you would not want a vendor or a former contractor to control.

7. How much vendor risk can you accept?

Every product you buy carries the risk of price increases, changed terms, discontinued features or an acquisition. Zylo's 2026 SaaS Management Index reports that 78% of IT leaders saw unexpected charges tied to AI features or consumption-based pricing, and 61% cut projects because of unplanned SaaS cost increases.

Custom software moves that risk rather than removing it. You depend less on a vendor and more on the people who can maintain the code.

8. Can you maintain what you build?

Be honest about capability. If you have no internal engineers, custom software means a long-term relationship with a partner, or hiring. For context, the US Bureau of Labor Statistics puts the median annual wage for software developers at $135,980 in May 2025, before benefits and management time.

Neglected code gets expensive. CISQ's 2022 report estimated that accumulated software technical debt in the US, meaning the cost of reworking suboptimal software, had grown to approximately $1.52 trillion. Our guide to technical debt in business systems explains how that debt builds up and how to pay it down.

A decision table for build vs buy software

Use the table as a first pass for each process, then test the answer against your cost model.

If most answers fall in one column, the decision is usually clear. If they split across columns, you are probably looking at a hybrid.

Is a hybrid answer usually the right one?

For most growing companies, yes. The pattern that holds up best is to buy the core and build the edges. The core is the system of record: the software that is the official home for a type of data, such as the ERP for orders and invoices or the CRM for customers. The edges are the workflows, portals and tools around it that reflect how your business actually operates.

Three hybrid shapes come up repeatedly:

1. Buy the platform and extend it. Use the extension points of products such as NetSuite, Salesforce or Microsoft Dynamics for custom fields, rules and small modules, while staying on the vendor's upgrade path.
2. Buy the core and build a layer on top. Keep the ERP as the source of truth and build a focused portal or internal tool that reads and writes through its API, so staff or customers never need to work inside the ERP.
3. Integrate first and build later. Connect existing systems and automate the handoffs now, then build custom software only for the gap that remains once data flows properly.

A hybrid keeps custom code small, which keeps maintenance small. It also means you can replace one piece later without rebuilding everything.

Illustrative example: Consider a regional distributor of packaged food with about 120 staff. Sales reps build quotes in a spreadsheet, phone the warehouse to check stock and email the result to customer service, who rekey it into the ERP. Leadership's first instinct is to replace the ERP. A process-by-process review shows the ERP handles orders, invoicing and inventory well, and the real gap is quoting. A packaged quoting product cannot express the distributor's customer-specific promotions without heavy customization. The recommendation is hybrid: keep the ERP, integrate it with the CRM so customer and stock data flow automatically, and build a small quoting tool that applies the promotion rules and writes approved quotes back to the ERP. The custom code covers only the part of the process that is specific to the business.

What mistakes do companies make in each direction?

Both options fail in predictable ways. Most of these mistakes are decisions made by default rather than on evidence.

Mistakes when building

• Building a utility. A custom CRM, expense tool or HR system rarely pays back, because vendors spread the cost of features and compliance updates across thousands of customers.
• Underestimating life after launch. The first release is the start of the cost, not the end. Budget every year for hosting, security updates, upgrades and enhancements.
• Skipping the requirements work. Vague requirements produce software that matches nobody's process. A written brief with users, must-haves and success measures prevents much of this. See how to write a requirements brief a development partner can use.
• Leaving ownership unclear. Code in a contractor's repository, cloud accounts under a personal email address and no documentation each make software hard to maintain or move.
• Building too much at once. A first release that tries to cover every role and exception takes longer to deliver and longer to adopt. Start with the core workflow, as covered in planning the first release of internal tools and portals.

Mistakes when buying

• Customizing a product until it behaves like custom software. Heavy customization can make upgrades painful and leaves you paying the costs of both options.
• Buying for features instead of fit. Demos show breadth. Test the product against your actual process, your data and your most awkward exceptions.
• Ignoring integration. A product that does not connect to your ERP or CRM becomes one more place for staff to rekey data.
• Missing the pricing model. Per-seat, per-record and usage-based pricing behave very differently as you grow. Model the renewals, not just year one.
• Adding tools without an owner. Each subscription needs an administrator, periodic access reviews and an exit plan. Without them, software sprawl creates security gaps and duplicate spend.

A related trap sits between the two: adopting a no-code or low-code platform as a quick fix and then discovering its limits once the process scales. Our comparison of off-the-shelf, no-code and custom software covers where those platforms fit and how to move off them.

How does AI change the build vs buy decision?

AI shifts the calculation in four ways, and not all of them favor building.

Writing code is faster, owning it is not

AI coding assistants can speed up well-defined tasks. In GitHub's controlled experiment, developers using Copilot wrote an HTTP server in JavaScript 55% faster than developers without it. The evidence is not uniform. A 2025 study by METR found that experienced open source developers working on large, familiar repositories took 19% longer to complete tasks when allowed to use AI tools, even though they expected to be faster.

Developers themselves are cautious. In the Stack Overflow 2025 Developer Survey, 84% of respondents were using or planning to use AI tools, yet 46% distrusted the accuracy of the output and 66% named "AI solutions that are almost right, but not quite" as their top frustration. Google's 2025 DORA report puts the pattern plainly: AI "doesn't fix a team; it amplifies what's already there."

The practical conclusion is that AI can lower the cost of producing software, but review, testing, security and maintenance still need experienced engineers. For a closer look at what moves a budget, see what drives the cost of custom software.

Bought software now ships with AI, and with AI pricing

Major SaaS vendors are adding AI assistants and agents to their products, often priced by usage or sold as add-ons. That can be the fastest route to AI inside a standard process. It also makes costs harder to predict, as the Zylo figures above show, and it ties your AI capability to the vendor's choice of models and its roadmap.

Integration becomes more valuable

AI is only as useful as the data it can reach. In the same MuleSoft report, 95% of organizations said they face challenges integrating AI into existing processes, and 80% cited data integration as their most significant obstacle. For many companies, the highest-value AI project is therefore an integration project: connecting the ERP, CRM, document stores and email so that an AI workflow can read context and act within approved limits, with a person approving consequential steps.

Custom AI needs a model strategy

If you build AI into custom software, decide early how you will choose and replace models from providers such as OpenAI and Anthropic, how you will test output quality against real cases, and where your data is processed. Designing so that the model can be swapped keeps you from recreating the lock-in you were trying to avoid.

How should you run the decision?

A disciplined decision does not need a long exercise. This sequence works for most processes:

1. Name the process and its owner. One workflow, one accountable business owner, and a clear statement of the problem and what it costs today.
2. Map the current process. Steps, roles, systems, handoffs and the exceptions that cause the most rework.
3. Classify it. Utility or differentiator, using the questions above.
4. Test two or three products against it. Use your real data and your hardest exceptions, not the vendor's demo script.
5. Check integration feasibility. Confirm API access, permissions and data quality in every system involved.
6. Model 3 to 5 year TCO for each option. Include internal time and maintenance, and write down the assumptions.
7. Decide and record why. Note the option, the reasons and the conditions that would make you revisit the decision, such as a large price increase or a change in the process.

The written rationale matters more than it seems. When a vendor raises prices or a new requirement appears two years later, you can check whether the original reasoning still holds instead of starting the debate again.

How Kastling approaches build, buy or integrate decisions

Kastling is an AI solutions and implementation partner. Custom software is one of three services, alongside AI integration and automation and AI and cloud infrastructure, so the recommendation for a given process can be an integration, an automated workflow or a new application, depending on what the process needs.

We start by understanding the work before the technology, and we prefer to connect existing systems rather than replace them. Where custom software is the right answer, Custom Solutions covers internal tools, dashboards, customer or supplier portals and web or mobile apps, with or without AI.

An engagement starts with a free discovery call. A clearly defined software brief can move straight to a scoped proposal, while broader AI and operations work often begins with a separately scoped, paid audit. Before development starts, we agree the scope, how success will be measured, and who owns the data, the code and the accounts. The software is tested against real business scenarios with the people who will use it, then integrated and supported with training. Ongoing maintenance is optional and covered by a separate agreement.