Build or integrate: where should your product development boundary sit?

Adding a capability does not require choosing between building everything and sending users to another application. You can develop the interface and workflow that distinguish your product while integrating a specialist service for part of the work. The important question is the boundary: who holds the data, who performs the action and who handles problems? Before requesting an estimate, define ownership of each part and the work that remains yours after integration.

What does the Xero and Gusto integration illustrate?

In August 2026, Xero announced US payroll powered by Gusto. Its announcement describes running payroll within Xero and connecting the data to accounting while Gusto supplies payroll capabilities. This is the company's product description, not our assessment of calculation quality or the agreement between the companies. It does not establish that all business or legal responsibility transfers to the engine provider.

Our interpretation is that a unified experience does not require owning every execution layer. Users can remain in a familiar journey while a specialist service operates behind it. However, a unified screen does not erase the system boundary. Define what happens when information differs, an operation remains pending or the provider is unavailable. The integration itself is part of the product and needs design and maintenance.

Identify what actually differentiates the product

Start with why customers choose you. Is it a distinctive workflow, information combined from multiple sources or specialist capability without a suitable alternative? A component central to that promise may justify more control and internal development. A non-differentiating component requiring ongoing upkeep may suit a provider. These are considerations to examine, not a rule that buying or building is always superior.

For each capability, record what changes frequently and who has the expertise to change it correctly. A small screen may conceal substantial support, rule maintenance and quality-control work. Do not compare only first-version development time with a supplier's subscription fee. Compare ongoing work, staff availability and the impact of changing requirements too. This reveals whether internal development is an advantage or a commitment you do not yet have the team to sustain.

Draw the data and action boundary

Trace one action from beginning to end. Identify user inputs, information sent externally, the system authorised to confirm completion and the result displayed. If two systems store the same information, decide which is authoritative when values differ. Otherwise, the team may build synchronisation that copies data without resolving which version is correct. Record the result in the technology product specification.

In a hypothetical ordering system, you might develop a distinctive selection experience while using a provider for a defined operation. You still need to associate its response with the order, handle late responses and avoid displaying success prematurely. This is a boundary-design exercise, not a client project claim. Ask the team to demonstrate the path with an uncertain response as well as the path in which everything completes immediately.

A documented example from Julius's website

During our October 15, 2026 website release check, test enquiries submitted through Hebrew and English forms were read back as CrmLead records in CodeManage. The evidence also recorded Umami measurement when analytics consent was present. This illustrates a practical boundary between the form experience and the enquiry-management system. It does not claim that the website contains a CRM built from scratch, or that the integration generated booked meetings or sales.

For software buyers, the implication is that verification can extend beyond the local screen. A successful form message alone does not establish that the working system received a usable record. A check should reach the system holding the result and confirm that necessary information exists there. Meanwhile, separate the integration's purpose from additional metrics: a saved enquiry is not a booked meeting, and consented analytics is not a complete census of every action.

Evaluate fit rather than a feature list

Choose scenarios representing your work and test whether the service supports them, under which constraints and with what additional implementation on your side. Request details of test environments, permissions, usage limits, version changes and support. Ask what data can be exported and how work continues if the integration changes. Our external API dependency guide explores risks after selection; the question here is which responsibilities to delegate in the first place.

Prepare an estimate separating interface adaptation, integration, testing and operation. Add expected usage costs and a higher-volume scenario. If a supplier does not cover an important exception, decide whether to handle it manually, narrow the promise or choose another solution. Do not mark a capability as covered merely because its name appears on a vendor website. Coverage must fit the business case you intend to offer customers.

How do you decide what to build now?

A limited integration can test value without committing to an entire proprietary engine. Define what you expect to learn and which signals would justify reconsidering the boundary. In an AI product, a model provider does not replace task definition, evaluation or permission design; our guide to choosing AI developers explains the surrounding work. A future provider change may require adaptation, so do not promise cost-free or test-free replacement.

For a conversation with Julius about software development, bring the journey customers must complete and the area where you want to be different. Compare internal development, an external service and a combined solution against the same business outcome. A useful decision specifies what stays under your control, what the provider handles and how the integration will be verified. You can then build your product without turning every capability inside it into another product to maintain.