Custom software development costs: why the same requirement gets you a €15,000 quote and a €150,000 quote

You send the same requirements description to three vendors and get back €15,000, €48,000 and €150,000. None of them contains an arithmetic error, each one is internally consistent. And from the document alone, none of them lets you judge whether it describes the software you actually meant.

That is the normal case, not the exception. And it is where mid-sized companies make the most expensive decision of a software project: blind, on three documents that do not describe the same thing. For this article we laid the published German price lists side by side and worked out how much of the spread the hourly rate explains at all. At the end you get eleven questions to put next to your quote PDF.

First the data basis: in July 2026 we compared the German pages that rank in Google for "Software entwickeln lassen Kosten" and "Individualsoftware Kosten", the German equivalents of "custom software development cost", and put their published price ranges next to each other. The result says more about the market than any of those pages says on its own.

For the same project class, each time explicitly labelled "medium", koch.engineer names €15,000 to €50,000. xmethod.de gives the same range for a "medium project/MVP". kopfundbyte.de, by contrast, puts "medium software solutions" at €50,000 to €150,000 and complex platforms at €150,000 to €500,000. digital-experts.com prices a web application at around €50,000 and starts the complex application at €100,000. bytefront.de puts enterprise software at €50,000 to over €100,000. Between the published lower bound of a serious project and the published upper bound of the same category lies a factor of 10 — between vendors who all appear on the same search results page.

Now the second calculation, which nobody in the market performs. The same vendors also publish their hourly rates: kopfundbyte.de €70 to €150 depending on seniority, xmethod.de €90 to €150 for agencies and up to €180 for senior consultants, bytefront.de €70 to €140 by discipline, digital-experts.com €120 to €180. From €70 to €180 is a factor of 2.6.

So the hourly rate explains at most a quarter of the price spread. The rest, roughly a factor of four, is scope. Nobody said a word about it.

That the difference does not come from the market is officially documented. The German Federal Statistical Office reports, for producer prices of services in software development and programming in 2025, a change of 0.8 percent against the previous year; for information and communication as a whole, 1.6 percent. Anyone telling you their price reflects rising market prices is arguing against the official numbers.

The theory behind this is over forty years old. In 1981 Barry Boehm described what is now called the Cone of Uncertainty: effort estimates made before requirements elicitation are off by a factor of four in both directions, a span of factor 16 in total. Boehm's original quantification was expert judgement, not a measurement series; it was tested against project data only later, and the order of magnitude held. Translated: as long as your requirements are not elicited, the spread between quotes is not a vendor problem. It is the mathematically expected consequence of your request.

It is not the hourly rate that creates the difference. It is the assumption each vendor made silently while reading your request.

One at a time: eight variables move the price of a software project. They cost different amounts, and above all they cost different amounts to change later.

Requirements clarity is the biggest lever and the cheapest. A request that describes the process instead of the desired software forces every vendor into interpretation, and every interpretation is a different number. So instead of "we need a portal", write down which role triggers which step in which order. That narrows the spread of your quotes before the first one is written. Effort: two afternoons.

Integrations are the most frequently underestimated item, and it comes down to a single distinction: read or write. Reading data out of an ERP and displaying it is manageable. Writing it back means error handling, retry logic and idempotency: the guarantee that the same message processed twice still produces only one booking. Add coordination with the ERP provider and tests against a system nobody hands over for experiments. The same line in the requirements document costs a multiple depending on the direction.

The roles, permissions and tenancy model quietly settles the effort. Two roles are a conditional. Seven roles with object-level permissions, deputy rules and tenant separation are an architecture decision that every later feature pays for again.

Migrating legacy data is mentioned by almost every vendor and quantified by almost none. The effort is not in copying rows, it is in data quality: duplicates, free-text fields that grew historically, records without mandatory values. Realistically you need two to three trial migrations, sign-off from your own subject-matter people, and often several weeks of parallel operation. If you are replacing a legacy system, this block belongs in the quote. How that works in practice is on our software modernization page.

Compliance is rarely the main cost driver, but it is a hard one. The GDPR baseline is part of every serious project: data processing agreement, technical and organisational measures, deletion policy. In many quotes it is not itemised. The EU AI Act becomes relevant as soon as AI features are involved; what that means for buyers we broke down in a separate article on the EU AI Act. Germany's accessibility act, the Barrierefreiheitsstärkungsgesetz, has applied since 28 June 2025, but under § 1 BFSG only to products and services intended for consumers. A purely internal B2B application does not automatically fall under it; a shop or booking section aimed at consumers does.

Operations and SLA change the number before the first line of code is written. An application that has to run Monday to Friday during office hours is a different system from one with a committed 99.9 percent availability and an on-call rota. Redundancy, failover, monitoring and standby are architecture, not accessories. They do not get added later, they get rebuilt later.

