Build vs buy software: a scorecard and cost worksheet for startups

Build vs buy software is the question every product team meets once it needs a capability it does not have yet: sign-in and accounts, billing, reporting dashboards, an AI assistant. The short answer is to build what customers choose you for and buy what they merely expect. Then check that answer against three-year cost, time to value, control of your data and the risk on each side.

Most teams get the easy cases right and the middle wrong, because the middle needs numbers. Our fractional CTO services exist for exactly these calls: a fractional chief technology officer (CTO) who prices both paths, checks the vendor and owns the decision with you. This guide gives you the same tools: a weighted scorecard, a three-year total cost of ownership worksheet with named inputs, and a third option that fits AI-era products.

What does build vs buy software mean?

Build vs buy software is the choice between writing and running a capability yourself and paying a vendor for one that already exists. In practice there is a third option, buy then extend: you take a platform that covers most of the need and add your own layer on top of its interfaces.

The decision whether to build or buy software is made per capability, not per product. A software product is a stack of capabilities, and a startup that builds its core workflow by hand while buying its sign-in, email delivery and billing is making three sound decisions, not one inconsistent one. The question to ask of each capability is the same: is this something customers pick us for, or something they assume works?

A build vs buy analysis is the written version of that question. It names the capability, scores it against a fixed set of criteria, prices both paths over the same period and records the risks that could change the answer. The rest of this guide is that analysis, in the order we run it.

Build what customers choose you for, buy what they expect

The first test is differentiation: if a capability is the reason customers choose your product over the alternatives, build it; if every competitor can buy the same capability from the same vendors, buying it creates no advantage and building it creates no edge. That one test settles most of the stack.

Sign-in and accounts, email delivery, payments, invoicing and support ticketing sit at the buy end. Customers expect them to work and notice only when they fail. Your core workflow, the matching logic, the scoring model or the editor your customers spend their day in sits at the build end. Nobody buys your product because its password reset is better.

The middle is where judgment is needed. Reporting dashboards, workflow automation, integrations with your customers' other tools and an AI assistant can be bought as platforms, but the part that makes them yours is the data model and the rules underneath. Those are the capabilities where buy then extend usually wins, and where the scorecard below earns its keep.

Two questions sharpen the test. Would a customer switch to a competitor whose version of this capability was clearly better? If yes, it is core. Could a competitor buy an equivalent next month? If yes, building it buys you nothing that lasts.

The build vs buy scorecard: seven criteria and weights

A build vs buy scorecard scores one capability against seven criteria, each with a build signal, a buy signal and a weight you set before you score. Scoring before weighting, or weighting after you have a favourite, is how most analyses end up confirming what the loudest person wanted.

Fill the table in for one capability at a time. Score each criterion from 1 (the buy signal fits) to 5 (the build signal fits), multiply by the weight, and add the products. The total matters less than the spread: a capability that scores high only on differentiation and low everywhere else is telling you to buy then extend, not to build from scratch.

The weights above are a starting point for a product team at seed or Series A, where differentiation and speed count most. A regulated business raises the weight on control of data and logic. A team with one engineer raises the weight on capacity. Change the weights once, in writing, before anyone scores, and keep them the same across every capability you compare.

Two readings matter. A total near the top of the range with no criterion under 3 is a build. A total near the bottom is a buy. Anything else is a buy then extend candidate, and the next two sections price it.

A three-year total cost of ownership worksheet

Total cost of ownership (TCO) over three years is the only fair comparison, because a build front-loads its cost and a purchase spreads its cost into fees that grow with usage. Year-one sticker prices favour buying; a three-year view with maintenance, fees and risk included is where the answer can flip either way.

The worksheet below lists the lines that belong in both columns. The build inputs are your own estimates, adjusted for the overrun pattern described in the next section. The buy inputs come from the vendor's current pricing page and from published data on how bought software is actually used.

The buy-side inputs have numbers behind them. Zylo's 2026 SaaS Management Index was published on January 29, 2026 and is built on the vendor's own data from more than 40 million software as a service (SaaS) licences and 75 billion US dollars of spend. It found that organizations leave an average of 36% of their SaaS licences unused, measured against the utilization levels the industry recommends. In the same report's survey of 218 IT leaders, 78% reported unexpected charges tied to consumption-based or AI pricing in the previous 12 months, and 61% had cut projects because of unplanned SaaS cost increases. Budget seats you will use, not seats you might, and read the usage and AI pricing clauses before you sign.

A worked example shows the shape. This is an illustration, not a client: a startup needs subscription billing and expects to bill 300,000, 900,000 and 2,000,000 dollars in its first three years, 3.2 million in all. Stripe Billing's pay-as-you-go plan is listed at 0.7% of billing volume on Stripe's Canadian pricing page as of November 2026. The platform fee over three years is therefore 22,400 dollars, calculated as 0.7% of 3.2 million. Add your integration effort and some admin time, and that is the buy column. The build column starts with your estimate for a billing engine that handles plans, proration, tax, dunning and invoices. Then it adds the overrun adjustment below and a share of an engineer every year to keep it working. For most teams the build column is larger before year one ends, and billing is not what their customers choose them for. For a team whose pricing model is itself the product, the same worksheet can come out the other way.

