What does custom software cost? Honest numbers from the workshop

"What does custom software cost?" is the first question in almost every initial conversation — and the industry's usual answer is evasion. We try it differently: with real ranges from real projects since 2018, including the cases where we advise against building.

The usual "it depends" isn't wrong. A project with three integrations costs different money than one with a single interface. But a decision-maker who gets no ballpark at all can't even judge whether the first conversation is worth their time. That's why our price ranges are public on our website — and here they are again, with the context an offer page has no room for.

Three shoe sizes instead of one number

For years we've sorted projects into three sizes — patch, module, platform. It sounds like a sales slide, but it's the most honest structure we've found for cost conversations. Because the three sizes differ not just in price, but in the kind of risk.

1. Patch: €8,000–25,000 net, 5–20 working days. One concrete extension to an existing system — an API connection, an importer, a lean capture app. The existing system stays untouched; we build next to it.
2. Module: €25,000–80,000 net, 4–12 weeks. A dedicated tool that fits exactly your process: its own web app or mobile companion, integration into two to four existing systems, an admin backend with roles and audit log. This is the most common case on our desk.
3. Platform: from €80,000 net, 3–9 months. A new product — marketplace, app product, industry platform. With real discovery up front, delivered and approved in phases.

The full breakdown is on our studio page. More important than the ranges themselves is the distribution: most enquiries that arrive as "we need software" turn out, on closer inspection, to be a patch or a module. Only a fraction genuinely needs the third shoe size — and if someone tries to sell you that one first, skepticism is warranted.

One more note on the ranges themselves: they're deliberately wide because they're honest. A patch against a well-documented API lands at the lower edge, one against a legacy system with a file-based interface at the upper. The fixed-price sketch after the first conversation then replaces the range with a concrete number — in writing, with assumptions, for each of the sizes in question.

What really drives the price

Within the ranges, it's not the number of screens that decides the price. It's five things that almost never come up in first conversations:

• Interface quality. The question is never whether DATEV, SAP or Shopware can be connected — it's how well the respective API is documented. A clean REST API is a matter of weeks; a CSV export from the nineties is a matter of months.
• Roles and permissions. "Everyone should see everything" holds exactly until the first payroll record. One user type quickly becomes four during the conversation — and every role costs logic, tests and maintenance.
• Offline capability. Construction site, workshop basement, underground car park: if the tool has to work without a connection, that easily doubles the effort in the data layer. Sync conflicts aren't a side topic, they're the topic.
• Legacy data. Cleanly importing ten years of Excel history is its own sub-project — with duplicates, format breaks and three columns whose meaning nobody remembers.
• GDPR and operations. Data processing agreements, deletion concepts, EU hosting, backups. Unspectacular but mandatory — and already priced into any serious provider's offer.

And the reverse holds too: what rarely drives the price is what gets discussed the longest — colours, logo placement, the dashboard. The expensive metres lie beneath the surface.

Fixed price or hourly rate?

Our answer is unspectacular: both, depending on the shoe size. Patches we offer at a fixed price — the scope is small enough to be fully understood beforehand. For modules and platforms we work in 2-week sprints, each sprint approved individually. The client sees every iteration and can exit at any time.

A hard fixed price across six or nine months, on the other hand, is something we warn against — even though it sells well. Nobody knows a large project well enough beforehand to price it seriously. So one of two things happens: the provider prices in a risk buffer that you pay in any case. Or they calculate tightly and claw the margin back later through change requests — and then every small change becomes a negotiation.

For context: the hourly rates behind it

Behind every project sum there's a day's work in the end. Typical hourly rates for custom software development in Germany range roughly between €90 and €140 net, depending on experience, region and provider size. Significantly below that, you should get suspicious: either someone is planning a junior-heavy team that makes the project more expensive overall, or the effort has been talked down and will grow back later. Significantly above it, you're often paying for overhead — project offices, layers of hierarchy, hallways — that never arrives in the product.

What a serious quote has to contain

No matter whom you ask — five points separate a solid quote from a glossy estimate:

• Assumptions, in writing. Which interfaces are assumed, what data quality, what involvement from your side? If the assumptions are missing, the basis for every later discussion is missing.
• What's not included. An honest quote has an out-of-scope list. It's uncomfortable — and the best protection against the argument in month four.
• Operations and maintenance as their own line item. Whoever stays silent about operations is selling only half the truth.
• Code ownership and handover. Repository, documentation, rights — with the client from day one, otherwise you're buying yourself a lock-in.
• An exit point. Sprint approvals or milestones where you can leave without drama. Whoever doesn't offer that is planning on your dependency.

The running costs nobody puts in the quote

Software isn't finished after launch, it's in operation. Hosting, security updates, library maintenance, small adjustments when a connected system changes. As a guideline: whoever budgets 10–15% of the build cost per year for upkeep rarely gets surprised. Whoever budgets zero pays it later anyway — in one large, unpleasant lump.

When custom software isn't worth it

Honesty has to work in both directions. In a good share of our initial conversations we advise against building. The four most common patterns:

• Standard software covers 90% — and the remaining 10% is negotiable. Then: buy, and adapt your process. That's cheaper than any custom build, and faster anyway.
• The process still changes monthly. Software pours processes into concrete. Whoever automates a process that's still finding itself builds twice.
• The savings are under two hours per week. Then the Excel sheet is the right software. Really.
• Nobody in the company feels responsible. Software without an internal owner goes to seed — no matter how well it's built.

The last point is the most underrated one. The best software in our projects was never the technically most elegant — it was the one with the most committed internal owner: the person who collects feedback, sorts priorities and defends the tool in daily business. Without that role, we wouldn't start a project today.

The calculation that matters

The most useful cost question isn't "What does the software cost?" but "What does the gap cost — per week?". A sample calculation from the typical patch range: a staff member bridges a system gap for two hours a day — retyping, copying over, keeping records in sync. That's ten hours a week, at €40 fully loaded cost per hour around €18,000 a year. A €15,000 patch has paid for itself in under a year. Everything after that is profit — not counting the lower error rate and the staff member's nerves.

From this follows our rule of thumb, the same one for years: two saved hours per week and person amortize a patch project within quarters, not years. If you're below that threshold, you shouldn't hire us. If you're clearly above it, every month of waiting loses you money.