Build or buy: custom software vs SaaS.

Build or buy is decided one system at a time. Accounting, payroll and email are common enough that a bought product is almost always right. The way you quote, schedule, approve, onboard or serve a customer is often specific to you, and that is where custom software earns its place.

Three questions settle most cases. Does the product fit the process today, without workarounds? Can it change when the process changes? Can it reach the other systems your team uses? Yes to all three points to buying. One no points to the hybrid option, and two or three point to building.

• The process is standard: invoicing, payroll, email, calendars, document signing, basic support desks.
• The product already does what you need, and the gaps are small enough to live with.
• You need it working soon, and the parts you would customize can wait.
• Few of your own rules need to live inside the tool, so its settings are enough.
• You are testing a way of working and may drop it, so a subscription is a cheaper experiment than a build.

The cost of buying shows up later, as workarounds. A team that exports data to a spreadsheet every week to finish a job the product cannot do is paying for the gap in hours. When the workarounds start to outnumber the features you use, the product has stopped fitting.

• The process is part of how you compete, so a product built for everyone would flatten it.
• Different roles, such as sales, dispatch, finance, partners and customers, need different access to the same records.
• The system must connect to others in ways a product's standard connectors do not allow.
• You want to hold the data and the rules yourself, and decide who sees what.
• The process changes with the business, and waiting for a vendor's roadmap holds you back.
• An AI agent needs to read and act on your data with permissions you define.

Building also has costs. It needs a clear scope, a delivery team and time before anyone uses it, and it needs maintenance afterward. A discovery phase at the start keeps those costs visible, and the cost guide explains what drives them.

Low-code suits internal workflows with a handful of steps, a small group of users and no unusual rules: an approval form, a simple tracker, a request queue. It suits a team that wants to build and own small tools without a development project. The glossary defines the term.

Three limits are worth checking before you commit. First, you build inside the platform's rules, so a requirement it does not support becomes a workaround. Second, the app lives on the platform, so leaving means rebuilding. Third, licensing is usually charged on the platform, by user or by app, and that shape can change as you grow. Low-code is a fair choice for a narrow job and a weak one for the system the business runs on.

Hybrid is often the most practical answer because it spends build effort where it pays back. A bought accounting product stays. A custom layer moves orders from the quote tool into accounting, keeps the customer record in step across both, and shows the sales team a single screen instead of three.

Foxefy has delivered internal tools, ERP modules, customer, partner, dealer and vendor portals, and standalone workflow automation and integration work. Those are the usual pieces of a hybrid setup. Back-office operations and sales and customer operations describe how Foxefy approaches the systems that sit around the tools you already pay for.

A hybrid setup needs one rule: decide which system owns each fact, such as the customer's credit limit, the price or the delivery address, and make every other system read it from there. Without that rule, a hybrid setup becomes the same data typed into three places.

The custom CRM vs off-the-shelf CRM guide takes this one comparison further, with the questions to ask before you choose and what to check when moving data between systems.

The system types are compared side by side on the back-office operations page. For the sales side, see sales and customer operations. A worked example for a distributor is in the insight CRM, ERP or internal tool for distributors.

An internal tool is the easiest of the three to build and the hardest to buy, because it exists for the step that no product handles. A CRM and an ERP are the reverse: products for both are common, so the question there is how far the product's standard shape stretches before your team starts working around it.

A simple order of operations helps. Start with the system where the pain is highest and the process is most specific to you. Buy where a product fits, build where it does not, and connect the two so each fact has one owner.

AI changes the build side of the choice in one way: an agent needs access to your data and the right to act on it, and that access is easier to control in a system built for you. A bought agent works inside its vendor's product. A built agent can work across your CRM, your accounting software and your inbox, with a person approving what matters.

Ask four things before deciding. Which systems must the agent read, and which must it change? Who approves its work before it reaches a customer? What happens when it is wrong? Who watches it after launch? If a bought agent cannot answer these inside your own rules, building is worth a closer look.

The AI agents for business operations guide explains what agents do and where they fall short. The insight when to build your own AI agent walks through the decision in more detail. See AI and automation for how Foxefy approaches this work.