Making Build or Buy Calls for Software and Services

The decision usually comes down to how much of your competitive advantage lives in that specific piece of functionality. If a solution is genuinely undifferentiated, something like payment processing infrastructure or standard reporting, buying makes sense almost every time. But when the feature touches how your product actually wins in the market, building gives you control you can’t get any other way.

The criterion that has tipped this call most reliably for us is long-term flexibility versus short-term speed. We worked with a fintech client evaluating a white label payment system for a new product. On paper, the white label option looked faster and cheaper. But once we ran a proper discovery phase, mapping user flows, evaluating the provider’s API limitations, and stress testing how the system would need to scale, it became clear the platform would hit a ceiling within eighteen months. We ended up recommending custom development instead, because the client’s roadmap depended on capabilities the white label vendor simply couldn’t support without significant rework down the line.

My advice to anyone facing this decision is to resist evaluating cost and timeline in isolation. Run a real discovery process first. Map out what you need today and what you’ll need in two years, then evaluate whether an off the shelf option can actually stretch to meet that second requirement. Too many teams buy for the demo and end up rebuilding within a year anyway, at which point they’ve paid twice.

The criterion: buy the system of record, build the workflow.

A system of record holds data you cannot afford to lose or reconstruct. Customers, invoices, contracts, tasks. Someone else’s uptime, compliance, backups, and export path are worth paying for, and at 15 people I have no appetite for owning that liability. We pay for a CRM, we pay for project management, and I would pay more without arguing.

A workflow is where the work happens. Every off-the-shelf workflow tool bends your process into the shape its founders imagined, then you pay monthly for the mismatch and quietly assign a human to cover the gap.

The call that taught me the line: client reporting. Three viable products, between $200 and $400 a month, all of them competent. Then I looked at what each actually required. Every one needed its data mapping maintained by a person every time a client account changed, and that mapping was the entire job. The subscription was buying a dashboard, not the labour. We built ours instead. A few weeks of work, no monthly line, and it reads our data in our shape rather than translating it into someone else’s. Same test on our proposal tooling. Built it.

What has shifted underneath this: AI made building far cheaper than it was two years ago. The default of buy unless it is strategic was written when internal software meant a developer for six months. That is no longer the price. I think most bootstrapped teams now under-build, and the tell is a stack of subscriptions that each solve 70 percent of a problem while somebody on payroll absorbs the other 30.

The record layer has not changed. Keep buying that. I have watched a company lose a year rebuilding a CRM it should have rented.

The question I ask is not “can I build this?” but “will I have to explain it?” I buy what I only have to trust. I build what I have to explain.

I run VolRadar, an options analytics platform, as the sole operator. Raw market data gets purchased from outside. I have no competitive advantage in running an exchange feed myself, and if a vendor goes down, that is a problem I can solve by switching providers. But every figure derived from that data is built here: the volatility measures, the ranking logic, the end-of-day pipeline. The goal is not to write better code than a standard library. It is that users ask me what a number means and which day’s data it came from. If the answer sits inside a system I cannot see into, I cannot give it, and a question I cannot answer becomes a support ticket that stays open.

On the calls that matter most, I look at who has to apologize when it breaks. If a failure means I email a vendor and wait, buying is fine. Billing, email delivery and error monitoring all work that way. If a failure means a user emails me and I have to defend the method, that piece has to be mine, even when the ready-made option is cheap.

Early on I made the error of doing the opposite. I bought a convenience layer for something users questioned constantly, then spent more time working out its internal behavior than building it myself would have taken. Buying does not remove the work when the thing is customer-facing. It moves the work somewhere I have less control over.

The single criterion that tips a build versus buy call for us is whether the off-the-shelf option can actually follow our client’s specific data, not just perform a generic version of the task. We’re building an internal Adobe Premiere Pro extension, called Edit Pulse, that analyzes raw footage, finds hooks and strong angles, cleans up filler words in the timeline, and generates an editing plan with B-roll suggestions and call-to-action placement, all tied directly to that specific client’s brand guideline document.

No off-the-shelf tool does that last part. Generic AI editing tools can flag filler words or suggest a hook in isolation, but they don’t know a specific client’s branding, tone, or what a specific client’s past approved videos looked like. We already build a detailed guideline document for every client we onboard, so building Edit Pulse around that existing data made far more sense than buying a tool that would ignore it entirely.

Cost sealed it. We’re only paying for API access to build and run it, no separate software license, no per-seat pricing stacking up across 45 editors. And because we own it, every editor’s real usage keeps improving how it performs, something a purchased tool would never let us touch.

The lesson: buy when the need is generic, build when the tool needs to know something specific about your business that no vendor will ever have access to.

