A field guide to software judgment
Most businesses do not need another app. They need a clear decision about the part that should be bought, the part that should be connected, and the small piece worth owning.
Open the dossierThe expensive mistake is not choosing a vendor. It is treating every gap in a tool as a reason to own an entire product.
Buying a tool can be the right move when the need is a commodity and the vendor carries the weight of updates, support, security work, and infrastructure. Building can be the right move when the workflow is the business advantage and the rules need to remain yours. Connecting is the middle path that gets skipped: keep the mature capabilities, then make the handoff feel like one service.
The first question should be concrete: what does a customer, employee, or operator need to finish? GOV.UK’s purchasing guidance asks teams to document the user need, capabilities, and decision process before choosing to build or buy. [1] That is useful because technology categories are poor substitutes for a real outcome.
“If this worked perfectly, what would be measurably easier for someone?”
What already works and does not need a new owner.
What should become one customer or operator journey.
What contains the domain advantage or a rule you must control.
Three moves, one outcome
This comparison is a starting point for a real decision, not a scorecard. Open each panel, then test the smallest slice of the workflow with real users, permissions, data, and failure cases.
The need is common, the workflow is well understood, and a maintained product already meets most of the need.
Fit gaps, contract terms, export paths, service limits, and whether the product can be used safely by the people who need it.
Run a bounded fit test with real records, roles, and one awkward exception.
The differentiating work sits between tools: a handoff, approval, notification, or view that nobody should retype.
Ownership of data, retries, duplicates, permission boundaries, provider outages, and the point where a sync becomes a second system of record.
Name the source of truth, then prove one complete round trip with a replayable test record.
The workflow itself is the advantage, the need changes quickly, or no product can represent the real domain without bending it out of shape.
Security, operations, support, recovery, upgrades, and the permanent owner after the first release. NIST’s SSDF exists because shipping code is only one part of the job. <Cite n={3} />
Write the narrowest version of the domain rule and test it with the people who will operate it.
| Question | Buy | Connect | Build |
|---|---|---|---|
| Where is the value? | The product itself | The handoff between products | Your domain rules |
| Who carries the platform? | Vendor, with contract limits | You own the seam and its failure modes | You own the whole operating loop |
| What must be proved first? | Fit with real work | Source of truth and permissions | Domain rule and recovery |
The “connect” column is where many practical fractional CTO decisions land: small, explicit integration work around a stable capability.
What evidence changes the choice?
GOV.UK’s guidance says teams need roles to design, build, and run a service, and recommends buying missing skills without locking the service into a long fixed contract. A vendor or contractor can accelerate delivery; someone still has to own quality, decisions, and the handover. [2]
NIST’s SSDF groups security work across preparing the organization, protecting software, producing well-secured software, and responding to vulnerabilities. The work exists whether the code is built internally or wrapped around an integration. [3]
CISA’s secure-by-design guidance asks manufacturers to take ownership of security outcomes and default settings. When you buy, ask what the product does safely without a custom patch; when you connect, ask what data and permissions cross the seam. [4]
Open standards make it easier to share data, change suppliers, and reuse components. They do not remove migration work, but they make the future legible enough to plan. [6]
A practical sequence for owners
A good decision gets smaller as you learn. Start with a thin slice that reaches a real outcome; do not build the imagined future around an untested workflow.
Use the language of the person waiting for the result: an approved quote, a paid invoice, a resolved request, a portal update. Avoid “we need an app.”
List what your current tools already know how to do, including roles, exports, events, APIs, webhooks, and support boundaries. Stripe’s hosted Checkout is a clean example of a capability that usually deserves to be used rather than rebuilt. [5]
Decide which system is authoritative, what can be retried, how duplicates are detected, and who can see or change each record. OWASP calls object-level authorization a common API weakness; test it at every endpoint that touches a record. [7]
If the business edge is a rule no vendor can represent cleanly, build that narrow rule and leave the commodity surfaces to maintained products. Choose the right identity assurance and recovery path for the risk; NIST’s current guidance treats usability, privacy, and security as part of the identity decision. [8]
Ian helps owners separate the product they need from the product they merely imagined, then gets one useful slice operating safely.
Sources & methodology
This report was researched September 8, 2026 for business owners deciding how much software to own. It synthesizes official guidance and product documentation; it does not estimate project cost, vendor quality, or expected return for a particular company.
“Buy,” “connect,” and “build” are analytical categories used here to make a decision visible. In practice, a service may combine all three. Recommendations and examples are Ian Dikhtiar’s operating judgment, clearly separated from source-backed claims.
Government Digital Service · GOV.UK · Updated September 3, 2026
Official guidance that requires a documented user need, capability review, and explicit build-or-buy decision process. It is public-sector guidance, not a small-business cost benchmark.
Government Digital Service · GOV.UK · Updated October 17, 2024
Guidance on buying missing skills without locking a service into a fixed contract, including knowledge transfer, quality, and cyber-security expectations.
National Institute of Standards and Technology · February 2022
NIST framework for reducing vulnerabilities and their impact across software development. It is a control framework, not a claim that building is inherently unsafe.
CISA and international partners · April 2023
Joint guidance asking software makers to take ownership of secure defaults and shift security responsibility away from customers where possible.
Stripe Documentation · Current documentation checked September 2026
Stripe documents hosted and embedded Checkout as low-code options. Product fit, regional payment methods, taxes, and webhook handling still require a real integration decision.
Government Digital Service · GOV.UK · Updated June 13, 2024
Guidance connecting open standards with reuse, supplier choice, lower lock-in, and change over time. Government context; the principles are broadly useful but not a price model.
OWASP API Security Project · 2023 edition
Primary security guidance on checking authorization for every object and action addressed by an API. It explains a material integration risk without estimating its likelihood for a specific business.
National Institute of Standards and Technology · Updated September 30, 2025
Current identity guidance covering proofing, authentication, federation, security, privacy, and customer experience. The right assurance level depends on the service and threat model.