Build, buy or configure?

Every product contains assumptions about how a business works. Buying it means accepting enough of those assumptions to benefit from the work already done. Building means taking responsibility for an approach of your own.

The decision turns on which differences matter. Adapting an unusual internal habit to ordinary software may simplify the business. Forcing a valuable operating method into the wrong product may destroy the advantage that made the method worth keeping.

Decide which differences deserve software

An unfamiliar process is not automatically a distinctive capability. Sometimes it exists because an old tool required a workaround. Sometimes it reflects a real promise to customers that ordinary products cannot support. Those cases deserve different treatment.

Consider a service business with standard invoicing but unusual assignment rules. It may be sensible to buy the invoicing capability and build a small layer for assignment. The sourcing decision can follow the responsibility rather than treating the whole operation as one indivisible platform.

The Government Digital Service’s build-or-buy discussion is useful for challenging assumed uniqueness. Test the business’s difficult examples against available products. If the only obstacle is a familiar preference, adaptation may be cheaper. If the obstacle is essential to the work, custom software deserves a fair comparison.

Test the awkward cases

A polished demonstration usually follows a clean path. Your evaluation should include a correction, a cancellation, a duplicate record and the uncommon case that regularly causes trouble. Ask who resolves each one and whether they need an expensive license or specialist assistance.

Check the integrations on the plan you would actually buy. Export options, automation limits and access permissions can differ between plans. Treat advertised capability as something to verify with representative work, especially when it is central to the decision.

Compare the whole commitment

For a product, include setup, migration, training, subscriptions, required add-ons and the effort of working around limitations. For a custom build, include discovery, delivery, hosting, maintenance, support and eventual replacement. Both options need an owner inside the business.

Use a realistic planning period and a few usage scenarios. Do not assume the smallest subscription tier will remain adequate forever, or that a custom system will never need changes. Total cost of ownership provides a fuller way to organize the comparison.

Consider a small custom layer

Sometimes the best fit is familiar software underneath a focused custom interface or workflow. That can preserve tools the team understands while removing the repeated work that makes them frustrating. The custom layer still needs monitoring and maintenance, but its scope can be much smaller than a complete replacement.

For Community Thanksgiving Dinner Foundation, we built an integrated web presence and operational system around the team’s needs and technical abilities. Cloudflare services and custom Google applications working with Sheets supported a focused approach without adding a collection of unnecessary paid tools. That is an example of choosing the implementation around the operation; it is not a claim that custom software is always cheaper.

Choose with ownership in view

Ask who can administer the result, fix a problem and move the data if circumstances change. A good purchase can fail when nobody configures or maintains it. A good build can fail when the business cannot support its ongoing responsibilities.

The useful outcome is a choice the business can defend and sustain. Buying a mature product and keeping the custom work small can be the result of careful engineering judgment.

Revisit the build cost with AI in view

AI-assisted engineering can lower the effort needed to explore and implement a focused custom tool. That makes some previously impractical builds worth reconsidering. It also makes it easier to create more software than the business wants to own.

Ask for an estimate that separates implementation from integration, testing, migration and ongoing support. Compare the full option against buying. Our guide to vibe coding and engineering explains what changes when an experiment becomes an operational dependency.