Build vs buy

The build-versus-buy decision for trading technology turns on one question, and getting that question right is most of the work: is trading technology genuinely your differentiator? For most desks the platform is table stakes and the edge is in strategy, relationships, and execution, not in re-implementing trade capture, valuation, risk, scheduling, and settlement. The heuristic that follows is simple to state and surprisingly hard to apply under pressure: build what is uniquely yours, and buy what is table stakes.

The difficulty is that almost every capability feels, to the team that would build it, like it could be done better in-house. That instinct is usually right about quality and usually wrong about value. Building a marginally better trade-capture screen does not create competitive advantage; it consumes scarce engineering effort that could have gone into the one or two things that actually differentiate the business. The discipline of the heuristic is to keep asking, for each capability, not could we build this well but would building it create an edge.

The heuristic sounds obvious stated baldly, yet firms violate it constantly, because the pressure to build comes from the most capable and confident people in the room. Engineers who could genuinely build a better trade blotter naturally want to, and their competence is real; the flaw is not in their ability but in the premise that a better blotter creates advantage. The discipline is to separate the question of whether something can be built well, which flatters the team, from whether building it creates an edge, which serves the business. Only the second question should drive the decision.

It helps to remember what actually produces returns in a trading business. It is rarely the trade-capture screen or the settlement engine; it is the strategy, the market insight, the relationships, and the discipline of execution. Technology serves these, and the parts of technology that embody a firm’s specific insight can be worth building, but the undifferentiated lifecycle that every competitor also has is not where returns come from. Keeping this clearly in view is what stops a firm from pouring its scarce engineering into the parts of the stack that create no advantage.

As you work through your platform decision, apply the heuristic to each capability explicitly: for this specific thing, would building it create an edge, or merely reproduce something the market already provides? Write the answer down. The capabilities where building creates an edge are few and worth protecting; the many where it does not are candidates to buy. The discipline of asking the question capability by capability, rather than debating the firm’s technology in general, is what turns the heuristic into a decision you can actually make and defend.

The phrase build versus buy invites a binary answer, and the binary is the first mistake. Almost no trading business should build everything, because the trade lifecycle is vast and mostly undifferentiated; almost none should buy everything with no ability to build on top, because that surrenders the possibility of an edge. The real decision is a portfolio decision, made capability by capability, about where to build, where to buy, and where to compose one on the other. Framing it as a single yes-or-no drives the organisation toward an extreme that is rarely right.

The binary framing is also how the loudest voice tends to win, because it turns a nuanced portfolio question into a contest between the build camp and the buy camp. The engineers argue for building, the finance team for buying, and the decision goes to whoever is most persuasive rather than to whichever answer is right for each capability. Reframing the question as capability by capability defuses this, because it stops asking who is right in general and starts asking what is right for each specific piece, which is a question the evidence can actually answer.

The portfolio framing also changes who should be in the room for the decision. A binary build-or-buy question tends to be settled by whoever argues most forcefully, often the head of engineering or the head of finance, in a single meeting. A capability-by-capability portfolio decision requires the desk, the engineers, the operations team, and the finance function to work through each capability together, because each brings knowledge the others lack about what differentiates and what is table stakes. The reframing improves not only the answer but the process that produces it.

Reframing away from the binary also defuses the emotional charge that often distorts the decision. Build-or-buy framed as a contest makes the engineers feel their competence is being doubted if the answer is buy, and makes the finance team feel reckless if the answer is build. Framed as a portfolio, the same decision becomes a shared, unemotional sorting of capabilities into where each belongs, which is far more likely to reach the right answer because it is not a referendum on anyone’s worth.

Convene the right people for the decision and frame it as a portfolio, not a referendum: bring the desk, engineering, operations, and finance together to sort capabilities into build, buy, and compose, rather than letting a single meeting settle a binary. The differentiation assessment gives this conversation a structure, so it produces a documented portfolio of choices rather than a contest won by the most forceful advocate. The reframing improves both the answer and the process, and it defuses the emotional charge that distorts a build-or-buy debate.

Buy the platform when you need the full trade lifecycle working reliably, quickly, and at low risk, which is to say almost always. Building capture, valuation, risk, scheduling, and settlement from scratch is a multi-year undertaking with a large and unglamorous surface area: every instrument, every convention, every market’s quirks, every regulatory report. None of that surface area differentiates you, and all of it must be built correctly and then kept correct for years as the world changes. The lifecycle is a solved problem, and buying it lets your engineering effort go where it actually creates an edge.

There is a second, subtler reason to buy the lifecycle: a bought platform amortises the enormous ongoing cost of correctness across every customer. When a market changes a convention or a regulator changes a reporting rule, the vendor makes the change once for everyone. A team that built its own lifecycle must make every such change itself, forever, and must staff for that maintenance indefinitely. The build cost is visible and finite; the maintenance cost is invisible and perpetual, and it is where in-house lifecycle projects quietly bleed value.

The reliability argument for buying deserves emphasis because it is easy to discount in advance and impossible to ignore in production. A bought lifecycle has been run by many customers across many market conditions, so its edge cases have been found and fixed by others before you meet them. A built lifecycle meets every edge case for the first time, in your production environment, often at the worst moment. The value of a platform that has already been hardened by others’ experience is real even though it is invisible until the moment an unhandled case would have caused a loss.

Speed is the other underrated reason to buy the lifecycle. A bought platform is trading in months; a built one is trading in years, if the build succeeds on schedule, which large builds famously do not. During those extra years the business either runs on its old system or does not exist, while the opportunity the technology was meant to serve waits. For most firms the cost of that delay, measured in strategy deferred and opportunity forgone, dwarfs the difference in licence cost, and it is a cost that only the buy option avoids.

When you evaluate the lifecycle, weight reliability and speed explicitly, because they are the reasons to buy that are easiest to discount in advance and impossible to ignore in production. Ask how long each option would take to have you trading, and remember that a bought platform has been hardened by many customers’ edge cases while a built one meets every edge case for the first time in your production. The delay and risk of building the lifecycle are usually larger than the licence saving, and only the buy option avoids them.

It is worth dwelling on just how large the trade lifecycle is, because underestimating it is the root of most failed build projects. Capture alone must handle every instrument the desk trades and every convention of every market, with all their special cases. Valuation must implement the pricing of each instrument correctly, with the right curves, day-count conventions, and settlement rules. Risk must aggregate across the book with the right methodologies. Scheduling must model physical delivery in all its logistical complexity. Settlement must produce correct invoices and payments. Each of these is a specialty, and each hides years of accumulated correctness.