Team seniority is the point where comparisons go wrong most often. The Freelancer-Kompass 2026 by freelancermap reports a median of €95 per hour for German IT freelancers, €90 for the software and web development discipline. That is the purchase price for a single person. The gap to the published German agency rates of €120 to €180 is not margin, it is service: code review by a second person, replacement when someone drops out, warranty, architectural responsibility, project management. Read that gap as a surcharge and you will still buy it in the end, only later and more expensively, in operations. Why we stay on a single technology base is on our TypeScript agency page.

The in-house alternative usually isn't one. On 7 August 2025 the German industry association Bitkom reported around 109,000 unfilled IT positions in the German economy, with an average vacancy period of 7.7 months. Seven point seven months is half a project year before the first line of code exists.

The risk premium in a fixed price is the eighth driver and the most invisible. It gets its own chapter below.

Our own position, then: we publish our ranges, because an article about price spread without a number of its own would be dishonest. These are values from our projects, not market statistics.

A process pilot or MVP costs between €8,000 and €20,000 with us and takes 6 to 12 weeks: one sharply cut use case, one user group, at most one read-only integration. A complete B2B web application with a roles model, reporting and one or two integrations sits between €20,000 and €60,000 over 3 to 6 months. As soon as several write integrations, multi-tenancy and a legacy data migration come together, we are between €60,000 and €150,000. The details on approach, stack and source code ownership are on our custom software development page.

Three situations break these ranges: a regulated industry with certification duties, hard availability commitments with an on-call rota, more than two write integrations into third-party systems. In the last case you do not control the interfaces yourself. Then we say so in the first conversation and name no number until we have seen them. For customer portals in the narrower sense we broke the calculation out separately: what a customer portal costs in 2026.

A price range without exclusion criteria is advertising. Only the exceptions make it dependable.

Most change orders in software projects are not dishonesty. They are the logical consequence of a quote that only describes development. Everything else happens anyway. A quote describes production; your invoice at the end of the year describes ownership. Between the two sit twelve items that are regularly missing from quotes and get paid for regardless. Check your document against this list: what is missing here arrives later as a change order.

Roles and permissions model as its own line item. Legacy data migration including cleansing and trial runs. Write integrations with error and retry logic. Test and acceptance environment, test data, support during acceptance. Monitoring, alerting and backup with a restore tested at least once. Documentation and operational handover as a runbook. Training and rollout. Data processing agreement, technical and organisational measures, deletion policy. Security review and ongoing dependency updates. Support SLA after go-live. A further-development budget for the first twelve months. And the third-party licence and hosting costs you pay directly: authentication, email delivery, map interface, search index.

A quote without a list of what is not included is not a quote. It is an entry price.

Straight to the core of the contract question: a fixed price is not safer, it shifts risk. And shifted risk gets priced in. With unclear requirements you pay a premium for an uncertainty you brought along yourself, precisely the factor Boehm located in every estimate made before requirements elicitation. We deliberately name no percentage for it: dependable numbers do not exist, and the rules of thumb in circulation are guesses.

The second effect is structural. Under a fixed price, every change becomes a change order. That creates a conflict of interest that costs your project time, money and trust. It is not down to bad faith, it is down to a contract that prescribes it. In projects where the business logic is still being learned, this is the most expensive construction you can pick.

Under a contract for work (§ 631 German Civil Code), the contractor owes the result. Payment falls due on acceptance under § 641, and defect claims exist. Under a contract for services (§ 611), the contractor owes the activity, and the project risk sits with you. That is the single line with the greatest economic consequence in the entire contract, and it appears in almost no quote.

Agile methodology does not decide the classification. In its judgment of 17 August 2017 (case 5 U 152/16), the Frankfurt Higher Regional Court ruled on a platform project run with Scrum that both contract types can apply side by side or alternately, and it deliberately left the general classification open. It affirmed the payment claim despite the aborted project, deriving it from the letter of intent combined with the practice actually lived: monthly individual commissioning, arrears billing by time spent, instalment payments. For buyers, the second part of the reasoning is the remarkable one. The court saw in the monthly commissioning of the following month an approval of what had been delivered so far, and therefore at least an implied acceptance, entirely without a formal acceptance protocol.

So anyone who settles invoices monthly and agrees on instalments may have accepted the work without meaning to. Write into the contract, explicitly, what triggers acceptance and what does not.

Our recommendation after several dozen projects: fixed price for a small, sharply cut first stage. There it can be calculated honestly, and it forces both sides into precision. After that, time and materials with a budget cap and a two-week release cycle. A vendor who cannot quote the first stage at a fixed price has not understood it. A vendor who quotes the entire project at a fixed price without having seen your interfaces has either priced in a large premium or is already planning the change orders.

This is where the market works least cleanly. The common rule of thumb is "15 to 20 percent of development cost per year", handed on from page to page and almost never backed by a source. The research picture is more interesting and more honest.

Franz Lehner of the University of Passau presented a meta-analysis on software maintenance costs at the 2021 GI conference on software management. Thirty publications from four decades were included; the study itself ran in 2020 at the university's chair for business information systems. Lehner points to the wide spread of the individual values and traces it back to the companies included, to selective data bases and above all to repeated averaging. The numbers are therefore unsuitable for trend analysis, he says, but usable as evidence of the order of magnitude. His own assessment:

