Every wealth management firm eventually faces the same question: should we build this, or buy it?

The firms answering it well have stopped treating it as a binary. The real question is more precise: where in our technology stack does building create a durable competitive advantage, and where does it just create maintenance?

The triangle framework.

One model that surfaced at the Pershing Insite technology panel is worth borrowing. Think of your technology stack as a triangle. The broad base is the infrastructure that runs across the firm — data management, integration, core platforms. The narrow tip is where your firm does something genuinely different from every other firm in your market.

The base should almost always be bought. Not because custom infrastructure is technically impossible, but because it produces no competitive differentiation. An RIA that builds its own portfolio accounting system from scratch has a portfolio accounting system. It’s not faster, smarter, or more defensible than a well-implemented third-party platform — it’s just more expensive to maintain and harder to upgrade.

The tip is where building makes sense. If your firm has a proprietary model for household segmentation, a unique approach to proposal generation, or an integration pattern that creates a client experience no one else can replicate — that’s worth building. That’s strategy, not infrastructure.

The firms that lose this decision build too much of the base.

What “stewardship” actually means.

Mid-sized firms, in particular, hear this framework and sometimes interpret it as settling for commodity technology. That’s the wrong read.

Being a steward of technology means actively managing which capabilities you own and which you consume. It means demanding integration quality from vendors rather than accepting gaps and working around them. It means selecting platforms that fit together, not platforms that require custom glue.

Stewardship is not passive. It’s a different kind of active. Instead of engineering integration from scratch, the energy goes into evaluating integration depth before selection, negotiating for data access, and treating the technology stack as a managed portfolio rather than an accumulation of point solutions.

The Pershing Insite panel framed this as focusing integration work as a core differentiator — not the integration itself, but how the firm manages the integration layer. That’s the leverage point for mid-sized firms that can’t compete with enterprise build budgets.

The honest enterprise version.

Larger firms face a different version of the same decision. The panel surfaced one clear principle from an enterprise perspective: know where you’re genuinely good at building and where you’re not.

That sounds obvious. It isn’t practiced consistently. Enterprise technology teams often justify internal builds based on organizational inertia — existing teams, existing infrastructure, the pull of “we should own this.” The discipline is in the honest self-assessment: would a best-in-class external partner do this better? If yes, buy.

The math shifts at enterprise scale. Some things that make sense to buy at $5B AUM make sense to build at $500B — but only because the volume of use justifies the development cost and the customization creates compounding value. The framework doesn’t change. The inputs do.

The question under the question.

When a wealth management firm asks “should we build or buy?”, they’re usually asking something else: how do we stay competitive without exceeding what our technology team can realistically deliver?

The honest answer requires knowing your technology team’s actual capacity, your differentiation thesis as a firm, and where in your stack a vendor’s update cycle is likely to outpace anything you could build internally.

Most wealth management firms, at most sizes, should be buying most of what they run and building only where the tip of that triangle gives them something no one else can offer.

The firms that get this right aren’t the ones who found cheaper vendors. They’re the ones who became precise about the question.