The surface area is not only large but constantly moving. Markets add instruments, change conventions, and revise rules; regulators introduce new reporting requirements; conventions that were standard become obsolete. A platform must not only implement all of this correctly once but keep implementing it correctly as it changes, forever. This is why the lifecycle is described as a solved problem: not because it is easy, but because the solving has been done, at great cost, by vendors who amortise it across many customers, and redoing it in-house means re-incurring that cost alone.

The moving nature of the lifecycle is what turns a build from a project into a permanent obligation, and it is worth making the mechanism concrete. Suppose a firm builds its own regulatory reporting. It works on the day it ships. Then a regulator revises a reporting format, and the firm must change its code. Then a new instrument is traded that the report must cover. Then a jurisdiction adds a requirement. Each change is small, but they never stop, and the team that built the reporting must remain to make them, forever, or the reporting quietly falls out of compliance.

This is precisely the cost a vendor amortises. When the same regulator revises the same format, the vendor changes it once and every customer receives the change. The firm that bought its reporting pays a share of one change; the firm that built its own pays for the whole change alone, again and again, for every change the world imposes. Over a decade of relentless regulatory and market evolution, this difference between sharing the cost of correctness and bearing it alone is one of the largest and least visible in the whole build-versus-buy comparison.

Insist that any proposal to build a lifecycle capability include not just a development estimate but a ten-year maintenance run-rate, because the perpetual cost of keeping it correct is the number that most often makes building the wrong choice. Compare that run-rate against the amortised subscription of buying, in which the vendor makes each market and regulatory change once for all customers. The comparison of a decade of solo maintenance against a shared subscription usually reframes the decision decisively toward buying the lifecycle.

Build the pieces that are genuinely unique to your edge, a proprietary forecasting model, a bespoke analytic, a novel trading strategy, a signal no one else has, and build them on top of a platform’s API rather than reinventing the lifecycle underneath them. The test is the heuristic applied honestly: if a capability is a real source of competitive advantage, build it and protect it; if it is undifferentiated plumbing, buy it and forget it. The mistake is not building; it is building the wrong things.

When you do build, build thin and build high. The most valuable in-house code is a thin layer of genuine edge sitting on top of a bought lifecycle, consuming the platform’s governed data and calling its API to act. That layer is small, which means it is cheap to build and cheap to maintain, and it is entirely yours, which means it is where your advantage lives. The anti-pattern is building thick and low: reimplementing the lifecycle and burying your actual edge inside a mountain of undifferentiated code you now own forever.

Building thin and high is a discipline that must be actively maintained, because builds tend to grow downward over time. A team that starts by building a thin proprietary signal on top of a bought platform is often tempted, as it hits the platform’s limits, to build a little more of the lifecycle to get exactly what it wants, and then a little more, until the thin edge layer has grown a thick undifferentiated base. Resisting this drift, and pushing capability requests to the platform rather than building around it, is what keeps the built code small and the advantage concentrated.

The test of whether you are building high enough is whether a competitor could replicate your built component by buying something off the shelf. If they could, you have built too low, reimplementing something the market sells, and you should buy it instead. If they could not, because the component embodies your specific insight or strategy, you have built at the right altitude. Applying this test to each thing you are tempted to build keeps the build focused on genuine edge and out of the undifferentiated plumbing that the market already provides.

When you decide to build something, apply the altitude test: could a competitor replicate this by buying something off the shelf? If yes, you are building too low and should buy instead; if no, because it embodies your specific edge, you are building at the right height. Then guard against the downward drift of builds over time by pushing capability requests to the platform rather than building around its limits, so your built code stays a thin, high-value layer rather than growing a thick undifferentiated base you must maintain forever.

The whole decision rests on correctly identifying what genuinely differentiates your business, and this is harder than it sounds because almost everything feels differentiating from the inside. The test is external and comparative: would a competitor, given the same capability, be at no disadvantage, or does this capability let you do something they cannot? Trade capture does not differentiate, because every competitor has it. A proprietary forecast that consistently anticipates a market better than others do differentiates, because it produces an edge a competitor cannot simply buy. Most capabilities, examined this way, fall clearly on one side or the other.

A useful discipline is to write down, explicitly, what you believe your edge is, in a sentence a sceptic would accept. If the edge is a specific model, a specific dataset, a specific strategy, or a specific relationship, then the technology that embodies that edge is a candidate to build. If the edge is vaguer, we execute better or we understand the market, then the technology probably is not the edge; the people and the strategy are, and the technology should be bought so those people can focus on the strategy. The clarity of your answer about your edge determines the clarity of your build-versus-buy decision.

Identifying the edge honestly is uncomfortable because it often reveals that the edge is not where the firm likes to think it is. A desk may believe its edge is its sophisticated risk system when in fact its edge is a set of relationships and a trading discipline, and the risk system is ordinary. Facing this means accepting that the technology the firm is proud of is not its advantage, which is unwelcome but liberating, because it frees the firm to buy that technology and concentrate on the relationships and discipline that actually are the edge.

The sceptic test, stating your edge in a sentence a sceptic would accept, is powerful precisely because it is hard to pass. Vague claims of doing things better or understanding the market do not survive a sceptic’s scrutiny, and their failure to survive is informative: if you cannot state the edge specifically, the edge may not be specific enough to build technology around, and the honest conclusion is to buy the technology and invest in whatever the real, if unstated, advantage turns out to be. The discipline of the sceptic test is to refuse to build around an edge you cannot articulate.

Before you decide what to build, state your edge in a single sentence a sceptic would accept, and test it hard. If the edge is a specific model, dataset, strategy, or relationship, the technology embodying it may be worth building; if you cannot state it specifically, that is a signal to buy the technology and invest in whatever the real advantage turns out to be. The clarity of your answer about your edge determines the clarity, and the correctness, of your whole build-versus-buy decision.

The framing of build versus buy as a binary is itself a trap. An API-first platform lets you buy the lifecycle and build only what differentiates you, composing the two cleanly through supported, versioned interfaces. This is usually the lowest-risk path to a real edge: the platform carries the undifferentiated weight, and your engineers build the thin, high-value layer on top. You get the reliability and amortised maintenance of a bought lifecycle and the differentiation of in-house code, without owning the parts that create no advantage.