Price the fractional help honestly as well. If a senior engineer would own the decision and the build, the fractional CTO cost calculator gives you a line for that column too.

Why build estimates miss: the risk the average hides

Build estimates miss not because every project runs a little over, but because a minority run far over. In their September 2011 Harvard Business Review article, Bent Flyvbjerg and Alexander Budzier of the University of Oxford's Saïd Business School analyzed 1,471 IT projects and found an average cost overrun of 27%. That average hid the real risk: one project in six was what they called a black swan, with a cost overrun of 200% on average and a schedule overrun of almost 70%.

Those two figures are the build column's contingency. Add 27% to your estimate as the expected case, then ask whether you could survive the one-in-six case at three times the estimate and a schedule most of a year late. Calculated on a 60,000 dollar build estimate, the expected case is 76,200 dollars and the black swan case is 180,000. A capability that only makes sense at the first number is a capability you should buy.

The same pattern explains why build projects feel safe until they are not. Scope set before the requirements are clear, a first version that grows into a platform and a vendor or contractor chosen on price are the usual routes into the tail. A startup CTO, full-time or fractional, earns much of their keep by keeping builds out of it: a scoped first version, a named owner and a stop rule agreed before the first line of code.

Buy vs build risk: lock-in, price changes and portability

Buy vs build risk runs the other way on the buy side: the money is predictable, the dependency is not. A vendor can raise prices at renewal, change its pricing model, retire the version you built on or shut down, and your product inherits every one of those events.

Three checks before you sign cover most of it. First, export: can you get your data out in a commonly used, machine-readable format, and have you tried it? Second, the roadmap and lifecycle: does the vendor publish deprecation dates and a support policy, and does its history suggest it keeps them? Our software end-of-life tracker lists the dates that matter for common startup stacks, and the current OpenAI API deprecations show how fast a model you built on can reach its shutdown date. Third, the switching cost: how many weeks of work would moving to the second-best vendor take, and does the contract add fees to that?

Regulation is starting to help on the last point, at least in Europe. The EU's Data Act has applied since 12 September 2025. Under its switching rules, as the European Commission describes them, providers of platform and software as a service must make open interfaces available and, at a minimum, export a customer's data in a commonly used and machine-readable format. All providers must remove obstacles to switching. From 12 January 2027 the Data Act removes switching charges, including charges for data egress, after a transitional period in which providers may still pass those costs on. If your vendor serves EU customers, these are terms you can now expect; if it does not, they are still the right terms to ask for.

Build risk and buy risk are different shapes, not different sizes. A build can fail quietly for a year and then loudly. A purchase rarely fails outright; it gets expensive, gets ignored or gets retired. The scorecard's vendor-risk and capacity rows are where you record which shape you can live with.

Buy then extend: the third option for AI-era products

Buy then extend means taking a platform that covers most of a capability, usually one designed to be built on through its application programming interface (API), and writing only the layer that makes it yours. It gives you most of the speed of buying with most of the control of building, at the cost of a dependency you have to manage.

AI features are the clearest case. Almost no startup should train its own foundation model. Almost every startup should own the prompts, the retrieval over its own data, the evaluation set and the guardrails that make an AI assistant useful in its product. The model is bought by the token; the judgment about what to ask it and how to check the answer is built. Our generative AI development services work exactly along that line, and the same split applies to reporting dashboards on an embedded analytics platform or workflow automation on a rules engine.

The failure mode is extension creep. The 20% you planned to customize becomes 60%, platform updates break your extensions, and you end up maintaining a build while still paying for a purchase. Three rules keep it honest.

• Extend through published interfaces only. Use the vendor's APIs and extension points; never fork or patch its behaviour.
• Keep your own data model. Hold your own copy of your data in your own schema, so the vendor stores it but does not define it.
• Set a re-scoring threshold in advance. Agree on the point at which the extension has grown enough to be scored again as a build.

AI coding tools change the arithmetic but not the test. A first version is cheaper to write than it was, which moves some middle cases toward building. The maintenance line, the overrun tail and the question of who owns the code at 2 a.m. are unchanged, and those are the lines that decide three-year cost.

Build vs buy software pros and cons at a glance

The build vs buy software pros and cons below are tendencies, not rules: the right column for your capability depends on the vendor you can actually buy, the team you actually have and how much the capability sets you apart.

Read the last row with the scorecard in hand. The main risk of each path is a known shape, so the honest version of the decision is not "which path is safe" but "which risk are we set up to manage".

How we help with build or buy decisions

We run this analysis with founders and product teams as part of our fractional CTO services for startups: the scorecard, the three-year worksheet, the vendor checks and a written recommendation you can show a board. When the answer is build, or buy then extend, our software product development services can scope and ship the first version with your team.

Every engagement is under a non-disclosure agreement (NDA), the intellectual property (IP) is always yours, and each one is quoted after a short call.

Frequently asked questions