As one reference point Lehner cites a CapGemini study: in 2017, around 47.3 percent of corporate IT budgets went to operating and maintaining hardware and software. For your planning that means: do not calculate operations as a percentage of development, but as its own item with its own justification.

Our own figures here are experience, not a study. Infrastructure for a typical B2B web application on EU servers runs €20 to €50 per month, high-availability €150 to €400. Pure operational effort is 2 to 5 hours a month: monitoring, security and dependency updates, plus small corrections. Over three years, most of our clients land at €40,000 to €80,000 in operating costs: operations without continuous expansion. If you want the application actively developed further, that needs its own budget: we price it at €4,000 to €12,000 per month depending on the pace, on top of the operating costs above and not included in them.

One point for the conversation with your CFO that no competitor mentions, under German tax rules. Under the German Federal Ministry of Finance circular of 22 February 2022, a useful life of one year may be applied to computer hardware and to the intangible assets operating software and application software. It applies to profit determinations for fiscal years ending after 31 December 2020. The circular explicitly counts as "software" applications tailored to the individual user, such as ERP or inventory management systems. The ministry also makes clear that this is neither an immediate write-off nor a new or special depreciation method: it is an option, not an obligation. Talk it through with your tax advisor; we do not give tax advice.

You do not recognise an underpriced quote by its price, but by six omissions. It shows no hours for analysis and architecture, so it was guessed rather than calculated. It documents no assumptions about user numbers, data volume, roles and interfaces. It names integrations without saying whether they are read or write. It says nothing about acceptance and test data. It has no chapter on operations and handover. And it names a lump sum without roles and rates.

Why that is more dangerous than it looks shows in a study by Bent Flyvbjerg and Alexander Budzier, published in Harvard Business Review in 2011. Across 1,471 IT projects, the average cost overrun was 27 percent. Every sixth project, however, was an outlier with an average cost overrun of 200 percent and nearly 70 percent schedule overrun. The necessary caveat: 92 percent of the projects came from the public sector, 83 percent from the US, and the average project volume was USD 167 million. Those are not mid-market projects, and the percentages do not transfer. The structure does: the risk does not sit in the average, it sits in the outlier. And the outlier appears exactly where nothing was clarified beforehand.

Put this list next to the PDF. Every question the vendor cannot answer in two sentences is a cost risk.

1. Does it state what is not included? The scope boundary is worth more than the scope description.

2. Are hourly rates itemised by role? A lump sum without roles cannot be compared with a second quote.

3. How many hours go to analysis and architecture? Under five percent of total effort means it was guessed.

4. Which assumptions are documented? User numbers, data volume, roles, volume model. Undocumented assumptions become your change orders later.

5. Are the integrations read or write? The most expensive distinction in the whole document.

6. Who provides test data, who supports acceptance? If the answer is "you", you need to plan internal capacity.

7. How does a change request work? Rate, lead time, approval path. Without a defined process, every change becomes a negotiation.

8. Contract for work or contract for services, and when does something count as accepted? This decides who carries the project risk.

9. Who owns the source code, where does the repository live, which third-party licences are included? With us the code belongs to the client; that is not the case everywhere.

10. What do operations cost in years two and three, including dependency updates? The item most often missing from budget requests.

11. Who keeps it running if we part ways? If there is no dependable answer, you are buying a dependency along with the software.

Eleven questions, twenty minutes of reading. They cost you less than the first change order.

Radically honest: there are four situations in which we advise against the project ourselves, even when we could win it.

First, when the process has not been settled internally. Software freezes a process; an unsettled process does not get better through software, it gets more expensive. Second, when standard software covers eighty percent and the remaining twenty percent is not a competitive differentiator. We worked that logic through using PIM as the example: build vs buy, and for portals under make or buy. Third, when nobody internally has time for acceptance and subject-matter questions: a software project needs your people, not only your budget. And fourth, when the trigger is a single complaint rather than a recurring process.

Not sure whether it has to be custom development at all? Website, web app and portal are three different answers with three different price tags. Settle that before the cost question: website, web app or portal.

The takeaway for all four cases: software does not solve an organisational problem. It makes it visible and bills it in day rates. Saying no early saves more money than any negotiation over the hourly rate.

The next step is not the quote. It is the requirements list that makes quotes comparable in the first place. Two to four pages are enough: the roles with their permissions, the three to five process steps in order, the connected systems with a note on read or write, plus the volume model. And finally the one sentence describing how you will know in six months that it worked. This document costs you two afternoons. It is the only investment in this project that pays for itself before the first invoice.

With that document, the spread of your quotes shrinks from a factor of 10 to something you can judge. Then you collect quotes, from us or from someone else. If you want to check your list against a real price range first, bring it to a free initial conversation: book thirty minutes here. We will tell you which of our three size classes your project falls into and which of the eleven questions is still open on your side. If we advise against it, we will say that too.