python# Build only your edge; call the platform API for the undifferentiated lifecycle.
from gravitas import Client

client = Client(api_key=KEY)

def my_proprietary_signal(market):
    ...                                   # THIS is your edge: build it
    return signal

def act_on_signal(signal):
    positions = client.positions.live()   # bought lifecycle: don't rebuild
    hedge = size_hedge(signal, positions) # your logic
    client.trades.book(hedge)             # bought lifecycle: capture, value, risk

This composability is why the API-first property of a platform matters so much to the build-versus-buy decision. A platform without a real API surface forces a binary: you either accept it as-is or you replace it, because you cannot build cleanly on top of it. A platform with a governed, comprehensive API dissolves the binary, letting you buy the lifecycle and build your edge on the same foundation.

The both option is not a compromise between building and buying but a distinct strategy that is often superior to either pure alternative. Pure building bears the whole lifecycle cost for no differentiation benefit on most of it; pure buying with no ability to extend surrenders the chance to embody the firm’s edge in technology. The both option captures the differentiation benefit of building exactly where it matters while paying the amortised, low cost of buying everywhere it does not. This is why an API-first platform is so valuable: it is what makes the both option available.

The both option also changes what a firm should look for when it buys, because the platform is now not only a lifecycle but a foundation to build on. The depth and quality of the API, the availability of events to subscribe to, the stability of interfaces across upgrades, become primary evaluation criteria rather than technical footnotes. A firm pursuing the both option is buying a platform to compose with, and it should evaluate the composition surface as carefully as the lifecycle, because that surface is what determines how much edge it can build on the bought foundation.

Evaluate platforms for the both option, not just as lifecycles: a platform you can compose your edge on is worth more than one you can only use as delivered. Ask what the API exposes, whether you can subscribe to events, and whether interfaces are stable across upgrades, because these determine how much edge you can build on the bought foundation. A genuinely API-first platform dissolves the build-or-buy binary and lets you buy the lifecycle while building exactly the differentiation that matters, which is usually the strongest position of all.

Composing your own code on a bought platform is only as good as the interface the platform exposes, so the both option depends entirely on the platform being genuinely API-first. This means every capability is reachable through a governed, documented, versioned interface, not just a few endpoints bolted on for show. It means the platform emits events you can subscribe to, so your code can react to what happens inside it. And it means the interfaces are stable across upgrades, so the edge you build against them does not shatter when the platform changes.

The depth of the API surface determines how much edge you can build. A shallow API that only lets you read some data and submit some trades limits you to thin integrations. A deep API that exposes the full lifecycle, positions, valuations, risk, events, and lets you extend the platform’s own behaviour, lets you build substantial differentiation on top of the bought foundation. When evaluating a platform for the both option, the depth, governance, and stability of its API are not secondary features; they are the very thing that makes the strategy possible, and they deserve to be evaluated as rigorously as the lifecycle itself.

The distinction between a shallow and a deep API is often the difference between a platform you can integrate with and one you can build on, and it is worth probing concretely during evaluation. Ask not whether there is an API but what exactly it exposes: can you read live positions, submit and amend trades, subscribe to events, retrieve valuations and risk, and extend the platform’s behaviour? A platform that exposes only a thin slice of its capability through the API confines you to shallow integrations, however much it markets itself as open.

Stability across upgrades is the other property that separates a usable API from a treacherous one. An interface that changes with every platform release turns the edge you built against it into a maintenance liability, because each upgrade threatens to break your code. A properly governed API is versioned, with breaking changes managed and old versions supported for a stated period, so the edge you build endures. When evaluating the both option, ask specifically about the API’s versioning policy and its history of breaking changes, because that history predicts whether your built edge will survive the platform’s evolution.

Probe the API’s depth and stability as rigorously as the lifecycle when you evaluate, because for the both option the composition surface is as important as the functionality. Ask concretely what the API exposes, whether it covers the full lifecycle or a thin slice, and what the vendor’s versioning policy and history of breaking changes are. A deep, well-governed, stable API is what makes the edge you build endure; a shallow or unstable one confines you to fragile integrations that shatter on upgrade.

Teams that choose to build often underestimate the ongoing cost, not of the first version, which is usually planned for, but of keeping the system correct as markets, instruments, and regulations change for years. This is the single most common and most expensive miscalculation in the build-versus-buy decision. The initial build is a project with an end; the maintenance is an operation without one. A convention changes, a market adds an instrument, a regulator revises a report, a curve construction needs updating, and each time, the team that built the system must make the change, test it, and deploy it, forever.

A bought platform amortises all of this across its whole customer base, which is why the subscription that looks expensive against a one-time build often proves cheaper once the perpetual maintenance is counted. When comparing build against buy, therefore, include the lifetime maintenance in the build column, not just the cost of the initial development. The comparison that counts only the build cost against the subscription is comparing a finite number against a perpetual one, and it systematically flatters building. The total-cost model accompanying this handbook frames the comparison honestly.

The perpetual nature of maintenance is the single fact that most often makes a build the wrong choice, and it is worth stating plainly why it is so easy to miss. When a build is proposed, attention is on the initial development: the cost, the timeline, the team to assemble. That cost is finite and can be planned. The maintenance that follows is unbounded and therefore uncomfortable to plan, so it is quietly assumed to be small, or is not costed at all. The build is approved on the visible, finite number, and the invisible, perpetual number arrives later, unbudgeted.

A useful corrective is to insist that any build proposal include a ten-year run-rate, not just a development estimate: the team retained every year to keep the system correct, the infrastructure, and the cost of the changes the world will force. Seeing the perpetual cost laid out over a decade, next to the amortised subscription of buying, usually reframes the decision, because the finite build cost that looked cheaper against the subscription now sits beside a decade of maintenance that the subscription includes and the build does not. The total-cost model exists precisely to make this comparison honestly.

Require every build proposal to show its ten-year run-rate next to the amortised cost of buying, so the perpetual maintenance that building incurs is visible before the decision, not discovered after. The finite development cost that looks cheaper against a subscription usually looks different beside a decade of solo maintenance that the subscription includes and the build does not. The total-cost model accompanying this handbook structures exactly this comparison, so the invisible, perpetual cost of building enters the decision where it belongs.

