The short answer
What custom software costs cannot be stated reliably before an analysis. That is not an excuse but follows from the subject: the price depends on what the application has to do from a business point of view, which systems it talks to and whether it is built from scratch or intervenes in an existing system. Any figure named beforehand is an assumption with a safety margin.
What can be said: classically, custom software is calculated as person-days times day rate. With AI-assisted development, this calculation shifts considerably. In our experience, the actual effort is one third to one fifth of classic estimates. Two projects where we tracked this are shown further down.
How custom software is classically estimated
A classic estimate breaks the project down into functions, estimates the person-days for each and adds them up. On top come project management, testing, coordination and a buffer for whatever nobody can foresee. The result multiplied by the day rate gives the quote.
This method is not wrong, but it reflects a particular way of working: people write code one after another, tickets wait for developers, implementations wait for review, reviews wait for testing. A large part of the estimated time is not work but waiting time between stations. It is paid for all the same.
What the price depends on
Regardless of how development is done, the same factors determine the effort. If you know them, you can assess quotes better.
Business scope and rules
It is not the number of screens that drives effort but the rules behind them: approval levels, special cases, calculations, deadlines. An application with few pages and many exceptions is more work than one with many pages and clear workflows.
Interfaces and third-party systems
ERP, CRM, accounting, single sign-on, partner services: every interface brings access, test data and coordination with another team. In our experience, this is where projects most often stall. That is why we clarify interfaces before implementation, not after.
Greenfield or existing system
Greenfield is faster than an existing system. On a greenfield project, the business domain alone decides the pace. In established systems, what was built years ago also has a say. If tests and a reliable pipeline are missing there, we build them first. The first weeks then go into safeguarding, after which it gets faster.
Data migration
Data from spreadsheets, legacy systems or exports has to be cleaned, mapped and checked. The effort depends less on the volume of data than on its quality.
Security, data protection and approvals
Roles and permissions, logging, requirements from data protection or from your customers: all of this belongs in the scope. Approvals from data protection, the works council or IT security add to it. They run in your calendar, not in our pipeline, and should appear in the plan as milestones of their own.
What AI changes about the estimate
In our process, several AI agents work on tickets in parallel: interface, API, data model and tests at the same time. An orchestrator distributes the work; architecture and decisions stay with us. Tests and several review instances run automatically alongside. How this looks in detail is described under AI-assisted software development.
Two shifts follow from this:
- Implementation is no longer the expensive part. What used to tie up most of the person-days runs in parallel. Tests and documentation are produced along the way and not afterwards.
- Waiting time disappears. When implementation, review and documentation no longer wait for each other, exactly the item that runs invisibly inside classic estimates shrinks.
What does not change belongs in the calculation just as much:
- The analysis with your specialists. What gets built is decided by people who know the business.
- Your acceptance. Technically green does not yet mean correct from a business point of view. Your side checks and decides that.
- Approvals and coordination outside the project.
An AI-assisted estimate is therefore not simply the classic figure with a discount. It distributes the effort differently: less in implementation, the same in analysis, acceptance and approvals.
Two projects in numbers
In two projects, we compared the classically estimated effort with the actual effort. The figures are measured, not extrapolated.
| Project | Classically estimated | Actually needed |
|---|---|---|
| A patent administrator in Munich | 75 days without AI assistance | 9 days |
| A specialist application in which we are ourselves involved | 310 person-days | 140–160 hours |
A candid note on the second row: this is not a customer reference. Our Managing Director is involved in this product, which is why it appears here without a name.
Two projects are not statistics, and no project is like another. Our figure from experience across further projects is therefore worded more cautiously: one third to one fifth of classic estimates. In established systems, getting started takes longer because tests and pipeline come first. Those weeks belong in any honest calculation.
Why we only name a framework after the analysis
Our approach begins with an initial conversation in which we clarify whether the project suits us. The analysis follows: requirements, interfaces, feasibility and milestones, together with your specialists. This is where it is decided whether a project is viable.
At the end of the analysis there is a clear framework: what will be built, in which steps and how you can measure progress. During implementation, you see a working version after every iteration, which you review and approve. That way you do not find out at the end of the project whether the budget is enough, but at every milestone.
How to recognise a reliable quote
Whether classic or AI-assisted: put these questions next to every quote for custom software.
- Which assumptions are behind the figure? A quote without stated assumptions is an estimate without a basis.
- How are interfaces accounted for? With access, test data and contacts on the other side?
- Which milestones are there, and what is available in working form at each of them?
- How is testing done? Automatically with every change, or at the end in a test phase?
- Who owns the code and infrastructure? Are both in your repositories and on your accounts?
- What does operation cost after launch, and who takes it on?
Do not forget running costs
Launch is followed by operation: hosting, monitoring, updates, bug fixing and further development at the pace of your business. These costs depend on your availability requirements and the pace of change. Per-user licence fees as with standard software do not apply to your own application.
We operate and, on request, continue to develop the applications we build. The LeafConnect case study shows what that looks like in everyday work. If your starting point is a spreadsheet that has grown over the years, also read When Excel is no longer enough: five signs you need your own application. How we build custom software is described under AI-assisted software development.