The first architecture decision on a new product is rarely a debate about build versus buy. It is a sequence: list every capability the product needs, mark which ones actually differentiate the business, then check whether a vendor, an API, or custom code covers each one. Teams that skip the sequence often end up rebuilding the same thing twice.
The inventory comes before the debate
Before anyone argues for a vendor or a custom build, someone has to write down what the system needs to do, in plain language, without naming a single product. This list usually runs longer than founders expect, thirty or forty items for even a modest first release, and most of them turn out to be commodity work: authentication, billing, file storage, notifications, search. Sorting that list into “commodity” and “core to the business” is the actual first decision. Everything that follows, which vendor, which framework, which integration pattern, is detail layered on top of that sort.
Teams that argue about tools before doing this sort tend to pick the tool that a senior engineer happens to like, which is not the same as picking the right one. The inventory forces the conversation onto what the product needs rather than what someone is comfortable with.
What changed in 2024, and why it matters
Two things moved in opposite directions at the same time. AI coding assistants went from novelty to default tooling on many engineering teams, cutting the time it takes to get a working first version of a custom feature in front of users. At the same time, a wave of SaaS vendors shifted from flat per-seat pricing toward usage-based or consumption pricing, which raises the long-run cost of buying once a product scales past its first few thousand users. The old default, buy unless there’s a strong reason not to, no longer holds automatically, because both sides of the ledger moved.
This does not mean building is now free or always cheaper. It means the gap between the two options narrowed enough that the decision is worth making deliberately, with real numbers, instead of by habit.
Where gluing things together actually wins
Gluing together, wiring a handful of existing services with integration code and webhooks instead of building a single monolith or buying one all-in-one platform, wins when a product needs several commodity capabilities that no single vendor bundles well. A payments flow that combines a billing API, a tax calculation service, and a custom approval step is a normal shape for this kind of architecture. The risk is not mainly technical. It is organizational: someone has to own the seams between the services, or the whole thing degrades the first time one vendor changes its API without warning.
The three-year cost nobody asks about early
Most buy-versus-build conversations stop at the first invoice or the first sprint estimate, when the number that actually matters is the total cost over three years: licensing growth as the product scales, the ongoing maintenance of integration code, and the cost of switching if a vendor changes its terms or the team simply outgrows the tool. A fractional CTO brought in at this stage is usually asked to model that three-year number before a contract gets signed, not after the f
For more detail, see Kody Doherty, Fractional CTO.
