Field notes / Startup & Product
Build, buy, or integrate: deciding before the code starts
Give a practical decision framework for software ownership and integration risk.
A software request often arrives as a choice of tools. I would start with a different question: which behavior needs to belong to this business? That answer determines where custom code earns its maintenance cost.
Consider a fictional appointment-booking business. Its advantage is matching a specialist to a complicated customer need. Sending reminders is necessary, but a custom reminder delivery system would not make that matching better. The booking rules and the delivery channel deserve different ownership decisions.
Separate the differentiator from the commodity
Keep the matching rules close to the product team. Treat message delivery as a replaceable boundary. For an existing customer database, investigate integration before proposing a replacement: the business may depend on workflows the initial request never mentioned.
The build-buy-integrate decision
Build the differentiating core, buy a suitable commodity, or integrate with an existing system; every path needs a maintenance owner.
Illustrative framework · Graphic by Nick JensenRead the diagram as text
Decision tree choosing build for differentiation, buy for a commodity with an exit plan, or integrate with an existing system; each choice needs a maintenance owner. Build the differentiating core, buy a suitable commodity, or integrate with an existing system; every path needs a maintenance owner.
This is a decision tree, not a vendor score. A commodity service can still be unsuitable if it cannot satisfy access, retention, or export requirements. A custom implementation can still be the wrong investment when nobody will operate it.
Work the decision through a failure
Suppose the messaging provider is unavailable after a booking succeeds. The booking should remain durable. A separate delivery job can retry against a stable booking ID while the interface reports that confirmation is pending. Putting those outcomes behind one provider-specific success flag would make a channel outage look like a lost appointment.
The integration contract should identify the local record, the remote reference, the owner of retries, and the visible failure state. An adapter is useful only if it contains real differences; a wrapper that passes every vendor field straight through has preserved little freedom.
The whole ownership picture
Ownership includes operation and an exit path, whether the capability is built, bought, or integrated.
Illustrative framework · Graphic by Nick JensenRead the diagram as text
Build / core differentiation: Own behavior and maintenance. Budget for operation and replacement.; Buy / commodity capability: Evaluate fit, access and export. A subscription is still a dependency.; Integrate / keep the system: Own mapping, retries and monitoring. Keep the provider behind an interface. Ownership includes operation and an exit path, whether the capability is built, bought, or integrated.
Price the exit as well as the entrance
For this example, I would ask each candidate solution to demonstrate export, cancellation, failure inspection, and credential rotation. Those are acceptance checks, not promises that switching will be cheap. The team must still understand what data can leave, what configuration cannot, and what users would need to relearn.
Buying trades implementation work for dependency management. Building trades subscription constraints for ongoing engineering ownership. Integrating keeps existing value but introduces mapping and reconciliation work. None removes the need for a named operator.
Write down the decision with its assumptions: expected workflow, required controls, maintenance owner, and the trigger for revisiting it. If the differentiator changes or an integration becomes the dominant source of incidents, the original choice deserves another review.
Before asking for a full implementation estimate, produce a small scope with observable acceptance checks. For a system with several external boundaries, use the API architecture guide. If you want help deciding what deserves custom software, bring the workflow to a build conversation.
From the idea to the work
Make the workflow useful in a real product.
Bring a product idea, an internal tool, or an AI-assisted workflow that needs a working implementation.