Off-the-shelf or custom software? A total cost of ownership worksheet

Off-the-shelf or custom software? "Which is cheaper?" is the wrong question

When you are weighing off-the-shelf against custom software (the classic build vs buy question), the first question that comes to mind is "which one is cheaper?" That question asks about a price. The decision is made on total cost of ownership (TCO): what you pay to acquire the software plus everything you pay while you use it. A license fee or a project quote is only one part of that total. The rest is fees that grow with scale, integrations, manual work, change requests and, eventually, the cost of leaving.

Putting the first-period prices of two options side by side is easy. Saying which one is more expensive in later periods depends on your time horizon, your scale and your business. So this article gives you a worksheet rather than an answer: eight cost layers, the questions to ask about each, and an empty table you fill in from your own documents. There is not a single amount in this article; the right amounts can only come from your own quotes and price pages.

The six-question table on our custom software development page shows which side you are on; this article is a longer version you can calculate with. If an off-the-shelf product already does the job, we will tell you so. The worksheet may well end with "off-the-shelf is enough," and that is a good outcome.

When does custom software make sense? Six questions and the costs they inflate

The decision mostly comes down to six questions. Each one inflates one to three cost layers in the worksheet; the last column of the table shows which ones to look at (the layer numbers are explained in the next section).

The downsides of off-the-shelf software usually show up in one of these six questions: compromises, missing connections, fees that grow with scale, or data sitting with someone else. If most rows fall in the first column, an off-the-shelf product is probably the right road. As rows pile up in the second column, the worksheet is worth filling in. For an example where business rules such as tiered pricing, quote approval and buyer-seller matching live together, see our B2B / C2C e-commerce platforms reference.

The eight cost layers of total cost of ownership

For each layer we write three things: how it looks on the off-the-shelf road, how it looks on the custom road, and the question that tells you.

1. Setup and build

Off-the-shelf: installation, configuration, migrating existing data, training the team. Custom: discovery, design, development and testing, which are the first four price items on our custom software page. This layer is one-time and goes only in the first period of the worksheet. Ask: are setup, data migration and training inside the price, a separate line, or not written down at all?

2. Recurring fees

Off-the-shelf: license, subscription, plan or version changes. Custom: hosting, a domain name, storage and the subscriptions of the third-party services you use. People assume custom software has no monthly fee, but the system runs somewhere and that somewhere sends a bill. Ask: does the price stay the same every period, and under what conditions does the plan change? On the custom side, are these costs written in the quote and which account pays them?

3. Fees that grow with scale

Off-the-shelf: per-user, per-order, per-transaction or per-module fees. Custom: infrastructure and outside-service fees that grow with usage (storage, message delivery, payment processing and the like). Both roads have them; only the shape differs. Off-the-shelf pricing steps up in tiers, while a custom system's bill follows usage. Ask: if my users and transactions grow substantially, which line changes and how?

4. Integrations and add-ons

Off-the-shelf: connector or add-on fees, plus the manual work of a missing connection (carrying data from one system to another by hand). Custom: building the integration and adapting it when the system you connect to changes its interface. Ask: for every system I need to connect, is there a ready-made connector, what does it cost, which way does the data flow and how often?

5. Trade-offs

What your business has to do because the product cannot: spreadsheets, manual steps, double entry. The measure is your own team's time and your own accounting. Nobody invoices this layer, which is why it is the one most often missed. On the off-the-shelf road trade-offs are usually more numerous; on the custom road they are not zero, because anything left out of the first version is still done by hand. Ask: which steps does the product not cover today, who does them by hand, and how much time does it take?

6. Change and maintenance

Off-the-shelf: the product roadmap is not in your hands; if your need is not on it, customization and add-on fees come in. Custom: change requests, updates and security patches. Platforms do not stand still: dependencies lose support and APIs change. Ask: what happens if my need is not on the roadmap, and who does it? On the custom side, what scope and what pricing does the quote give maintenance?

7. Risk

Off-the-shelf: price and terms changes, the product changing direction or shutting down, data sitting with the provider. Custom: dependence on a single vendor or a single person, and continuity of knowledge. Measure it as likelihood times impact and keep it qualitative (low, medium, high). If the product has AI inside, dependence on the model provider belongs here too; we cover that layer in our AI integration production checklist. Ask: if the price or terms change, what do I do, and how well does the contract protect me?

8. Exit

Off-the-shelf: the format in which data can be taken out and the contract's termination terms. Custom: handing over the code, accounts, domain name and documentation. Exit cost is part of the decision because being able to leave sets your bargaining power. Ask: if I wanted to leave tomorrow, what would I get, in what format and in which steps? Find this out in writing before you buy.

