How Much Does Custom Software Cost? Plan With Confidence

Software Selection · 9 min

Illustration: cost frame for custom software as coin stacks next to software building blocks with one golden coin

You want to prepare quotes faster and have them checked before they go out. What the software costs depends on the effort that workflow takes to build. An initial calculation is: person-days for each phase × the corresponding day rate, followed by external costs and ongoing operation. The example below makes that effort tangible. For your own project, one everyday example is enough to start.

What you can calculate with

Suppose your sales staff prepare quotes from a maintained product and price list. A small internal application should import that list as a CSV file, calculate quotes and produce PDFs. Discounts above 10% need the sales manager's approval. Sales staff and the sales manager use the application. Sign-in uses an existing company account, with its integration included in the plan. Sending quotes, invoicing, migration of historical data and a direct ERP connection are excluded.

The allowances below were chosen for this fictional calculation. They are not measured project times, a delivery promise or an estimate for your business. One person-day here means eight hours of one person's work.

Understand the workflow: 2 person-days. Review sample quotes and agree the discount rule and intended result.
Prepare the data: 2 person-days. Build the CSV import and handle missing product numbers or prices.
Create quotes: 5 person-days. Implement entry, calculation, saving and PDF output.
Sign-in and approval: 2 person-days. Connect company sign-in, set who can view and edit quotes, and implement discount approval.
Verify: 3 person-days. Test calculations, invalid data, permissions and approval with sample quotes and fix defects.
Introduce the application: 2 person-days. Deploy it, complete acceptance with sales staff and document how to use it.
Contingency: 2 person-days. Allow for corrections within the described scope.

The calculation is: 2 + 2 + 5 + 2 + 3 + 2 = 16 person-days, plus 2 days of contingency, giving 18 person-days or 144 hours. That does not mean 18 calendar days: questions, approvals and team availability also affect elapsed time. Your staff's time for examples and acceptance is additional. Hosting, licenses and later maintenance are not included here.

If the application should instead read products directly from the ERP, that connection needs a separate allowance. Adding 3 days to build it and 1 day for its tests takes the same example from 18 to 22 person-days. Those four days are also an assumption. If a usable interface or access rights are missing, they need investigation before the extra effort can be estimated.

Day rates reported by a market survey

A published comparison comes from the Lünendonk 2023 study of Germany's IT services market, page 54, figure 26. For software development fees in 2022, it reports an average minimum day rate of €766 and an average maximum of €1,298. The figure's 2022 data covers 39 participating IT service providers. These are averages of their lower and upper list prices, not a universal price range or a current 2026 price list. Source checked on 28 October 2026.

These survey figures are not CERTAINCE day rates or a quotation. To compare proposals, you need each provider's rate and their effort for the same scope. If discovery, development and introduction have different rates, multiply the days in each phase by its corresponding rate. Our proposal states the price for the agreed scope. Neither this example nor the survey establishes a CERTAINCE project price.

Six characteristics that drive the price

The size of the result. A single workflow such as a quote, a month-end closing or a customer request is considerably cheaper than a bundle of them.
The number of steps and handovers. Every change between people or programs needs its own rule for what is passed on and what happens when something is missing.
Who checks or decides. Approvals, deputies and different permissions cost more than a workflow one person carries out alone.
Connecting existing programs. Business Central, DATEV or a CRM can usually be connected; the price depends on whether the interface is documented and how clean the data behind it is.
The number of exceptions. The normal case is built quickly. Each exception everyone in the company knows about needs its own rule, owner or check and therefore adds effort.
What should be measurably better in the end. Sending quotes faster, entering data only once or seeing the current status immediately take different amounts of work, and the answer decides which first step is worth taking.

The automated DATEV export shows how much weight those characteristics carry. Accounting continues to work in Business Central and checks the completed export file before it goes to DATEV. The software handles the recurring steps. The interface offers upload, preview and download; the application carries the posting rules and the DATEV format requirements. Since that project, we ask every proposal, our own included, how many exceptions the price covers and what happens to the rest.

What has to be settled before a dependable price

A price becomes dependable once four things are settled. When one of them is missing, the proposal carries an assumption, and assumptions are either confirmed during the build or they become expensive. Anyone who does not raise these four points before the proposal is naming a price for software they do not know yet.

Which work the software takes over and which work stays with a person.
Which exceptions the price includes and which ones cost extra later.
Which existing programs are connected and which data they supply for it.
How you will know in everyday use that the solution works correctly.

How you get a proposal

The starting point is a free AI assessment. For a clear build, it leads to a short plan with the expected hours and a ceiling; if the build is too large or uncertain to bound, we first settle the open points in an analysis workshop or a pilot, billed by the hour.

What makes a proposal easy to understand?

A good proposal explains clearly which work the software will handle and what belongs to the first step.
The project is divided into manageable steps. You can always see what is finished and what comes next.
New details are discussed as soon as they appear. You decide with the developer whether to include them now or later.
Real examples show before the build what the software needs to do in everyday work.
Tests and careful code review help the solution run reliably and make later extensions possible.
The code, data, and access belong to you. Maintenance and later changes are explained clearly as well.

Consider total cost and benefits together

Compare total cost over the period you intend to use the solution. For off-the-shelf software, count the licenses, adjustments, and time spent on work that still has to be done by hand. For custom software, include development, operation, and later changes. Then consider the everyday benefit. Faster quotes or entering data only once may matter more to your company than the lowest starting price.

Off-the-shelf software: setup + licenses + adjustments + additional manual work + the cost of changing later.
Custom software: capturing the workflow in detail + development + introduction + operation + later changes.

Use the same period for both paths and include the time your employees actually spend. A detailed guide is in Custom Software vs. Off-the-Shelf. See custom software development for how your first description becomes an accepted solution that you own. Custom software is one of several paths; the others are in the AI services overview.

How does AI help with development?

AI can accelerate drafts and recurring development work. It does not remove the business review that determines whether a solution represents the workflow correctly. A serious price therefore still includes clarification, testing and long-term maintenance; saved writing time is not a reason to leave that work out of the proposal.

Can I get a cost estimate with an initial idea?

Yes. One example from your working day is enough as a starting point. Describe how the workflow runs today, what you want to improve and which exception creates the most effort. From that, the useful next step, the remaining open questions and an initial budget range can be derived. You do not need a technical specification yet.

Do I need to describe my workflow completely myself?

No. Describe the workflow as you know it. Walk through the individual steps, the roles involved and typical exceptions. The provider should record the details that matter for the software and translate them into a technical description that can be built. Ask them to explain that translation back to you in everyday language.

What helps with an initial cost estimate?

What helps most is three to ten real examples, such as a quote, an invoice or a spreadsheet you use. The names of the programs you work with today and one known exception are helpful as well. No further preparation is needed. Real examples make the rules and the open questions that determine the price visible.

When does a pilot help?

A separately agreed paid pilot tests a specific uncertainty with real examples, such as whether the available data is sufficient for a solution. It is needed only when that question cannot be answered in conversation.

When is a dependable budget frame possible?

A budget frame becomes possible once the scope, important exceptions and intended result are clear. For a simple project, the free AI assessment may be enough. If the build is too large or uncertain, an analysis workshop or a pilot resolves the open points before the proposal. The proposal names its assumptions and explains which changes trigger a new estimate.

The one exception that costs your team the most effort is the best starting point, so let us discuss a concrete workflow.