The most important and most neglected cost of building is not on any invoice: it is the opportunity cost of the engineering effort consumed. Every engineer building and maintaining an undifferentiated lifecycle is an engineer not building the firm’s edge. In a trading business, engineering talent is scarce and valuable, and how it is deployed is a strategic choice. Pouring it into reimplementing trade capture, which creates no advantage, means it is unavailable for the proprietary model or the novel analytic that would. This cost is measured in advantage forgone, which is why it never appears in a budget and is so easily ignored.

Counting the opportunity cost explicitly usually transforms the build-versus-buy comparison. When the build column includes not only the money spent but the edge not built because the engineers were busy building plumbing, the case for buying the lifecycle and concentrating engineering on differentiation becomes clear. The question to ask is not can our engineers build this, since capable engineers can build almost anything, but is this the highest-value thing our engineers could be building? For undifferentiated lifecycle capabilities, the answer is almost always no, and the opportunity cost of pretending otherwise is the edge the firm never developed.

The opportunity cost of engineering is best understood by asking what the firm is not doing while its engineers maintain a built lifecycle. Those engineers, among the most capable and expensive people in the business, are spending their days keeping trade capture and settlement working, when they could be building the proprietary model, the novel analytic, or the automation that would actually create advantage. The lifecycle maintenance is not free even when it is done well; its cost is the edge the firm never developed because the people who could have developed it were busy elsewhere.

This cost compounds in a way that is easy to miss. An edge not built this year is not merely a one-year loss; it is an advantage the firm never accrues and a lead a competitor may take instead. Over years, the firm that pointed its engineering at differentiation pulls ahead of the one that pointed the same talent at maintaining plumbing, not because it spent more but because it spent better. The opportunity cost of engineering is therefore not only large but cumulative, which is why leaving it out of the comparison, as most firms do, is such a consequential omission.

Count the opportunity cost of engineering explicitly in your comparison, because it is usually the largest and most neglected cost of building: every engineer maintaining an undifferentiated lifecycle is one not building your edge. Ask, for each thing you might build, not whether your engineers could build it but whether it is the highest-value thing they could be building. For undifferentiated plumbing the answer is almost always no, and naming the edge forgone is what makes the true cost of building visible.

The build-versus-buy comparison is won or lost on how honestly the costs are counted. The build column must include not only the initial development but the run-rate: the team retained to maintain the system, the infrastructure it runs on, the cost of every change the world forces on it, and the opportunity cost of the engineering effort that is now unavailable for anything else. The buy column must include not only the subscription but implementation, integration, and the internal effort of running the vendor relationship. A comparison that counts the build honestly and the buy honestly usually looks very different from the one sketched on a whiteboard.

The asymmetry to guard against is counting the buy side fully while counting the build side only to first release. The subscription is visible and recurring, so it is counted in full; the build’s perpetual maintenance and opportunity cost are invisible, so they are omitted, and the comparison is rigged in favour of building before it begins. An honest model counts both sides over the same horizon and includes the invisible costs of building, which is exactly what the accompanying total-cost model is designed to enforce.

Honest costing requires symmetry, and the most common failure is asymmetry that favours building. The buy side is easy to cost fully, because the subscription is a visible recurring number; the build side is easy to undercount, because its largest costs, perpetual maintenance and opportunity cost, are invisible. A comparison that fully counts the visible buy costs and partly counts the invisible build costs is not a comparison at all; it is a foregone conclusion dressed up as analysis. The discipline is to count both sides over the same horizon with the same rigour.

The internal cost of buying deserves its own honest accounting, because buying is not free of internal effort either. Implementing and integrating a platform takes work; running the vendor relationship takes attention; configuring the platform to fit the operation takes time. Counting these on the buy side keeps the comparison fair in the other direction, and a firm that counts them will make a better decision than one that pretends buying is effortless. The goal is not to favour buying but to count both paths honestly, which usually favours buying the lifecycle but occasionally reveals a genuine case to build.

Insist on symmetry in the comparison: count the build side over the same horizon and with the same rigour as the buy side, including the perpetual maintenance and opportunity cost that are easy to omit, and count the internal effort of buying too. The common failure is to count the visible subscription fully and the invisible build costs partly, which rigs the decision toward building before it begins. The total-cost model enforces the symmetry, so the comparison is fair in both directions and the answer rests on honest numbers.

Building trading technology is not only a cost decision but a talent decision, and the two are entangled. To build and maintain a lifecycle in-house, a firm must recruit, retain, and organise a substantial engineering team with specialised knowledge of trading systems. That team must be led, its knowledge must be documented so it does not walk out the door, and it must be covered when people leave, which they do. The firm becomes, in part, a software organisation, with all the management overhead that implies, whether or not software is its business.

There is a retention risk specific to building undifferentiated systems: the best engineers want to work on interesting, differentiating problems, not on maintaining a reimplementation of a solved lifecycle. A firm that assigns its talent to plumbing may find that talent leaving for work with more edge, taking with it the undocumented knowledge of the systems it built. Buying the lifecycle and pointing engineering at genuine differentiation is not only better for the firm’s edge; it is often better for retaining the engineers, because it gives them the interesting problems that keep them engaged.

The talent dimension interacts with the firm’s identity in a way that deserves conscious thought. A trading firm that builds and maintains a large lifecycle becomes, in part, a software company, and must manage as one: recruiting engineers, retaining them, documenting their knowledge, and covering their departures. If software is not the firm’s business, this is a substantial distraction from what is, and it imports management challenges, and failure modes, that a trading firm may be ill-equipped to handle. Buying the lifecycle lets the firm stay focused on being a trading firm.

Key-person risk is a specific and underappreciated hazard of building. A built system is understood by the people who built it, and if that knowledge is not rigorously documented, the departure of a few key engineers can leave the firm operating a critical system it no longer fully understands. This risk grows over time as the original builders move on and the system ages. A bought platform externalises this risk to the vendor, whose business is to maintain the knowledge across its whole team; a built one keeps the risk in-house, where a resignation letter can become an operational crisis.

Weigh the talent and key-person implications alongside the cost, because building makes the firm partly a software organisation and concentrates critical knowledge in the people who built the system. Ask whether being a software organisation serves your actual business, and whether the departure of a few key engineers could leave you operating a system you no longer fully understand. Buying externalises this risk to the vendor; building keeps it in-house, where it should be consciously accepted rather than stumbled into.

Beyond cost and talent, build and buy differ sharply in how quickly they deliver value and how much execution risk they carry. Buying a proven platform delivers a working lifecycle in the time it takes to implement and integrate it, which is measured in months and carries the relatively contained risk of a configuration and migration project. Building the same lifecycle delivers value only when the build is complete and correct, which is measured in years and carries the substantial risk that the build runs late, costs more than planned, or does not achieve the correctness the lifecycle demands.