The eight layers in one table:

The total cost of ownership worksheet

Copy the table below into a spreadsheet. The rows are the eight layers plus your own time cost (writing to the vendor, managing the product, the internal effort you set aside for setup); the columns are two off-the-shelf options and the custom road. Year N is yours to choose: the horizon over which you expect the investment to pay off. Add as many middle years as you need. The cells are empty on purpose. Layer 5 covers work done by hand because the product cannot do it; the "Your own time cost" row covers writing to the vendor, managing the product and setup effort. Do not enter the same hours in both rows.

The same worksheet is also available as a spreadsheet file (XLSX) with the totals already wired in: fill in the empty cells and the formula below is calculated for you. It opens in Excel, Google Sheets and Numbers.

Option A is your first off-the-shelf candidate. Option B is a second off-the-shelf candidate, or a hybrid in which an off-the-shelf core and a custom layer sit together. You get the total from this formula:

TCO(option) = Setup and build + Σ (for each year: layers 2 to 7 + your own time cost) + Exit

Setup and build goes only in the first year and exit only at the end of the horizon. If you do not want to put an amount on the risk row, leave it qualitative and read it separately in the decision note. The worksheet does not account for the difference in value between years (discounting); for long horizons, take that up separately with your accountant. The example is symbolic too: for Option A, layer 3, Year 2, the cell reads "fee per user × the number of users I expect in Year 2 (price page, date opened)."

There is a single filling rule: write the source next to every cell: a quote, a price page, a contract clause or your own assumption. A cell with no source is a question; leave it empty and put it to the vendor in writing. Take the price and terms of off-the-shelf products from the product's official page and note the date you opened it. For the custom road the source is the written quote and the scope document attached to it; we explain how to read them in how to read a software proposal. For a line-item model of the custom road on the mobile side, the table in mobile app development cost can serve as an example.

How to read the result

1. Put the three columns side by side with their totals, but defend the decision with the rows that move the total most, not with the total. Which row, if it grows, changes the ranking?
2. Fill in the same table under two scenarios: cautious growth and ambitious growth. If the ranking is the same in both, the decision is robust; if it changes, you know the decision depends on your scale assumption.
3. If you are writing an investment case, the source of each cell is an appendix to that case. Show the cells that say "I don't know" openly too; they are questions to settle before the decision.

Where the decision turns: three sliders

Once the table is full you will see the decision is sensitive to three things. The crossover point depends on your numbers; we do not give numbers. The direction usually runs like this.

• As the horizon grows: the one-time setup-and-build cost shrinks as a share of the total and the recurring layers (2, 3 and 6) gain weight. The setup-and-build cost of the custom road is spread over a longer period; but the custom road has recurring layers too, so fill in both columns year by year.
• As scale grows: tariff-based fees grow on the off-the-shelf road, infrastructure and outside-service fees on the custom road. Price pages and quotes tell you which grows more steeply.
• As trade-offs pile up: layer 5 grows and pushes the off-the-shelf column up. It is often the least measured layer.

There are also clear cases where off-the-shelf wins: if your process resembles a common workflow, little customization is needed, your scale is small and your horizon is short, an off-the-shelf product is usually the right choice. Whether the work is core to your business is a separate criterion. An essay from 2001 (Joel on Software) puts it this way: "If it’s a core business function — do it yourself, no matter what." The essay is about keeping a core function under your own control rather than buying it in. If what sets your business apart does not fit inside an off-the-shelf product's settings, you have a reason beyond the worksheet to look past the off-the-shelf product; whether you build it with your own team or with a supplier is a separate decision. The reverse also holds: in an area that does not set your business apart, such as a standard accounting or email process, the case for custom software is hard to make.

The hybrid road: an off-the-shelf core with a custom layer

The third column of the worksheet is often a hybrid: leave the standard process to an off-the-shelf product and build only the different part, such as a customer portal, an integration or reporting. It makes sense where the core is standard but one edge is specific to you.

Hybrid tends to fit when:

• The core process is standard, but a face that meets customers or partners is specific to you.
• The off-the-shelf product offers well-documented access through an API and lets you take your data out.
• You can build the custom layer outside the product, so it survives even if the product changes.

The price is two vendors, two maintenance relationships and dependence on the product's connection surface: when the product changes its interface, the custom layer has to be adapted (layers 4 and 6). Starting with an off-the-shelf tool and moving to custom software once you see what is missing is also a legitimate road; we describe how we cut scope for a first version on our MVP development page.

