When to Build From Zero
A framework for 0-to-1 product investment at incumbents
In January 2026, Capital One announced it would acquire Brex for $5.15 billion. The deal — one of the largest bank-fintech combinations ever announced — was a direct response to a competitive dynamic that has been building in corporate cards and business spend management for half a decade: a cohort of digital-native fintechs (Brex, Ramp, Mercury, and others) have been quietly taking share from traditional card issuers in the middle-market segment by offering something incumbents have struggled to match: fully digital, self-serve onboarding paired with modern expense management software.
Every major corporate card issuer is now facing some version of the same question. The digital-native challengers have exposed a structural gap. The question is what to do about it.
There are three possible answers: build from zero, acquire, or extend existing infrastructure. Most of the 0-to-1 product literature — written largely by startup founders and venture capitalists — treats "build from zero" as the default heroic choice. At incumbents, it rarely is. Building from scratch inside a large financial institution is expensive, politically difficult, and slow by startup standards. It should be chosen only when the alternatives are worse.
Having spent six years building digital products at the intersection of fintech, credit risk, and regulated markets, I've come to believe that the build-vs-buy-vs-extend question deserves a sharper framework than it usually gets. What follows is that framework — with the caveat that every real decision is messier than any framework suggests.
The three responses, and what each actually costs
Existing stack competitive
Strong internal capability
Credible target exists
Extending existing infrastructure is what incumbents do by default. It's cheap, fast, and low-risk. A digital layer gets added to a legacy process. A new API wraps an old system. A new front-end calls the same underwriting engine. Extension works when the underlying capability is still competitive — when the problem is really just that customers want a different surface on something that fundamentally works.
Extension fails when the bottleneck isn't the surface. If the legacy process runs sequentially where the new competitive standard is parallel, you can build the prettiest digital front-end in the industry and customers will still experience a slow, frustrating flow. The surface lies about the substance.
Acquiring solves the capability gap by buying it whole. This is Capital One's answer with Brex — rather than close the gap internally, purchase the company that has already closed it. Acquisition works when (1) a credible target exists at a reasonable price, (2) time-to-market matters more than differentiation, and (3) the incumbent's starting point is far enough from the target state that building would take years. The Capital One/Brex deal appears to fit all three conditions: Brex is mature, the middle-market competitive window is closing, and building a Brex-equivalent platform from scratch at Capital One's scale would likely take longer than integrating Brex will.
Acquisition's hidden cost is integration risk. The history of bank-fintech acquisitions is littered with examples where the acquired company's culture, talent, or technology failed to survive contact with the acquirer's processes. Paying a premium for a fintech only to have its best engineers leave in eighteen months is a common and expensive failure mode.
Building from zero is the most expensive and slowest option on paper, but it produces something the other two can't: full control of the roadmap and an asset that is natively compatible with the rest of the incumbent's stack. Building works when (1) the incumbent's existing engineering capability is strong enough to execute at a reasonable pace, (2) the gap is architectural rather than product-feature-level, and (3) maintaining strategic control of the capability matters for reasons beyond the immediate competitive response.
The argument for building that I find most persuasive is the one that's rarely made explicitly: if the incumbent's existing capabilities already contain 60–70% of what the new platform needs, buying a competitor means paying a premium largely for capabilities you already have. The math of acquisition changes dramatically depending on how close the incumbent's starting point is to the target state.
A decision test
Given those three options, how should a product leader at an incumbent decide? I'd propose a three-part diagnostic. It's imperfect, but it's more useful than the usual "build vs. buy" framing, which collapses important distinctions.
1. Where is the gap? Is it in the acquisition channel, in the process architecture, or in a post-sale capability like expense management or reporting?
A channel gap alone can often be extended. A process architecture gap usually can't — if the legacy system's sequencing, data model, or compliance assumptions are wrong, wrapping them in a new UI produces a worse experience than leaving them alone. A post-sale capability gap is often best solved by acquisition, because mature standalone tools usually exist and building one from scratch is reinventing a solved problem.
2. How much of the target state already exists internally? This is the question that separates Capital One's Brex decision from a hypothetical incumbent that decides to build instead.
If your existing stack contains most of the components and you're missing orchestration or a front-end, building is probably right. If you're missing core capabilities — a modern data platform, a unified ledger, AI-native automation — the math tips toward acquisition, because the time and cost to build those foundations is often underestimated by an order of magnitude.
3. How contested is the competitive window? If the segment you're defending is in rapid share erosion, twelve months matters. Acquisition collapses time. Building extends it. If the segment is slower-moving or the incumbent's position is more defensible, the time premium for acquisition may not be worth paying.
The interesting cases are where the answers to these three questions point in different directions. A channel gap with a short competitive window but strong existing infrastructure is the classic "build the missing piece fast" scenario. A multi-layer gap with a short window and weak existing capability is the classic "acquire" scenario. A multi-layer gap with a long window and strong existing capability is where building becomes genuinely attractive — and where Capital One's competitors may find themselves.
What the 0-to-1 literature gets wrong about incumbents
Most writing about building from zero assumes the builder starts with nothing. For startups, that's accurate and liberating. For incumbents, it's neither.
The startup 0-to-1 playbook emphasizes speed, minimum viable product, and learning loops. These principles translate poorly to a regulated financial institution building a platform that has to pass credit, compliance, and fraud review before it sees a single customer. The MVP of a corporate card onboarding flow is not "a landing page and a form" — it's a landing page, a form, a KYC pipeline, a credit decisioning layer, a fraud check, a compliance audit trail, and an integration with a core banking system. The scope floor is much higher.
What this means in practice is that incumbents building from zero need to be ruthlessly honest about which components are genuinely new and which are being rebuilt out of habit or organizational politics. A 0-to-1 project at an incumbent that rebuilds twelve components when four would have sufficed is not a bold bet — it's a slow, expensive extension dressed up as a rebuild. The discipline to say "we'll use the existing credit engine and build only the orchestration layer" is the hardest and most valuable muscle an incumbent product team can develop.
Conversely, the discipline to recognize when a component must be rebuilt — because the legacy version encodes assumptions that are incompatible with the new competitive standard — is equally important and often culturally harder, because it means telling a team that owns a working system that their system is the problem.
Where this leaves incumbents in corporate cards
The Capital One/Brex deal is the most visible move in a broader strategic shakeout. Other major issuers face the same threat and will make different choices. Some will acquire. Some will build. Some will extend and hope the digital-native cohort stalls before their market share does.
My bet — and this is genuinely a bet, not a prediction — is that the winners of this cycle will be the ones that resist the instinct to pick one response and instead match each capability gap to the right response. Build the acquisition channel from zero because extending a sales-assisted flow can't match a self-serve digital one. Acquire expense management because the category is mature and building is reinventing. Extend existing credit and fraud capabilities because they're still competitive and rebuilding them would be expensive theater.
That portfolio approach is less clean than "we bought Brex" or "we built our own Brex." It doesn't generate a $5 billion headline. But it may produce better economics, lower integration risk, and a platform that's natively compatible with the incumbent's existing strengths rather than welded awkwardly onto them.
The question every product leader at an incumbent should be asking is not "should we build or buy?" It's "what's the shape of our gap, and what's the right response to each piece of it?"
The answers will look different at every institution. But the discipline of asking the question at that level of granularity — rather than defaulting to the most visible option — is what separates incumbents who survive the fintech cycle from those who get acquired during it.
The views expressed in this article are the author's own and do not represent the views of any employer or organization.