The risk profile matters as much as the timeline. A lifecycle build is a large software project, and large software projects carry well-known risks: scope grows, complexity is underestimated, correctness proves harder than expected, and the project that was going to take two years takes four. Meanwhile the business runs on whatever it had before, waiting. Buying transfers most of this risk to the vendor, who has already borne it and amortised it. For a business whose priority is to be trading well soon rather than to own its lifecycle eventually, the time-to-value and risk difference alone often settles the lifecycle question in favour of buying.

The time-to-value gap has a strategic dimension beyond the obvious delay. While a firm spends years building its lifecycle, its competitors who bought are already trading, learning, and refining their strategies on a working platform. The building firm is not standing still by choice; it is prevented from advancing its actual business by the demands of a construction project that creates no advantage. By the time the built lifecycle is complete, the competitors have a multi-year head start on the things that matter, bought with the time the building firm spent on plumbing.

The risk asymmetry compounds the time gap. Buying a proven platform carries the contained, well-understood risk of an implementation project. Building a lifecycle carries the open-ended risk of a large, novel software development, which the industry’s track record shows runs late and over budget more often than not. A firm that builds is betting not only years but the possibility that the bet does not pay off on schedule or at all, while the business waits. For a decision this consequential, the difference in risk profile alone often settles the lifecycle question, quite apart from cost.

Weigh time to value and execution risk, not just cost, when you compare building and buying the lifecycle. A bought platform is trading in months at contained risk; a built one is trading in years, if the build succeeds on schedule, at the open-ended risk of a large software project. Ask what the delay costs your business in strategy deferred and opportunity forgone, and remember that competitors who bought are advancing while you build. For most firms this difference alone settles the lifecycle question.

This handbook argues that most of the lifecycle should be bought, but honesty requires acknowledging how buying can go wrong, because it can. A firm can buy a platform that does not fit its operation, forcing painful workarounds or expensive customisation. It can buy a platform whose architecture is legacy beneath a modern surface, inheriting all the problems the cloud-versus-legacy handbook describes. It can buy from a vendor that neglects the product, or become locked in to a platform it cannot leave. Buying is not automatically safe; it is safe only when the platform genuinely fits and its architecture is sound.

The way buying goes wrong is usually a failure of evaluation rather than a failure of the buy decision itself. A firm that buys a poorly-fitting or poorly-architected platform did not evaluate rigorously enough, which is exactly what the selecting-an-ETRM handbook exists to prevent. The lesson is not that buying is risky and building is safe, but that buying well requires the same rigour as any major decision: evaluate the architecture, test the fit against your real operation, assess the vendor, and negotiate the terms. Buying carelessly can be as costly as building the wrong thing.

Acknowledging that buying can go wrong is essential to using this handbook honestly, because a recommendation to buy that ignored buying’s failure modes would be as flawed as an unexamined urge to build. Buying goes wrong when the evaluation is shallow: a platform is chosen on its demonstration rather than its architecture, or on its feature list rather than its fit, and the firm discovers only in production that the platform does not suit its operation or that its architecture is legacy beneath a modern surface. The remedy is not to build instead but to buy properly, with the rigour the selecting-an-ETRM handbook describes.

The lock-in that buying can create is a real cost that must be weighed rather than dismissed, but it is often overstated as a reason to build. Building creates its own lock-in, to a bespoke system only your team understands, which is at least as constraining as dependence on a vendor and comes without the vendor’s ongoing investment in the product. The honest comparison is not lock-in versus freedom but one kind of lock-in versus another, and a well-chosen platform with portable data and configuration-based adaptation often imposes lighter lock-in than a home-grown system that no one else can maintain.

When you do buy, buy properly, because buying goes wrong through shallow evaluation, not because buying is inherently risky. Evaluate the architecture, test the fit against your real operation, assess the vendor as a long-term partner, and negotiate the terms, with the rigour the selecting-an-ETRM handbook describes. And weigh lock-in honestly on both sides: building creates lock-in to a bespoke system only your team understands, which is often heavier than dependence on a well-chosen vendor with portable data.

The build-versus-buy decision is not made once for the whole platform; it is made capability by capability. Some capabilities are unambiguously table stakes and should be bought: trade capture, standard valuation, standard risk, settlement. Some are unambiguously your edge and should be built: your proprietary signals, your bespoke analytics, your novel strategies. The interesting work is at the boundary, and it is done by asking of each capability whether it is a genuine source of advantage or undifferentiated plumbing, and recording the answer and the reasoning.

The differentiation assessment accompanying this handbook turns this into a structured exercise: list your capabilities, score each on how much it differentiates you and how well the market already solves it, and let the scoring sort them into build, buy, and compose-on-top. The value of the exercise is less the score than the discipline of asking the question honestly for each capability, which is exactly the discipline that confident engineers and confident desks tend to skip.

The capability-by-capability method is what turns the build-versus-buy heuristic from a slogan into a decision procedure. Rather than arguing about the firm’s technology in general, it forces a specific judgement about each capability: is this one a genuine source of advantage or undifferentiated plumbing? Made capability by capability, the decision resolves into a clear pattern for most firms, buy the lifecycle, build a small number of genuinely differentiating components, and the argument moves from the general and emotional to the specific and evidenced.

Recording the reasoning matters as much as reaching the answer, because the reasoning is what lets the decision be revisited and defended. A capability sorted into build today because it differentiates may need to be revisited in a few years if the market catches up and it becomes table stakes. A recorded rationale makes that revisiting possible, because the firm can see why it decided as it did and whether the reasoning still holds. The differentiation assessment captures this reasoning, turning the decision into a documented, revisitable record rather than a one-time judgement lost to memory.

Make the decision capability by capability and record the reasoning for each, using the differentiation assessment to structure the exercise. Sorting each capability into build, buy, or compose, and writing down why, turns an emotional general debate into a specific evidenced decision, and it produces a record you can revisit when the market shifts. The value is less the score than the discipline of asking, honestly and specifically, whether each capability is a genuine edge or undifferentiated plumbing.

A simple two-dimensional matrix organises the capability-by-capability decision usefully. On one axis is how much a capability differentiates you; on the other is how well the market already solves it. A capability that differentiates you strongly and that the market solves poorly is a clear candidate to build, because building it creates an edge the market cannot sell you. A capability that does not differentiate you and that the market solves well is a clear candidate to buy, because building it wastes effort on something you could simply acquire.