Exit: leaving an off-the-shelf product, taking over custom software

When leaving an off-the-shelf product, the first question is whether your data can be taken out: in what format (files or access through an API), which data is included (history, attachments, settings), and what happens to the data when the contract ends. Read the product's data export documentation and contract terms before you buy. If the data includes personal data and you are the data controller, Article 12(2) of Turkey's data protection law (KVKK, Law No. 6698) says that when someone else processes data on your behalf you share responsibility with them for the required measures; if the data sits on a server abroad, the transfer rules in Article 9 of the same law may come into play (mevzuat.gov.tr, in Turkish). If you operate under another country's rules, the same questions apply under that country's law.

When taking over custom software, the list is: source code, server and domain accounts, third-party accounts, documentation. On rights, Article 52 of Turkey's Law No. 5846 on Intellectual and Artistic Works requires contracts about economic rights to be in writing, with the rights concerned listed separately (mevzuat.gov.tr, in Turkish); other countries have their own rules on how a transfer of rights must be documented. What to ask for is in the "what to ask the previous team for" section of our guide to taking over an unfinished software project. For accounts the question is simple: in whose name were the domain, hosting, storage and store or third-party accounts opened? An account opened in the vendor's name can turn into a bargaining chip when you leave. This section is general information, not legal advice.

An example from our own decision method

In the "build-versus-buy call" section of an engineering article we published we used the same structure on a hardware project: we put an off-the-shelf product's recurring fees and replacement needs next to one-time build plus recurring operating costs over a long program horizon. The gap turned out too large to engineer away later, and it decided whether the program could exist at all. We did not leave the decision to one calculation either: we tested the economic argument against a separate, independent technical one. This structure, which sets one-time, recurring and replacement costs side by side over a horizon, is also the skeleton of this worksheet; the exit and risk rows are there so that the decision is not left to price alone. We do not repeat the figures from that article here; it was a hardware example and your layers are specific to software.

How we do it

Here we only repeat what we say on our site. If an off-the-shelf solution does the job, we will tell you so. If custom software is the answer, every engagement is a paid project that starts with a written quote you approve: scope, timeline and cost are in writing before anything is billed, and the price does not move afterwards.

Ownership of the delivered work passes to you when the project is paid in full. Unless you choose otherwise we manage the infrastructure; with your own accounts, we deploy there. If you ever want your infrastructure brought in-house or moved to another team, we help you transfer it cleanly, with accounts, domains and documentation; nothing we run for you is a reason you cannot leave. After launch we give direct support; anything beyond that is sized to the project. We describe how this works on our custom software development page; details are on Process and Terms. Once you have filled in the worksheet, tell us about your project.

Frequently asked questions

Is off-the-shelf or custom software cheaper?

It depends on the horizon, the scale and how standard the work is; there is no single right answer. In the first period an off-the-shelf product usually starts lower, but as recurring and scale-driven fees and trade-offs pile up, the gap can close or reverse. So fill in the worksheet above with your own figures; we do not give numbers.

When does custom software make sense?

When several of the six questions fall in the second column: your business logic is unique, an off-the-shelf product forces compromises, you need to connect several systems, you have different user roles and record-level access rules, where the data lives must stay under your control, or fees that grow with scale weigh heavily over a long horizon. One question is not enough; the rows add up.

Is customizing or building on top of off-the-shelf software "custom software"?

Most of the time it counts as a hybrid. The core stays in the off-the-shelf product and the different part (a portal, an integration, a report) is built custom. Keep it in the worksheet as Option B, a separate column, so that the recurring fees of the off-the-shelf part and the maintenance of the custom layer appear together.

Can I take my data with me when I move from an off-the-shelf product to custom software?

It depends on the product's data export documentation and the contract terms; read them before you buy and ask for written confirmation. Which data comes out and in what format varies by product. When you move to custom software, how the data will be transferred into the new system should also be written in the quote.

What does the maintenance cost of custom software cover?

The work in layer 6: change requests, updates, security patches and keeping track of dependencies. With us, direct support is given after launch; support beyond that (new features, monitoring, updates) is an arrangement sized to the project.

Sources

The pages below were opened and read on November 2, 2026.

• In Defense of Not-Invented-Here Syndrome, Joel on Software, October 14, 2001 · Our engineering article on energy monitoring with Arduino
• Law No. 5846 on Intellectual and Artistic Works, Article 52, mevzuat.gov.tr, in Turkish · Law No. 6698 on the Protection of Personal Data, Articles 9 and 12, mevzuat.gov.tr, in Turkish

This article is general information; it is not legal or financial advice.