Custom software costs depend on what you’re commissioning and what it takes to use it day to day. A price list using labels such as MVP or business platform leaves too much undefined. This guide helps you break down a quote and calculate costs over several years. For the broader decision, read our custom software guide; the explanation of code ownership and supplier dependency covers handover arrangements.
How is the price of custom software determined?
The development price follows from the agreed behaviour and the conditions in which the software must work. Screen count isn’t a useful measure on its own. One button might save a record, or it might trigger checks across several systems with different permissions and failure handling.
A useful scope describes a task someone needs to complete. For example, an employee submits a request, a manager approves it and administration processes it. Add what happens after a rejection or when information is missing. The developer then sees more than screen names, and you can later judge whether the agreed work has been delivered.
Existing data can change the estimate. Who checks duplicate customers, missing addresses or inconsistent product codes before migration? Who decides which value is correct? This isn’t always programming work, but someone must do it. A quote assuming a clean file is hard to compare with one that includes repairing the file first.
Which items should appear separately in a quote?
Ask the supplier to describe each item so you can see what it delivers. You don’t need an hourly breakdown for every button. You do need to recognise whether design, testing and introduction are included or will be charged later.
| Item | Explanation to request | Assumption to discuss |
|---|---|---|
| Investigation and scope | Process, roles, exceptions and feasibility | What remains unknown? |
| Design and development | Functions and screens for the agreed tasks | What’s outside the first version? |
| Integrations | Data and operations for each external system | Are an API and test environment available? |
| Migration | Sources, cleanup and checks on transferred data | Who supplies which data? |
| Testing and security | Checks on behaviour, permissions and recovery | Which results will you see? |
| Introduction | Installation, instruction, documentation and transition | Who helps if the first working day goes differently? |
| Maintenance | Upkeep, support and external services | Which costs recur? |
An integration involves more than its first successful exchange. Discuss an outage, a duplicate submission and a change on the supplier’s side. Our guide to connecting software explains how to define that exchange. Don’t ask for a universal price per integration before the systems and operations are known.
Security also belongs in design and development. The NIST Secure Software Development Framework describes security practices within the development process. Use it as a starting point for asking which checks and commitments appear in the proposal. Citing a framework doesn’t, by itself, prove that your application has been tested.
How do you calculate the cost over two years?
The example below is entirely hypothetical. The figures were chosen to demonstrate the calculation. They aren’t market averages, supplier rates or TopDevs prices. We assume equal usage in both years, no price rises and no new features. All amounts exclude VAT and are shown in euros.
| Cost item in this example | Year 1 | Year 2 |
|---|---|---|
| Development of the agreed application | €20,000 | €0 |
| One-off data migration | €2,000 | €0 |
| Hosting, assumed at €100 per month | €1,200 | €1,200 |
| External services, assumed at €60 per month | €720 | €720 |
| Agreed maintenance | €2,400 | €2,400 |
| One-off instruction | €1,000 | €0 |
| Subtotal for these items | €27,320 | €4,320 |
That adds up to €31,640 over two years. The €20,000 development quote is one part of the calculation. In this example, development, migration and instruction don’t recur in year two, while hosting, services and maintenance continue.
This still isn’t a complete business budget. Internal hours, possible extra training, new functions and unexpected recovery work haven’t been entered. Add them for your project. Account for the transition too: if the old and new systems run side by side temporarily, you may have two subscriptions or maintenance agreements during that period.
You don’t have to hide uncertainty inside one precise total. Alongside the base budget, calculate a scenario with more users or an extra integration. State which assumption changes. That shows where a decision will be needed if the scenario occurs.
Which costs recur after delivery?
Ask what maintenance actually includes. It might cover security updates, backup checks, incident recovery or adjustments to a changed integration. New functions are different work again. A monthly amount should always come with a description of the service.
Office-hours support differs from availability outside those hours. An agreed response time isn’t a deadline for resolving every problem either. Discuss who can report an incident, who decides its severity and who can put a temporary manual process in place.
External services have their own terms. Examples include email delivery, payment processing and AI models. If the application uses AI, budget for that usage separately with the method in AI agent costs. Owning the custom code doesn’t make those services free or give you control over their prices.
Don’t forget responsibility for how the system is used. Someone needs to grant access to new staff, check whether reports still make sense and communicate changes in the business process. Decide who does that in your company. Otherwise, a technically working application can continue running with outdated information or instructions.
Should you choose a fixed price, hourly billing or a budget cap?
A fixed price suits work that’s defined clearly enough. The price applies to that scope. If you later change the intended behaviour, there should be a process for agreeing the effect on cost and planning. A fixed price doesn’t include every future requirement you might think of.
Hourly billing may suit investigation or work whose direction is still changing. Ask for visible progress, reporting on hours used and points where you decide whether to continue. Without those arrangements, you can receive invoices while struggling to judge whether further spending makes sense.
With a budget cap, establish what happens as the limit approaches. Does work stop, does the scope shrink, or is further approval required? The word cap doesn’t answer that. At TopDevs, we agree a fixed price in advance for the defined assignment; its scope remains the starting point.
How do you compare suppliers beyond their hourly rates?
Give each supplier the same example process and assumptions. Ask them to raise questions where information is missing. Then compare proposals by deliverable: included, excluded or still unclear. A blank item may matter more than a small price difference.
Ask who will do the work, explain design decisions and provide support after delivery. A freelancer may have cover and handover arrangements, while a larger agency might concentrate knowledge in one person. Judge continuity by the commitments and people available, rather than the company’s legal form or size.
Discuss acceptance too. Which tasks must your team be able to complete before approving a deliverable? Use your own examples. A supplier might demonstrate that a form works, while you need to know whether a rejected request returns to the employee with the correct reason.
How do you avoid a promising budget becoming an expensive choice?
First check whether an existing package supports the task well enough. Custom software doesn’t automatically save on licences: you’re also taking responsibility for your own application. Our comparison of AFAS and custom software explains why the suitable route depends on the process.
Then tie the investment to a measurable problem. What duplicate work happens now, who is affected and what should change after introduction? Include checks and exceptions. Expected time savings need testing; they aren’t a guaranteed return you can already deduct from the price.
Finally, consider the cost of change. Can you export data, is the behaviour documented and can another supplier take over maintenance? With TopDevs, the code is and remains yours, but a useful handover also requires access, documentation and arrangements for external services.
How do you actually get started?
Choose a process you want to improve and describe the smallest version your team could use in practice. Add examples, user roles and existing systems. Then ask for a proposal separating the one-off investment, recurring items and assumptions that still need testing.
If you’re considering custom software development, we can discuss that first scope together. With a concrete task on the table, it’s easier to see the investment required and which requests can wait. Book a call.