The two remaining quadrants are more subtle and repay thought. A capability that differentiates you strongly but that the market also solves well is a candidate to compose: buy the market’s solution and build your differentiation on top of it, rather than rebuilding the whole thing. A capability that does not differentiate you but that the market solves poorly is a candidate to reconsider entirely, because it may be a need you can avoid rather than a capability you must acquire. Placing each capability in the matrix, honestly, converts a vague argument into a structured decision, and the differentiation assessment tool builds this matrix from your scores.

The differentiation matrix earns its place because it makes the compose quadrant visible, which the simple build-or-buy binary hides. The most valuable insight the matrix produces is often about capabilities that both differentiate strongly and are well solved by the market: these are not to be built from scratch, which wastes the market’s solution, nor simply bought, which surrenders the differentiation, but composed, bought as a foundation with the firm’s edge built on top. Without the matrix, these capabilities are forced into build or buy, and either choice leaves value on the table.

Placing capabilities in the matrix honestly requires resisting the pull toward the build corner. Every capability feels more differentiating from the inside than it is, so the differentiation axis tends to be scored too high across the board, pulling capabilities toward build. A useful corrective is to score differentiation by the sceptic test, would a competitor with this capability be at no disadvantage, and to score market maturity by honest research into what the market actually offers. Scored honestly, most capabilities land in buy or compose, and only a few genuinely belong in build, which is the pattern the heuristic predicts.

Build the differentiation matrix for your capabilities, scoring each on how much it differentiates you and how well the market solves it, and pay particular attention to the compose quadrant that the build-or-buy binary hides. Score differentiation by the sceptic test and market maturity by honest research, resisting the pull that makes everything feel differentiating from the inside. Scored honestly, most capabilities land in buy or compose and only a few in build, which is the pattern the heuristic predicts and the matrix makes visible.

A firm that buys the lifecycle and builds its edge on top runs a hybrid estate, and that estate needs governance to stay healthy. The boundary between bought and built must be clean, mediated by the platform’s API rather than by reaching into its internals, so that the bought platform can be upgraded without breaking the built edge. The built components must be engineered and maintained to a proper standard, not left as scripts that only their author understands. And the whole must be documented, so that the firm knows what it owns, what it buys, and how the two connect.

The governance discipline that keeps a hybrid estate healthy is the same one that keeps any software estate healthy, applied to the boundary between bought and built. Version the interfaces between your code and the platform. Test your edge against new platform versions before adopting them. Keep your built components thin and well-defined, so they are cheap to maintain and easy to reason about. A hybrid estate governed this way gives the firm the best of both, the amortised lifecycle and the owned edge, while an ungoverned one can become a tangle in which the built and bought parts are so entwined that neither can change safely.

Governing the hybrid estate is what makes the both option sustainable rather than a slow slide into a tangle. The discipline is to treat the boundary between bought and built as a managed interface, not a blurred edge: your code calls the platform’s API and subscribes to its events, but never reaches into its internals, so the platform can be upgraded without breaking your edge. This clean boundary is what lets the two halves of the estate evolve independently, the platform through its upgrades and your edge through your development, without each breaking the other.

The failure mode a governed boundary prevents is the estate in which built and bought are so entwined that neither can move. This happens when built components depend on internal details of the platform rather than its supported interfaces, so that a platform upgrade breaks the built code, which discourages upgrades, which freezes the platform, which ages the whole estate. Keeping the built components thin, well-defined, and dependent only on governed interfaces is what keeps the estate healthy, and it is the same engineering discipline that keeps any software system maintainable, applied deliberately to the bought-built boundary.

If you pursue the both option, govern the boundary between bought and built deliberately: have your code depend only on the platform’s supported, versioned interfaces, never its internals, so platform upgrades and your edge can evolve without breaking each other. Keep built components thin and well-defined, and test them against new platform versions before adopting. This is the discipline that keeps a hybrid estate healthy rather than letting it drift into a tangle where neither the bought nor the built half can move.

Buying the lifecycle means entering a long relationship with a vendor, and that relationship should be evaluated and governed as deliberately as the platform itself. A good vendor invests in the product, supports its customers, and treats the relationship as a partnership; a poor one extracts rent from a captive customer. Because switching platforms is costly, the buyer has most leverage before signing and least after, which is why the vendor relationship, the support commitments, and the exit terms should be negotiated up front rather than left to be discovered later.

Lock-in is the risk that shadows every buy decision, and it should be assessed rather than ignored or feared. The relevant questions are concrete: how portable is your data if you leave, how much of your adaptation lives in customisation that cannot be moved, and what would switching actually cost? A platform that keeps your adaptation in configuration and supported extensions, and that lets you extract your data cleanly, imposes lighter lock-in than one that requires customisation and holds your data in proprietary forms. Lock-in cannot be eliminated when you buy, but it can be understood and limited, and it should be weighed as part of the decision rather than treated as an unmentionable.

The vendor relationship is a long-term dependency that deserves the scrutiny of a partnership rather than the casualness of a purchase, because switching is costly and the relationship will shape the firm’s operation for years. Evaluate not only the platform but the vendor: does it invest in the product, support its customers well, and behave as a partner, or does it treat customers as captive revenue? The vendor’s track record with existing customers, especially through difficult moments, predicts the relationship you are entering far better than its sales behaviour does.

Negotiating exit terms up front feels pessimistic but is simply prudent, because it is the moment of maximum leverage and the terms protect against the relationship souring. Data portability, the right to extract your data in a usable form, and clear terms for what happens if you leave, are cheap to secure before signing and expensive or impossible to secure after. A vendor confident in its product will not resist reasonable exit terms; resistance to them is itself informative. Securing these terms does not signal an intention to leave; it ensures that staying remains a choice rather than a trap.

Treat the vendor relationship as a long-term partnership to evaluate, not just a product to buy, and negotiate exit terms, especially data portability, up front, while your leverage is greatest. Examine the vendor’s track record with existing customers through difficult moments, which predicts your relationship far better than its sales behaviour. Securing reasonable exit terms does not signal an intention to leave; it ensures that staying remains a choice, and a vendor confident in its product will not resist them.

