Custom Software: When It Pays Off – and When Off-the-Shelf Is the Better Decision

One thing up front, because it is where most make-or-buy decisions come apart: the problem is rarely the technology, it is the question. Ask "which one is cheaper?" and you are holding a one-time build price against a monthly license fee. That answer is skewed before you get it. The question that holds up sounds different: which of your processes explains your margin, and which one is pure administration? The first you build yourself. The second you buy, and then never touch again.

There is also a shift that turns up in almost no comparison article: the cost side of off-the-shelf software is no longer stable. Gartner analyst Mike Tucciarone reports that subscription prices at several large SaaS vendors have risen by 10 to 20 percent this year. Over the same period, Gartner forecasts IT budget growth of 2.8 percent (Gartner statements quoted in CIO.com, 2025). The old comparison, one-time build against recurring license, lands differently today than it did five years ago, and in both directions, depending on how many people use the software.

Custom software is built for one specific client and that client's actual processes, rather than for an anonymous market. You commission it, you do not license it. Its scope comes out of the requirements of exactly one organization, and the usage rights are settled in a contract instead of assigned through terms and conditions.

What custom software is not matters just as much. It is not the same thing as customizing an off-the-shelf product: there the vendor stays the owner, and you carry the upgrade risk for your modifications. It is not identical to in-house development either. In a techconsult survey, 44 percent of the companies surveyed hand development to an external provider, 22 percent build exclusively in-house, and the rest run some mix of both (techconsult, 2021, n = 201 IT and software decision-makers, commissioned by the German custom software vendor Dr. Eckhardt + Partner, a vendor-funded survey that should be read as one). And it is certainly not a large program of work, at least not at the start: the smallest sensible cut is a single process, not a system replacement.

Some orientation before the criteria. The usual comparison articles stage a duel between two contenders. In practice you have four options, and most bad decisions happen because the middle two get skipped.

You buy a finished product and bend your process to the software. This is the fastest option and almost always the cheapest one, as long as you genuinely accept the change to your process. It tips over the moment your people start closing the gaps with spreadsheets, email chains, and shouting across the room. Those shadow processes are the real cost. They appear on no invoice.

Parameters, custom fields, workflows inside the vendor's rule set, and then, one step further, extensions in the product's own code. Configuration within the intended boundaries is unproblematic. Customization in the narrow sense, meaning changes to the standard itself, moves the upgrade risk onto you: every release the vendor ships turns into your test project. This option tips over when your modifications need release management of their own. At that point you are paying for a license and for development at the same time.

You assemble application logic inside a platform, without classic software development. For internal form and approval processes with users in the dozens rather than the hundreds, this is often the most economical choice, and we actively recommend it in those cases. It tips over at three points: complex data logic, high user counts, because licensing is nearly always per user, and the exit, because what you built does not run without the platform. You trade development effort for a very tight platform dependency. A legitimate trade, as long as you know you are making it.

You commission exactly the application your process needs, built on a widely used technology stack. The investment is highest at the start and does not grow with your user count afterwards. It tips over when the process is unclear, when nobody internally takes ownership of the domain decisions, or when the process is due to be replaced soon anyway. Remember this: each of the four options has a tipping point. Anyone who cannot name it has not understood the option.

Pros-and-cons lists help nobody, because nothing in them is weighted. A different approach works better: walk through each criterion on its own and note which of the four options it pushes forward. When five of seven criteria point the same way, the decision has already been made.

Differentiation. Do you make money because you run this process differently from your competitors? Yes: custom development. No: off the shelf, no discussion. This criterion beats all the others.

Process specificity. How many of your process steps run outside what the standard product foresees? Up to about a tenth: buy the standard and adjust the process. Up to a quarter: configuration, and low-code for the remainder if it comes to that. Above that: custom development, because from there on customization costs more than building new.

Integration depth. How many systems have to be kept consistent: ERP, PIM, shop, CRM, inventory management, shipping provider? At one or two, the standard wins. From three systems with mutual dependencies onward, the integration layer becomes a product in its own right, and no license vendor is going to build that for you.

Rate of change. How often does the process change in business terms? Once a year: standard. Several times a quarter: custom development or low-code, because otherwise every change puts you in the vendor's queue.

Number of users. License costs scale linearly with headcount, development costs do not. Few users argue for standard, many for building your own. We work through where exactly the crossover sits further down.

Rights to the result. Do you want to be able to develop this process further with a different provider in five years? Only custom development gives you that option, and only if the contract is right.

Time to production. Off the shelf: days to weeks. Configuration: weeks to months. Low-code: weeks. Custom development: with a clean cut, six to twelve weeks to the first production version; with an everything-at-once scope, a year and more. Time is not an argument against custom software. It is an argument against oversized first cuts.

For context: the values below are our practitioner's read from mid-market projects, not study results. They do not replace an analysis. They are a better test frame than "it depends".

Threshold 1: license cost against build investment. If your annual license and maintenance fees for one system exceed a third of what your own solution would cost as a one-time build, the calculation is worth doing. How you notice: the renewal date sets off the same fundamental debate internally every single year.

