“How much does software cost?” is a fair question. Even so, it can’t be answered with a single number. A holiday planner for one team and a customer portal connected to the ERP and accounting system are both called “software”. In terms of effort, they are worlds apart.
That is why you won’t find a price list in this guide. Instead, you’ll learn which factors determine the price, how the billing models work, which costs come on top after go-live and how to make quotes comparable. If you want to have software developed, this lets you describe your project in a way that makes an estimate reliable.
The project calculator gives you the actual figure: you answer up to eight short questions and receive, by email, a cost range, the approximate delivery time and the factors driving the effort most in your case.
How the price is made up
Software development is almost always calculated on effort: how many person-days does the team need for concept, design, development, testing, project management and roll-out? The price follows from this effort and the day rate. A fixed price is, at its core, an effort estimate too, plus a premium for the risk the provider takes on.
Programming is only one part of it. Clarifying requirements, designing interfaces, testing, aligning and rolling out all take time that never shows up in a feature list. If you only look at the programming, you will underestimate the total effort.
The cost drivers at a glance
Ten factors determine how much effort goes into your software. The project calculator asks about the first seven as well, because they make the biggest difference.
1. Type of application
An internal business application has known users within your own company. A customer or partner portal opens up to external users, with login, registration and support cases. A SaaS product has to work for many customers at once, with separate data per customer, billing and its own onboarding. With each step, the baseline effort rises before the first business function has even been built.
2. Process scope and features
Scope is the biggest lever. Every process the software covers needs input screens, business rules, error cases and tests. A focused first module for one core process is something completely different from an application that connects several departments. That is why many projects start with one core process and expand from there.
3. Interfaces
Accounting, ERP, CRM, email delivery, payment providers: every integration needs coordination with the other system, error handling and its own tests. A lot depends on how well the other side is documented. A clean REST API is connected quickly; a legacy system that exports a CSV file overnight is not. The more systems there are, the more effort it takes to test everything together. How we build integrations is described on the page on API integration.
4. Roles and permissions
If all users see the same thing, the permission model is built quickly. With roles such as team, management and administration, the number of views and checks grows. It gets really complex with permissions per record, approval workflows or multiple tenants that must be strictly separated from one another. That needs a dedicated authorisation concept, and every rule has to be tested.
5. Data migration
If data is to be taken over from a legacy system, that means mapping fields, cleaning up duplicates and legacy clutter, and rehearsing the move several times. Master data such as customers and products is manageable. If you also want to bring over transaction data and the full history, you need considerably more trial runs. Hardly anyone knows in advance exactly how clean the data in the legacy system is. That is why every plan needs a buffer here.
6. Interface and design
Proven UI components, lightly adapted to your brand, are the cheapest route and often entirely sufficient for internal tools. If you supply a finished design, it gets implemented. A dedicated concept with user research, drafts and feedback rounds pays off above all where external users are meant to use the software voluntarily.
7. Add-on packages: ERP, billing, languages, AI
Some features bring so many requirements of their own that they count as separate packages: an ERP integration, billing with subscriptions and invoices, a multilingual interface or an AI feature such as an assistant or document analysis. Only plan for what is definitely coming. Anything that might come “later” should be allowed for by the architecture, but not sit in the first budget.
8. Compliance: GDPR, accessibility, industry requirements
If the software processes personal data, a deletion concept, logging, access rights and data processing agreements (DPAs) are part of the job. Whether the BFSG (German Accessibility Strengthening Act) applies depends on whether you offer the application to consumers and in which area. It does not apply to many internal tools. Where it does apply, plan accessibility in from the start, because retrofitting costs more than thinking ahead. Industries such as insurance, healthcare or finance bring their own requirements that extend documentation and testing.
9. Quality assurance
Automated tests, code reviews, test environments and acceptance testing take time. That is exactly why they are the first things to disappear from tight quotes. It comes back to bite you later: without tests, every change becomes risky and therefore expensive. In every quote, ask which tests are included and who prepares the acceptance.
10. Team and seniority
An experienced team has a higher day rate, but often needs fewer days for the same task and makes architecture decisions that don’t have to be corrected at great cost later. So never compare day rates alone; always compare the estimated total effort and who will actually work on the project. Your side counts too: one contact person with decision-making authority saves more feedback loops than any methodology.