Certain build-versus-buy mistakes recur across trading businesses, and naming them helps a firm avoid them. The most common is building the lifecycle out of a belief that the firm’s needs are uniquely special, when in truth they are variations a bought platform could configure. Another is the sunk-cost trap: having started to build, a firm continues long past the point where buying would have been better, because abandoning the build feels like waste. A third is buying carelessly, treating the buy decision as low-effort and ending up with a poorly-fitting platform.

A subtler failure mode is building the edge and the plumbing together, so that the genuinely differentiating code is buried inside a reimplemented lifecycle and cannot be separated from it. This squanders the advantage of the edge by tangling it with undifferentiated maintenance, and it locks the firm into maintaining the whole mass forever. The remedy for all these failure modes is the discipline this handbook teaches: decide capability by capability, count the true costs, keep the edge thin and separate, and hold both build and buy decisions to rigorous evaluation.

The sunk-cost trap deserves particular vigilance because it turns one build mistake into a compounding one. Having invested in building, a firm feels that abandoning the build wastes what it has spent, so it continues, spending more, long after the evidence says buying would be better. But the money already spent is gone whichever path is taken; the only question that matters is which path is cheaper from here. A firm that can set aside sunk cost and decide forward, on the remaining cost of finishing the build versus the cost of buying, will escape the trap; one that cannot will keep pouring money into a decision it should reverse.

The entangled edge is the failure mode that most directly defeats the purpose of building. A firm builds to create a differentiating edge, but if it builds that edge tangled into a reimplemented lifecycle, it has buried its advantage inside a mass of undifferentiated code it must now maintain forever. The edge that was supposed to be a thin, high-value layer becomes inseparable from the plumbing beneath it, and the firm gets the maintenance burden of building the lifecycle without cleanly capturing the value of its edge. Keeping the edge thin and separate is what prevents this, and it requires deliberate architectural discipline.

Guard against the two failure modes that most often defeat a build: the sunk-cost trap and the entangled edge. Decide forward on the remaining cost of finishing a build versus buying, setting aside what is already spent, so a bad build is not compounded by finishing it out of regret. And if you build an edge, keep it thin and separate from any lifecycle beneath it, so your advantage is not buried in undifferentiated code you must maintain forever. Both failures are avoidable with deliberate discipline.

Analytics and reporting deserve specific attention, because they are where the build-versus-buy line is most often drawn in the wrong place. Standard reporting, regulatory reports, and conventional analytics are table stakes: every platform provides them, and building them in-house creates no edge. But the analytics that embody a firm’s specific view of the market, its proprietary risk measures, its bespoke performance analysis, may genuinely differentiate, and those are candidates to build, ideally on top of the platform’s governed data rather than on a separate export.

The both option is particularly powerful for analytics. A platform with a governed model and a good API lets a firm build its proprietary analytics directly on trusted operational data, inheriting the correctness of the governed model rather than re-establishing it on an export. This is the ideal shape: buy the lifecycle and the standard analytics, and build the differentiating analytics on top of the same governed data, so the firm’s special insight is computed on numbers it already trusts. Building analytics on a separate exported copy, by contrast, reintroduces the reconciliation and trust problems the governed model was meant to solve.

Analytics is where the both option shows its value most clearly, because analytics is where a firm’s specific insight most naturally lives. Standard reports are table stakes and should be bought, but the analysis that embodies how a firm uniquely sees risk, performance, or opportunity can be a real edge, and it is best built on the platform’s governed data rather than on a separate export. Building differentiating analytics on trusted operational data lets the firm’s insight operate on numbers it already trusts, inheriting the correctness of the governed model instead of re-establishing it.

Building analytics on a separate export is a common and costly mistake that reintroduces the very problems a governed platform solves. The export is a copy, and a copy can diverge from the operation, so analytics built on it must be reconciled before anyone trusts them, which returns the firm to the copy-and-reconcile world it was trying to leave. Building differentiating analytics directly on the platform’s governed data, through its API, avoids this entirely, which is why the quality of the platform’s data access is as important for analytics as for any other part of the both option.

For analytics, buy the standard and regulatory reporting and build only the analysis that embodies your specific insight, and build it on the platform’s governed data through its API, not on a separate export. Building differentiating analytics on trusted operational data lets your insight operate on numbers you already trust; building it on an export reintroduces the copy-and-reconcile problems a governed platform solves. The quality of the platform’s data access is therefore as important for analytics as for any other part of the both option.

Open-source components complicate the simple build-versus-buy binary in a useful way, because they offer a third source of capability that is neither fully built nor fully bought. A firm can adopt an open-source library for a well-defined technical function, a pricing library, a numerical toolkit, rather than building it or buying it as part of a platform. Used well, open source lets a firm avoid reinventing solved technical problems while retaining more control than a proprietary platform gives. Used carelessly, it becomes a maintenance burden the firm has taken on without fully realising it.

The discipline for open source is the same as for building: an adopted open-source component is a dependency the firm must understand, keep current, and maintain the integration of, so it should be adopted where it clearly saves effort over building and where its maintenance burden is acceptable. Open source is most valuable for well-bounded technical capabilities with strong community support, and least suitable as a substitute for the integrated, governed lifecycle a platform provides. It is a tool in the build-versus-buy toolkit, to be used deliberately for the right capabilities, not a blanket alternative to either building or buying.

Open source is best understood as a third option alongside build and buy, with its own profile of benefit and burden, rather than as a free alternative to either. A mature open-source library for a well-bounded technical problem can save a firm from reinventing solved work while giving more control than a proprietary component, which is genuinely valuable for the right capabilities. But adopting it is a form of building: the firm takes on the dependency, must keep it current, and must maintain its integration, so the maintenance burden that makes building expensive applies to open source too, just at a smaller scale.

The judgement for open source is therefore the same as for building, applied to a narrower question: does adopting this component save enough effort over building it to justify the maintenance burden of owning the dependency? For well-bounded technical capabilities with strong communities, the answer is often yes. For the integrated, governed lifecycle, the answer is usually no, because no open-source assembly matches what a mature platform provides, and stitching one together recreates the surface area and maintenance of building. Open source is a precision tool for specific capabilities, not a blanket substitute for buying the lifecycle.

Treat open source as a precise tool for well-bounded technical capabilities, not a blanket alternative to buying, and apply the same maintenance-burden test you would to building. Ask whether adopting a component saves enough effort over building it to justify owning the dependency and maintaining its integration. For mature libraries with strong communities the answer is often yes; for the integrated, governed lifecycle it is usually no, because stitching one together recreates the surface area and maintenance that buying avoids.

