Guide

Custom software: ongoing costs and operation

The project price is only part of the calculation. What actually arises in effort and costs after going live — and which item is most often forgotten.

Quote on requestfrom 8 weeks to first versionAs of 2026
In short

After going live, custom software typically requires just a few hours of maintenance per quarter, plus hosting, licenses and third-party usage-based fees. The most frequently forgotten item is not the money, but the responsibility: systems become outdated because no one is assigned, not because maintenance is demanding.

01 — Operation

What ongoing operation means

After settling in, the effort is low, but not zero. For custom software, that's typically a few hours per quarter: additions when something changes in your offering, a look at the logs, occasional corrections.

More important than the scope is the responsibility. Systems don't become outdated because maintenance is demanding, but because no one is assigned. One person with a recurring calendar appointment solves this problem completely.

What additionally arises on an ongoing basis depends on the setup — hosting, licenses and third-party usage-based fees belong in the same calculation as the implementation. We show this separately in the quote instead of hiding it in the project price.

02 — Factors

What drives the price

  • Scope and number of integrations. Every additional system that needs to participate costs effort — regardless of how simple the core is.
  • State of your starting point. Clean data, existing content and documented processes significantly reduce effort. Chaos is the most expensive cost factor.
  • How much new material needs to be created. What you can contribute doesn't need to be invented by anyone. This is the biggest lever you have in your own hands.
  • Requirements for design and customization. A solid standard system costs a fraction of a custom solution — and is sufficient more often than vendors admit.
  • Operating model. One-time project costs or ongoing support: calculated over three years, this often gives a different picture than the quote comparison.

03 — Contract

What needs to be clarified in writing

  • Ownership of data and access. They belong to the client. If a provider won't clearly confirm this, that's the most important information from the conversation.
  • Handover upon termination. In what format, within what timeframe, at what cost.
  • No minimum term without consideration. Lock-in is justifiable if something is delivered in return — otherwise not.
  • What a later change costs. The total cost isn't determined by the project price, but by the hourly rate in year three.
  • Documentation as a deliverable. Not as a promise, but as a line item in the proposal.

04 — Questions

Frequently asked questions

Can we start with a spreadsheet?

Often yes, and that's a good test. If the spreadsheet maps the process and only fails due to multi-user capability, permissions, or data volume, the requirement is clear and the project is calculable.

How many users can a system like this handle?

That depends on the architecture, which we plan according to your expected growth — from a few users in your own business to several hundred across multiple locations.

How do we avoid the project going off the rails?

Small steps with usable results, fixed budgets per step, and the option to exit after each step. Large fixed-price projects over twelve months are the most reliable path to disappointment — for both sides.

Does this run on our own servers or in the cloud?

Both are possible. For most businesses, a cloud solution is lower-maintenance; where data must not leave the premises, we set it up on your own infrastructure.

Who owns the source code?

You do, completely, upon payment. That's in the contract. You can take it to any other developer — that's the point.

When does custom software pay off compared to standard software?

When your process is a genuine competitive advantage, when standard software only fits seventy percent and the rest ends up as manual work, or when license costs per user exceed the development cost over a few years. If it's only about convenience, standard software is cheaper.

What if we discover new requirements during development?

That's normal and planned for, because we work in small steps. A new requirement is incorporated into the next step, instead of stalling the entire project.

Next step

Send us a few sentences about your project.

We read every inquiry ourselves and respond personally. No sales team, no callback form into the void.