Threshold 2: number of systems to keep in sync. From three systems with data flowing in both directions, you need an integration layer of your own regardless. How you notice: half of somebody's job is reconciling data between two systems.

Threshold 3: share of process steps outside the standard. Above a quarter, customization costs more than building new, because every modification has to be defended against the vendor's release cycle, permanently. How you notice: there is a spreadsheet without which the process does not work, and everybody knows the one I mean.

Threshold 4: number of users. In our model below, the crossover for per-user SaaS licensing sits at around 80 users; the price per seat moves it a long way in either direction. How you notice: you are buying licenses for people who open the system twice a month. Zylo shows how large that line item gets: organizations spend an average of $21 million a year on unused SaaS licenses, 14.2 percent more than the year before (Zylo, 2025 SaaS Management Index, based on more than 40 million managed licenses and $40 billion in SaaS spend, mostly large US enterprises). The absolute figure does not transfer to a mid-market company. The mechanism does.

What follows is an open model calculation, not a study. Every assumption is in the text so you can swap in your own. Starting case: a line-of-business application for one operational core process, 80 users.

The license path. €45 per user per month gives you €43,200 in year one. With a 10 percent annual price increase, that adds up to roughly €264,000 over five years. That uplift is the lower end of the range Gartner reported in 2025, projected forward across five years: the most attackable assumption in this model. On top of it, €40,000 one-time for rollout, data migration, and configuration. Total: around €304,000.

The development path. €150,000 initial investment for a fully built-out line-of-business application. For maintenance we use the most stable empirical figure in the software engineering literature: maintenance consumes 40 to 80 percent of a piece of software's total cost, 60 percent on average (Robert L. Glass, Facts and Fallacies of Software Engineering, 2002). Spread across a ten-year life cycle, that works out to about 15 percent of the initial investment per year, so roughly €22,500. Plus €6,000 a year for operations and hosting. Over five years: around €293,000.

The result is deliberately unspectacular: at 80 users it is a tie. Cost decides nothing here. What has to decide is process specificity, integration depth, and rights. The calculation only gets interesting at the edges. At 25 users the license path costs around €122,000 in the same model and wins clearly. At 250 users it sits at around €864,000, while the development path stays at €293,000. Software does not get more expensive per head.

Two items are missing from the license side in almost every internal calculation. First, the unused licenses whose order of magnitude is above: you pay per head, you use per need. Second, the pricing models: 66.5 percent of the IT leaders Zylo surveyed report unexpected SaaS costs from consumption-based or AI-driven pricing (Zylo, 2025 SaaS Management Index). The crossover point is not a law of nature. It hangs on three variables: user count, license price development, and rate of change.

Honesty means naming the other direction: there are categories where we advise against custom development as a matter of course, even though it is what we do for a living. Accounting and financial reporting. Payroll. Time tracking. Email and collaboration. Standard CRM without a genuine process peculiarity. Anything subject to certification or audit requirements for which certified products exist. In these fields, buying the product also buys you the regulatory upkeep, and that is worth more than any degree of fit.

Category aside, we also advise against building when any one of these four conditions holds. The process is not described in business terms and nobody can explain it at a whiteboard in an hour. There is no internal owner allowed to make decisions. The budget only covers half of the first sensible cut: then you build a fragment nobody uses. Or the process is due to be replaced within the next eighteen months as part of some other initiative anyway.

If you are not yet sure which category of application you even need, the orientation guide on website, web app, or portal settles that faster than any make-or-buy analysis.

Industry lists are not much help here, because custom software does not sort by industry. It sorts by process type. These six cases are the ones we see most often.

Configurator and quoting. Products with many variants, pricing logic full of exceptions, quotes in minutes instead of days. The classic case where no standard product models the rule logic, because the rules are your business.

Customer portal. Order status, documents, complaints, reordering: everything your customers currently phone your inside sales team about. Cost and scope questions we handle separately under customer portal development and in the comparison of when Zendesk is enough and when it gets expensive.

Order flow across system boundaries. One transaction that passes through four systems and three departments and is held together by email today.

Data hub between ERP, PIM, and shop. Product data maintained in three places and correct in none. When a system of your own pays off here and when a standard PIM is enough is covered in build vs. buy: when a custom PIM pays off.

Review and approval workflow. Multi-stage approvals with deadlines, delegation rules, and an audit trail. Frequently the case where low-code is the right answer, as long as the user count stays in the dozens.

Reporting across inconsistent data sources. Metrics that have to be assembled from several systems, because no single system holds the truth on its own.

One special case cuts across all six: when the application being replaced is a legacy system that grew over years, the make-or-buy question is the second step. The first is how you cut the replacement, which we cover under software modernization. An international survey run by GLG Insights on behalf of Slalom shows how common that case is: 61 percent of companies still run the majority of their business applications on outdated platforms (GLG Insights for Slalom, August 2025, n = 2,000 across five countries, German subsample 161; only companies that had already started or were just starting an AI initiative were surveyed).