The build-versus-buy decision is not made once and settled forever; it should be revisited as the business and the market change. A capability that differentiated you when you built it may become table stakes as the market catches up, at which point maintaining your own version is no longer worth it and buying makes sense. Conversely, a capability you bought may become a place where you could build an edge as your strategy evolves. Treating the decision as permanent risks maintaining a built capability long after it stopped differentiating, or missing a new opportunity to build.

A periodic review of the estate against the differentiation matrix keeps the decision current. Ask, for each significant built component, whether it still differentiates, and for each bought capability, whether it has become a place to build. This review prevents the slow drift in which a firm keeps building what it has always built and buying what it has always bought, regardless of whether those choices still fit. The differentiation assessment is not a one-time exercise but a lens to reapply as the business evolves, so the estate keeps matching the firm’s actual sources of advantage.

Revisiting the decision matters because the differentiation landscape shifts under the firm’s feet. What differentiates today may be table stakes in three years as the market catches up, at which point the firm is maintaining a built capability that no longer earns its keep, and should be retired in favour of buying. The opposite also happens: a capability bought today may become a place to build an edge as the firm’s strategy evolves. A decision treated as permanent misses both shifts, keeping stale builds and missing new opportunities.

A periodic review against the differentiation matrix is inexpensive insurance against this drift. Once a year or so, walk the estate and ask, for each built component, whether it still differentiates, and for each significant bought capability, whether it has become somewhere to build. Most items will not move, but the few that do are exactly the ones where continuing on inertia would waste effort or forgo advantage. The differentiation assessment is designed to be reapplied this way, so the estate keeps matching the firm’s actual, evolving sources of edge rather than the sources it had when the decisions were first made.

Schedule a periodic review of the estate against the differentiation matrix, because what differentiates shifts over time: today’s edge can become tomorrow’s table stakes, and a bought capability can become somewhere to build. Once a year or so, ask of each built component whether it still differentiates and of each bought capability whether it now could. Most will not move, but the few that do are exactly where inertia would waste effort or forgo advantage, and the differentiation assessment is designed to be reapplied this way.

A decision of this magnitude should be governed, documented, and defensible, because it commits the firm’s money, engineering, and years of maintenance obligation. The governance is not bureaucracy; it is the discipline of recording what was decided, for which capabilities, on what reasoning, and against what alternatives, so that the decision can be explained to a board and revisited later on its merits. A build-versus-buy decision made informally, in the confidence of a strong voice, is one the firm cannot later examine or defend when its consequences arrive.

The tools accompanying this handbook exist to make the decision documented and defensible. The total-cost model records the full cost of each path, with visible assumptions. The differentiation assessment records the capability-by-capability reasoning that sorted each into build, buy, or compose. Together they turn a decision that is often made on instinct into one made on evidence, which is what a board is right to expect for a commitment this large. Governing the decision this way also makes revisiting it easier, because the reasoning is recorded and can be re-examined as circumstances change.

Governing the decision is what separates a considered choice from an expensive guess, and it matters most precisely because the decision is so consequential and so contested. When the reasoning is documented, capability by capability, with the costs modelled and the alternatives recorded, the firm has a decision it can explain to its board, defend under scrutiny, and revisit on its merits. When the decision is made informally, in the confidence of a persuasive advocate, the firm has a commitment it cannot later examine, because the reasoning that produced it was never captured.

The documentation also disciplines the decision as it is being made, not only after. The act of recording why each capability was sorted into build, buy, or compose forces the reasoning to be explicit, which exposes weak arguments that would survive an informal discussion. A capability that someone insists should be built often looks different once the rationale must be written down and stand next to its cost, because the discipline of documentation is also the discipline of honest reasoning. Governing the decision improves it, not just records it.

Document the decision, capability by capability, with the costs modelled and the alternatives recorded, so it can be explained to your board, defended under scrutiny, and revisited on its merits. The discipline of writing down why each capability was sorted as it was exposes weak arguments that survive informal discussion, so governing the decision improves it as well as recording it. The tools accompanying this handbook produce exactly this documentation, turning an instinct-driven commitment into an evidence-driven, revisitable record.

Bring the threads of this handbook together into a structured, capability-by-capability decision. For each significant capability, ask whether it genuinely differentiates you and how well the market already solves it, and let those answers place it in build, buy, or compose. Count the true cost of each path, including the perpetual maintenance and opportunity cost that building incurs. Weigh time to value and execution risk. And govern the decision so it is documented and defensible. The result is not a single build-or-buy verdict but a portfolio of deliberate choices, each right for its capability.

The discipline this handbook teaches is, in the end, to resist the two easy answers. Building everything indulges the engineer’s confidence and squanders the firm’s effort on undifferentiated plumbing. Buying everything with no ability to build surrenders the possibility of an edge. The right answer is almost always to buy the lifecycle, build the edge, compose the two on a genuinely API-first platform, and keep revisiting the boundary as the business evolves. Make that decision capability by capability, on your own evidence, and your engineering effort will go where it creates advantage rather than where it merely keeps the lights on.

The portfolio that results from a capability-by-capability decision is more robust than any single verdict, because it is right in the small even where a blanket answer would be wrong. Buy-everything is wrong wherever the firm has a genuine edge to build; build-everything is wrong wherever the capability is table stakes, which is almost everywhere. The portfolio captures the right answer for each capability, buying the vast undifferentiated lifecycle, building the few genuinely differentiating components, and composing where a bought foundation can carry a built edge. No single verdict can match this, because no single verdict fits every capability.

The final discipline is to hold to the portfolio against the pressures that will push it back toward an extreme. Engineers will want to build more than they should, because building is what they do well; finance will want to build less, or buy more cheaply, than serves the edge. The portfolio, made on evidence capability by capability and documented, is the defence against both pressures, because it grounds each choice in whether that specific capability creates advantage. Return to it, revisit it as the business evolves, and let it, rather than the loudest voice, decide where the firm’s engineering effort goes.

Hold to the portfolio your capability-by-capability analysis produces against the pressures that will push it toward an extreme, and let the evidence, not the loudest voice, decide where your engineering effort goes. Buy the vast undifferentiated lifecycle, build the few components that genuinely create an edge, compose where a bought foundation can carry a built edge, and revisit the boundary as the business evolves. Made this way and documented, the decision will serve the firm’s advantage rather than anyone’s confidence, which is exactly what a decision this consequential should do.