Build or buy: the honest case for each in software product development company

Buy when the process is standard and a commercial platform covers most of it. Build when the workflow is your competitive advantage, or when no product fits your data model and regulatory position. The honest third answer is compose: buy the commodity layers, build the differentiated middle, and own the integration contract, which is what most successful platforms actually are.

This article defines the three options precisely, gives you a five-factor score you can run in an afternoon, compares what each option costs and what it locks you into, and sets out the conditions under which building is the wrong answer even when building is what you want to do.

Three options, defined so they can be compared

Buying means licensing a commercial product that a vendor operates and develops. You configure it, you do not change its data model, and its roadmap is not yours. Your costs are a subscription, an implementation, and the internal change work to fit your process to the software.

Building means commissioning software written for your process, which you own and operate. Your costs are a build, ongoing change, infrastructure and support. Your asset is a system shaped exactly to how you work, and your risk is that you are now responsible for every part of it.

Composing means buying the parts of the stack that are genuinely commodity, building only the layer that differentiates you, and treating the joins as first-class engineering. Payments, identity, email, search infrastructure, error tracking and analytics are bought. The workflow that makes your business distinctive is built. The APIs, webhooks and reconciliation between them are the real project, which is why teams underestimate this option most often.

Joel Spolsky's argument in defence of not-invented-here syndrome is still the clearest statement of the principle: build the thing that is your core business function, and buy everything that is not, because an outside supplier's priorities will never match yours on the part that matters.

A five-factor score you can run in an afternoon

Score each factor from one to five, where five argues for building. A total above eighteen means build or compose; below twelve means buy and stop deliberating.

• Differentiation. Does a customer ever choose you because of how this process works? Five if the answer is yes and you can name the customer. One if it is a back-office function every competitor runs identically.
• Fit. How much of your requirement does the best available platform cover as configured, without custom development? Five if it covers under half. One if it covers nearly everything and the gap is cosmetic.
• Data gravity. Does the process depend on data that already lives in your systems and would have to be synchronised out and back? Five for heavy two-way synchronisation. One for a self-contained process.
• Regulatory and residency constraints. Do you need the data in a named region, in your own tenancy, with audit rights you cannot get from a vendor? Five if a regulator or a large customer imposes this in writing. One if standard terms are acceptable.
• Change rate. How often will this process need to change in the next two years? Five if it changes monthly because the market is moving. One if it has been stable for a decade and will stay that way.

The score is a conversation tool, not an oracle. Its real value is forcing the differentiation question to be answered with a customer's name rather than with an opinion, because that is the factor teams systematically overrate when they want to build.

Build, buy or compose: the trade-offs

What does building cost compared with buying?

Building has a visible capital cost and an invisible commitment. Eazyware's product and platform development programme runs from $42,000 or ₹28,00,000 to $175,000 or ₹1.2 Cr as a fixed-price engagement, and a narrower scope costs considerably less: a full stack web application starts at $14,000 or ₹8,80,000, and API development and integrations at $7,000 or ₹4,40,000. A SaaS or cloud-native application starts at $31,500 or ₹20,80,000. Published starting prices for every scope are on the pricing page.

Then add the commitment. A built system needs support cover, dependency upgrades and a change budget. Care plans start at $1,000 or ₹68,000 a month for business-hours cover in IST and reach $5,250 or ₹3,40,000 for 24x7 with a one-hour response and a named engineer. Buying has the mirror-image profile: a low first-year number that rises with seats and transactions, plus implementation and internal change effort that rarely appears in the vendor's proposal.

Comparing them on year one is the mistake almost everyone makes. Compare total cost over three years, including the cost of the process compromises you will accept if you buy, and the cost of the change you will not make if you build and then under-fund it. The hidden costs that quotes leave out lists the running lines on the build side.

How composing actually works

Buy the layers where being different is worthless

Payments, identity, transactional email and messaging, error tracking, logging and mapping. Nobody has ever won a customer with a better password reset. Buying here converts engineering time into a predictable subscription and gives you compliance work somebody else maintains.

Build the layer that makes you worth choosing

This is usually one workflow, not a suite: the way a dispatcher assigns jobs, the way an underwriter scores a file, the way a marketplace matches supply and demand. It is small enough to build well and specific enough that no platform will ever fit it. Building it well and buying everything around it is how you get a defensible product for the price of a modest project.

Own the joins

Composing fails on integration rather than on components. Every join needs a contract, an idempotency rule so a retry cannot double-charge or double-book, a retry policy, and a named owner. Webhooks need signature verification and replay handling. If nobody owns the joins, you get integration sprawl, which is the characteristic failure of this option; from product to platform covers the discipline in detail.

When building is the wrong choice

We turn down build work regularly, and these are the four conditions that trigger it.

Your process is standard and you just dislike the incumbent product. Rebuilding a payroll system, a helpdesk or a CRM because the current one is irritating produces a worse version of a mature product two years later, at a higher cost, with fewer people who know how to run it.

You have no owner. A built system needs somebody internally who decides what changes next and is accountable for adoption. Without that person the system freezes at its launch state and drifts out of usefulness, which is the pattern described in why enterprise software implementations fail on adoption.

You cannot fund year two. A build with no change budget is a depreciating asset. If the money exists for a project but not for the following year of iteration and support, buying is the more honest choice because somebody else is obliged to keep the software current.

The requirement is still moving. If nobody can describe the workflow the system must support, buying a platform and living with it for a year is a cheap way to learn what you actually need, and the learning transfers directly into a later build.

A worked decision

A last-mile logistics operator could have bought a transport management system. It already had one. What no vendor sold was the specific dispatch logic its planners used and a driver app that kept working through dead zones on the route, which is exactly the composed shape: keep the bought TMS, build the differentiated middle, integrate carefully with telematics and the ERP. The result is described in the dispatch platform case study, and the decision that made it work was refusing to rebuild the parts the market already solved.

Before you decide

• Name the customer who would choose you because of this process, or accept that it is not differentiating
• Run a real trial of the best platform against your actual data, not a vendor demo
• Count the integrations either option requires; that number drives cost more than features do
• Confirm whether a regulator or a major customer requires your own tenancy or a named region
• Identify the internal owner who will direct change after launch
• Model three years of both options, including implementation and internal change effort
• Check the exit path: what you take with you from a platform, and what handover looks like from a build
• If the score is borderline, buy the commodity layers now and build the middle later

Related reading

Build vs buy vs integrate applies the same framework to AI capability specifically, the build vs buy comparison page summarises the decision on one screen, and Software Product Development Company cost in 2026 gives you the build side of the three-year model.

Build the part of the system that would embarrass you if a competitor did it better, and buy the rest without sentiment.