Build versus buy versus configure: a decision guide for software

Buy when a capability only keeps the lights on, build when it is the thing that makes you money, and configure a platform when the gap between the two is narrow. The real decision is not about software at all: it is about which parts of your operation you want to be accountable for over the next five years. Total cost of ownership, integration burden and your exit path settle the question far more often than the licence fee does.

Start with the differentiation test

Before anyone compares vendors, answer one question about the capability in front of you: does this make us money, or does it keep the lights on? Payroll, accounting, email, help-desk ticketing, calendar scheduling and document storage keep the lights on. Nobody chooses you because your general ledger is unusual. Buy those, take the vendor's opinions about how the work should be done, and spend the saved attention elsewhere.

The capabilities that make you money are the ones your customers actually feel: the quoting logic that reflects how your industry really prices, the dispatch rules that account for how your crews move, the portal your franchisees log into every morning, the underwriting model built on data only you hold. If a competitor could buy the same product tomorrow and match you, it was never differentiation.

The test is harder than it sounds, because it is easy to mistake habit for advantage. A useful challenge: write down the specific behaviour you believe no off-the-shelf product supports, then ask three people outside your department whether a customer would notice if it changed. If nobody can name the consequence, it is process habit rather than differentiation, and buying is the cheaper answer.

Total cost of ownership over five years, not one budget cycle

Comparisons collapse because they weigh a build quote against one year of subscription. Stretch both over the life of the system, which for anything load-bearing is usually measured in years rather than budget cycles, and the shape changes.

A workable model has four parts. Acquisition is what it costs to get to first production use: development for a build, implementation and data migration for a buy. Operation is what it costs to keep it running each year: hosting and monitoring for a build, subscription and per-seat growth for a buy. Adaptation is what it costs when the business changes: your own development capacity, or a vendor's roadmap plus whatever you spend working around it. Transition is what it costs to leave: rewrite and migration for a build, extraction and re-implementation for a buy.

Two costs are easy to miss. The first is administrative labour, the hours your staff spend maintaining the bought system, reconciling exports and doing by hand what the product will not do. That work is invisible because it never appears on an invoice. The second is renewal risk. Subscription costs tend to rise with seats, usage tiers and repackaged features, and your negotiating position weakens as the system becomes harder to leave. A build has an opposite risk profile: high upfront cost, then a maintenance line you control, plus the obligation to keep dependencies current and security patched. Neither shape is better in the abstract. They are simply different bets about where you would rather carry risk.

Buying does not remove the work. It moves the work to integration, configuration and the people who reconcile the gaps.

The hidden integration burden of buying

The failure mode of buying is rarely the product itself. It is the ninth one you buy. Each bought system arrives with its own identity model, its own customer record, its own notion of an order, and its own idea of when something is complete. Connecting them is your problem, not the vendor's.

Budget for the parts nobody demos: mapping fields between systems that disagree about the same concept, deciding which system holds the master record, handling the cases where one system's required field is another's optional one, building the reconciliation report that catches drift, and paying attention to API rate limits and versioning when a vendor deprecates an endpoint on their schedule rather than yours. Add single sign-on, audit logging and access reviews if you operate anywhere near regulated data.

None of this is an argument against buying. It is an argument for counting integration as part of the purchase, and for keeping the number of systems that own customer data deliberately small. A clear view of where records live, and which system is authoritative, is worth more than any individual tool. This is where data and database architecture stops being a technical detail and becomes a commercial one.

Configure, and the third path of AI app builders

Between buy and build sits configuration: a platform with a data model, permissions and workflow engine you shape to your process. Customer platforms, content systems, low-code business tools and case-management suites all live here. Configuration is genuinely fast, and it tends to fail in a predictable way. Teams configure past the point the platform intends, then discover their logic lives in a proprietary rules engine that cannot be tested, version-controlled or reviewed. At that point you have built custom software under someone else's constraints, with none of the portability of your own codebase.

The newer option is generating an application with AI-assisted builders. Used well, these suit internal tools, proofs of concept and the first honest version of an idea, and they are a quick way to show stakeholders something real before a budget is committed. The limits tend to show up in the same places: authentication and permissions at scale, data integrity under concurrent use, accessibility, and the maintainability of generated code months later. Our view on AI app builders is that they are a strong start rather than an ending, and best treated as a way to buy certainty about requirements before committing to a build.

Exit paths and data portability

Decide how you leave before you arrive. Ask every vendor, in writing, three things: can we export the complete dataset including history, attachments and relationships, not just a flat report; in what format and by what mechanism; and what happens to our access if we stop paying. Then test the export during the trial rather than during the crisis. An export that omits audit history, file attachments or the links between records is not a real exit path.

The same discipline applies to builds. Code you cannot deploy without one contractor is as trapped as data in a closed platform. Insist on documented environments, infrastructure defined in code, dependencies you could reasonably maintain, and credentials held in your own accounts. At OlDevs, clients own all code, designs, accounts and IP, because ownership is the only exit path that survives a change of supplier.

The hybrid pattern: buy the core, build the edge

The organisations we see get this right tend to end up in the same place. They buy or configure the commodity core, then build a thin layer of custom software at the edge where their advantage lives: a portal, a quoting tool, a routing engine, an analytics surface that joins bought systems into one view a manager can act on.

Two rules keep the pattern healthy. Keep the custom layer thin and well bounded, so it can be replaced without touching everything else. And decide deliberately which system owns each piece of data, so the edge reads from a known source rather than guessing. A full-stack team that works across the data layer, the integrations and the interface is usually better placed to hold that boundary than separate suppliers on either side of it.

Revisit the decision on a schedule. Software you built five years ago may now be sold as a product, and a product you bought may have drifted away from how you work. The answer is not permanent.

How OlDevs helps

OlDevs is a full-stack technology studio in Vancouver, British Columbia, working with organisations across Canada since 2014. We are usually brought in at exactly this decision point, and we are comfortable telling a client that the right answer is to buy something and let us integrate it well.

The engagement is deliberately plain. One accountable team, a working demo every week so you can see the decision taking shape rather than reading about it, WCAG 2.2 AA accessibility built in rather than retrofitted, bilingual English and French capability where you need it, and full ownership of everything produced. Where a build is the right call, we scope the thin edge rather than the whole estate. Where configuration or a bought product wins, we say so and focus on the integration, data model and reporting that make it work. See how we approach web application development, or bring us the shortlist you are already weighing.

If you are holding a build-versus-buy decision and want a second opinion grounded in what it will cost to live with, request a quote. We reply to every enquiry within one business day.