I’m not a huge fan of requirements documents because they usually start describing a solution before people even articulate the real problem. Before I make a decision about building something internally vs. buying something off the shelf, I usually watch people do their jobs, and I pay a lot of attention to where they slow down. When people hesitate at exactly the same spot between screens, spreadsheets, or approvals, that tells me a specific feature is missing. But when different people hesitate in different spots, I usually conclude that the process is just still unsettled, and no solution will fix that.

That approach has shaped a lot of decisions. I have bought a software solution that was clearly not perfect because the process friction was actually coming from inconsistent habits, and no custom feature would have helped. I have also built tools that were far smaller than people requested because the hesitation happened at exactly one step, and the problem could be solved by a single feature. I have learned that people are rarely able to describe where a process feels slow, but they reveal it every day through their hesitations.

We make the build-versus-buy call on cost per qualified view, not sticker price, because a cheap tool that produces views nobody wanted is the expensive option. When we modeled it across our own clipping work, the break-even was clear: below roughly fifty clips a week the AI tooling wins on unit cost, and above that a managed service wins because human judgment on hooks and retention stops being the bottleneck. To avoid a long procurement cycle, we pressure-test any buy with a fast pre-qualification triangle, integration evidence, conformance posture, and deployment fit, which surfaces a bad option in under half an hour. That keeps us from buying a tool that demos well and dies in production. Volume and quality both live in that cost-per-view number, which is why we run short-form clipping (https://forkoff.xyz/services/clipping) as a cost-per-qualified-view system, having processed more than five billion views.

We make this call on nearly every project, because a client site can be a custom build or a Webflow build, and the tempting answer is almost always the custom one.

The criterion that has never failed me is asking who needs to change this thing next month, and how often. If the answer is a marketer who wants to swap a headline on Tuesday afternoon, buying beats building every time. A custom stack means that change goes through a developer, waits for a deploy, and probably slips a week.

We build custom only when the thing is the product itself, or when it genuinely does not exist off the shelf.

The lesson underneath it is that build or buy is rarely a capability question. It is a question about who gets blocked later.

The criterion that most reliably tips the call is whether we are prepared to staff the thing indefinitely, not whether we can build it. Building version one is rarely the hard part and often looks cheap. The real commitment is the years afterwards: fixes, security patches, upgrades, and keeping pace with vendors whose entire business is that one capability. So when a need emerges I ask what the owning team looks like in year three. If the honest answer is that nobody will own it and it will quietly rot, we buy, even when building looks faster today. Building wins when the need sits close to what makes the product distinctive, because then the ongoing investment is work we would want to fund anyway. The pattern that teaches this lesson is common to most engineering estates: internally built tools that outlive their authors and become nobody’s job. An unmaintained in-house system can be worse than either clean option, and that is the outcome this criterion exists to avoid.

The criterion we trust most is the cost of future dependence, not the purchase price. A tool may look affordable at first but become expensive if every important change means waiting or adjusting our workflow to fit someone else’s approach. We work in a space where content structure, audience paths, and credibility matter. That is why we pay close attention to how much control we keep over our work.

We look beyond the early cost and ask what keeping control will mean over time. If losing control would slow testing or reduce quality, we choose to build. If the capability is common and dependence does not create a real problem, we choose to buy. The biggest cost is often not money but the loss of good judgment and flexibility.

There is one criteria above all else, however, which dictates whether I include something or not: does this technology directly determine the end-user experience in terms of latency and reliability? It was an extremely painful lesson we had to learn, whereby we had to tear out a third party’s speech routing system that caused about 400 milliseconds worth of jitter in our voice agents. If a technology is getting better and less expensive by virtue of itself alone, then we will buy and route across vendors for cost and quality purposes. Otherwise, we build it ourselves.

When a need pops up at Sunny Glen Children’s Home, I decide build versus buy by asking what keeps our team free to care for kids instead of wrestling with tools. We’ve served more than 25,000 children since 1936 from our base in San Benito, Texas, across the Rio Grande Valley, and that long run shows one criterion that reliably tips every call: will this choice protect staff time for restoring hope, or will it drain us into upkeep that pulls people away from the children?

I’m talking real services here, care and residential programs, Supervised Independent Living at the Allen House for youth 18-21, counseling through the Poenisch Counseling Center, and support for refugee kids. Resources stay tight, so we prioritize hard. If an off-the-shelf option covers the core need and we can get people trained fast, we buy it every time. Building only wins when nothing available matches our Christian-based focus on physical, emotional, and spiritual needs, and even then we keep the scope narrow.

That single lesson has never steered us wrong. Can we explain the tradeoff clearly so stakeholders trust we’re putting vulnerable kids first? We research options thoroughly before any rollout or public word. Buying keeps us CARF Accredited and doors open for abused, neglected, or forgotten children. Custom builds have sunk good plans when money and hours don’t stretch. Don’t chase perfect code when a solid service already works. That discipline has carried us over 90 years and still guides every decision we make.

The factor that guides our decision is reversibility. If we are wrong, we choose the path that is easier to undo without hurting progress. Buying is often easier to reverse, so we prefer it unless future changes create clear problems. We build only when a temporary solution creates problems across teams, reports, or decisions.

This approach helps us avoid choices that look cheap but create bigger costs later. A simple tool can become costly if teams change their work around its limits. We have seen teams focus on activity instead of results because systems guide their choices. When software starts driving behavior instead of helping us, we know building may be the better option.

The first step is to identify where the real bottleneck exists. If the problem is with technology, buying a proven solution can be the right choice because it already solves many common challenges. If the real issue is decision quality, process alignment, or how teams understand information, building a custom solution often makes more sense. In those situations, the greatest value comes from creating a system that matches the way the business operates every day.

The strongest lesson is that urgency should never decide the architecture. A quick purchase may solve an immediate problem but can also create challenges that remain for a long time. It is better to separate short term pressure from long term business needs before making a decision. Once the real problem is clear, choosing between building and buying becomes much easier and more effective.

One thing I learned while running a marketplace: Does it actually move us toward the finish line?

If it buys us better buyers or makes them trust us more to do it in house. We had our own custom vetting process because existing tooling wasn’t good enough and made the user onboarding process a nightmare. We continue to invest in what we need in house because it enables us to move faster and make better users stick.

I’ll look much more at skills than capacity to help answer this question. In other words, if our employees’ skillsets align with developing that particular tool in-house, that’s what we’re going to do. We may need to wait until we’ve cleared a few client projects to tackle it, but that can be a smart tradeoff if we can get a tool that’s a better fit for our needs and under our direct control.

As chief executive of a corporate-services firm managing 118 SME entities across 22 jurisdictions, I apply one test to build-versus-buy: will the vendor sell it to me at a unit price? A number on a public pricing page means buy; a wall of demo-request buttons means the product was priced for someone else’s budget.

Take entity management. The major platforms publish no self-serve pricing; the one figure I could find was a $25,000-a-year entry tier whose “get started” button still routed to a demo call. That sales motion assumes an enterprise legal department. We manage companies for SME clients. So I built our portal myself in Python, Node.js, and SQL — my own development time, once, against $25,000 a year, every year — and it runs our entire book today.

Identity verification went the other way. Stripe Identity publishes €1.25 per successful verification in our region (document check plus selfie match), so I bought, wiring the sessions straight into our production schema.

Opaque pricing is information: the vendor’s ideal customer isn’t you. That mismatch is usually my cue to build. The exception is anything security- or compliance-critical. Those I buy even when the pricing page makes me call sales.

From an operational management perspective, there are many factors that determine whether you should build custom software or buy off-the-shelf. From a risk and reliability standpoint, we purchase pre-built software for all of our essential administrative functions such as facility billing, inventory tracking, scheduling, etc. The single criterion, that has always tipped my call to buy the software, is the availability of enforceable service level agreements and 24-hour technical support. When in-house software does not work, our internal team must abandon all other tasks to resolve the code base which will cause delays in operation. When we purchase from a reputable vendor, we know that they have committed to keeping the system uptime within specified time periods; we will have access to a full-time customer support specialist and any issues will be addressed quickly. This contractual reliability ensures that our administrative functionality will continue without interruption.

We primarily evaluate the need for a piece of software based upon whether or not it will preserve budget predictability and protect operational efficiency. Administrative functions such as facility logistics, record archiving, and payroll are generally handled by purchasing off-the-shelf software because they represent established commercial process. If there exists no viable off-the-shelf solution, but would still be necessary for day-to-day operations, then we may consider developing the function in-house.

Our primary consideration when deciding whether to develop in-house or purchase off-the-shelf, is the ability to natively integrate into our existing administrative technology stack. If a piece of commercial software can natively connect into our system without requiring additional development, we make the decision to purchase it immediately. Custom coding for disparate systems creates unreliable, fragile workflows; however, buying software that includes native integration ensures reliability in both data flow and lessens the amount of time administrative personnel spend working around technical issues.

When an administrative operation has a new technology requirement, I will assess if an “off-the-shelf” tool meets the administration’s needs for its process without significant customizations. In addition to meeting administrative processes, all of the enterprise applications also require me to ensure that there are adequate, strong data security measures in place for every application. Therefore, when selecting a software platform for this purpose, I look for mature cloud-based software platforms with built-in encryption, regular security audit schedules, and dedicated technical support.

Ultimately, the single factor which reliably determines whether or not I buy a particular software package is the cost to the company to continually monitor and remediate compliance and security issues as they arise. Custom development allows my internal teams to perform manual updates to address newly identified vulnerabilities on their own. However, buying from well-established vendors removes the responsibility for continuous monitoring and remediation of these compliance/security-related risks from our internal administrative staff to professional vendor support personnel, thereby enabling our organization to continuously meet high levels of enterprise-class security compliance standards at minimal cost internally, while ensuring that we remain lean and focused administratively.