This is the section no ranking comparison article delivers, even though it matters to CIO and CFO alike. Two points before you sign. Neither replaces legal or tax advice; both tell you what to ask about. What follows is German law, which applies whenever you contract with a development partner in Germany.

Rights. Under German copyright law, copyright in software cannot be transferred (§ 29 (1) UrhG); only usage rights can be granted. If the contract says nothing explicit, the purpose-transfer rule of § 31 (5) UrhG applies: in case of doubt, the client receives only those rights the purpose of the contract strictly requires. That is typically a plain right of use, non-exclusive, with no claim to the source code. A right to modify the software beyond what § 69d UrhG already permits for intended use and defect correction is not a given either. Anyone who treats "the source code is ours" as settled usually does not have that sentence in the contract (based on the account by IT-Recht-Kanzlei).

Risk and balance sheet. Whether you sign a Werkvertrag (contract for work, owing a result) or a Dienstvertrag (contract for services, owing effort) decides the essentials under German civil law. Under a Werkvertrag the provider owes a result, carries the production risk, and is liable for defects after acceptance. Under a Dienstvertrag you are buying working time, and the outcome risk stays with you. On the balance sheet, the contract type only has an indirect effect. Software can be capitalized when it was acquired for consideration, meaning that control passes from a third party and there is an objectively verifiable payment in return. A Werkvertrag setup meets that test more readily than pure time-and-materials billing, which amounts to creating the asset yourself. For internally generated intangible fixed assets, German commercial law grants an option to capitalize (§ 248 (2) HGB), while German tax law prohibits it (§ 5 (2) EStG). Talk this through with your tax advisor before the contract type gets picked out of convenience (based on the account by Haufe).

Three clauses belong in every custom software contract: an exclusive right of use, unlimited in time and territory, including the right to modify; continuous delivery of the source code into your own repository, not only at project end; and an exit clause with handover documentation. Anyone who dodges on one of those three has a reason for it. The technical frame we set is described under TypeScript agency.

To close, the patterns we see most often: first the mistakes in awarding the work, then the ones in running it.

The 80-page requirements document before the first prototype. Requirements that were never validated against a running system are guesses in contract form. Write twenty pages, build for six weeks, write the next twenty.

A fixed price on a fuzzy scope. A fixed price is good when the scope is sharp. When it is not, you pay the provider's risk premium and get a provider who has to fight off every change.

The oversized first cut. McKinsey and the University of Oxford analyzed more than 5,400 IT projects with an initial volume of $15 million and up: on average they ran 45 percent over budget, 7 percent over schedule, and delivered 56 percent less value than planned (McKinsey/University of Oxford, 2012). Those numbers describe large programs, not mid-market projects. That is precisely the point: they are the strongest argument there is for keeping the first cut small.

Nobody allowed to decide. If you cannot name a person who may make domain decisions without convening a committee, you are buying delay. In our experience that is the most reliable predictor of a project that never finishes.

No operating concept. Who pays for hosting, monitoring, security updates, and support from day one after go-live? Settle that after launch and you negotiate from the weaker position.

The assumption that you will do it in-house. Bitkom puts the gap at 109,000 unfilled IT positions in Germany, with an average time to fill an open IT role of 7.7 months (Bitkom, 7 August 2025, n = 855 companies). Build the capability internally and you lose a good two quarters on recruiting alone before the first line of code exists. That is not an argument against building the capability. It is an argument against treating it as a schedule.

Operations shows up in almost no proposal. Budget a recurring 10 to 20 percent of the initial investment per year. That is our experience range, and it lines up with what Glass's 60 percent maintenance share implies across a realistic life cycle. It covers security updates, dependency upgrades, adjustments to changed third-party interfaces, and small business changes. Not new functional areas.

The second honest point concerns dependency on your provider. The charge that custom software creates a permanent tie is fair, and it can be limited both contractually and technically. The source code sits in your repository, not ours. The technology stack is common enough that another provider can pick it up, instead of being stuck in a house framework. Architecture and deployment are documented, and the deployment itself runs without proprietary tooling. And the dependency is not binary anyway: with off-the-shelf software you are tied to a vendor too, except there you have no influence on the product roadmap, the price, or the end-of-life date.

Before you talk to any provider, one hour of internal preparation is worth the time, and it carries the rest of the decision. List your operational processes and sort them by differentiation: what does the competition do the same way, what do only you do that way? For the three most individual processes, put the annual license and maintenance costs of the systems you use today next to a rough build estimate. Sketch which systems have to exchange data. Finally, note where spreadsheets and email chains hold the process together today. That is your actual requirements list.

If the case for building your own holds up after that, the next sensible step is not a requirements document but a scoped first release. The €150,000 in the model calculation is the application built out over years, not the entry point. How we set up that entry point is described on our page on custom software development: an MVP in six to twelve weeks from €8,000, operations on EU servers, source code belongs to you.

If you would rather talk your case through in half an hour than sort it out on your own: book a consultation. We will also tell you when off-the-shelf is the better decision. That happens more often than a provider might like.