Build, Reuse or Buy: How We Decide

Every new capability in our platform starts with a decision that shapes everything after it. Should we build this ourselves? Do we already have something that does it? Should we rely on an outside provider whose whole business is solving this problem?

Getting that decision wrong in either direction is expensive. Building what we should have bought wastes time and creates risk. Buying what we should have built leaves us dependent on someone else's priorities. Here is how we reason through it.

Option one: reuse what already exists

The first question is always whether the platform already has the capability, or most of it. Our modules share a media library, a payment path, a permission system, a content store, a communications system and more. Many new features turn out to be a new screen on top of an existing service.

Reuse is almost always the best option when it fits. It is faster, it keeps behavior consistent and it adds nothing new to maintain. That is why our first step in any work is to read the existing code.

Option two: build what makes us distinct

We build things ourselves when they are central to what our products are for, or when owning them gives customers something they could not otherwise have. Examples include the visual page builder that organizations use daily, website importers that bring entire sites across without leaving dependencies behind and our own realtime updates service that keeps pages current without depending on a third-party push service.

Building is a long-term commitment. Before we build, we ask whether we are prepared to maintain, secure and improve this capability for years.

Option three: rely on specialists

Some problems are best solved by companies that focus entirely on them. Payment processing is the clearest example. Handling card data, fraud detection, bank networks and global regulations is a full-time specialty. We rely on a payment processor for that work and build our own value on top: invoicing, subscriptions, accounting and the customer experience. You can read more in why card numbers never touch our servers.

Other examples include domain registration, video streaming infrastructure, mapping data and AI models. In each case, the provider handles a deep specialty while we handle how it fits into our customers' work.

Questions we ask

A few questions guide the decision:

1. Is it central to our purpose? Central capabilities are worth owning.
2. Would building it require expertise we do not have? Some specialties take years to master.
3. What happens if a provider changes or disappears? If the answer is "our customers lose their data," we design for portability or build it ourselves.
4. What does it cost to maintain? Building is cheap at the start and expensive over time.
5. Does it touch customer data or money? Those areas need extra care whichever option we choose.

Wrapping providers carefully

When we rely on a provider, we wrap it in our own service layer. Our code talks to our service; the service talks to the provider. That keeps provider details in one place, makes it possible to change providers if needed and lets us apply our own rules, such as registration of AI calls, permission checks and usage metering, consistently.

We also avoid scattering a provider's keys or assumptions across many modules. One place to configure, one place to secure.

Avoid lock-in where it hurts

Some dependencies are fine. Others would trap customers. We try to make sure customers can take their content and data with them, that their files live in their own storage and that their payment accounts are their own. When dependencies exist, they should be dependencies on standards and services that can be replaced, not on something that holds customers hostage.

Revisit decisions over time

A good decision today may not be good in three years. Providers change prices and policies. Our own needs grow. We revisit major build, reuse or buy decisions when circumstances change, rather than treating them as permanent. Plans for running more of our own infrastructure, for example, are studied carefully and only acted on when they are clearly better for customers.

Frequently asked questions

When should a company build software instead of buying it?

Build when the capability is central to your purpose and you can maintain it long-term. Buy or rely on providers for deep specialties outside your focus.

What is the risk of relying on a provider?

Providers can change prices, policies or availability. Wrapping them in your own service layer and keeping customer data portable reduces that risk.

Why reuse existing code before building new features?

Reuse is faster, keeps behavior consistent and adds no new maintenance, so it should always be considered first.