Custom software cost is determined less by the number of screens and more by how many rules, how much data and how many connections the software involves. Of two applications that look the same, one may be finished in a few weeks and the other may take months. We don't give a price list in this article, because a figure quoted for software whose scope is unknown would be misleading. Instead, we explain the factors that will help you read quotes correctly.
In short
- Cost is driven mostly by scope (the number and depth of features), business rules, integrations and user roles.
- The level of design, the number of platforms (web, iOS, Android), data migration and security requirements also affect the budget.
- The cost of software doesn't end at delivery: hosting, maintenance and further development are ongoing expenses.
- An MVP (minimum viable product) approach reduces risk and lets you grow the budget according to real needs.
- When comparing two quotes, check whether the scope is the same before looking at the price.
8 factors that determine the price of custom software
1. Scope: the number and depth of features
This is the biggest factor. "Customer records" looks like a one-line feature. But if a customer will have multiple addresses, contacts, devices and a history of records, and if search, filtering and export are also needed, the same feature grows several times over. Writing down each feature in terms of "who does what, in which steps?" before asking for quotes is the step that saves the most money.
2. Business rules and exceptions
The real effort in software lies in coding the rules and exceptions. Rules such as "send a reminder if a quote isn't approved within 10 days," "apply a different price to a specific customer group" or "an order that has gone into production can no longer be changed" don't appear on screen, but each one needs development and testing. We explained the difference between the screens users see and the rules behind them in our article Frontend vs. backend.
3. Integrations
If the software needs to talk to other systems (accounting software, e-invoicing, SMS, WhatsApp, payments, shipping, machine data), each connection is a separate work item. What affects the cost:
- Whether the other system has a documented API,
- Whether it offers a test environment,
- Designing what happens when things go wrong (a dropped connection, missing data).
Working with a well-documented API is usually far more predictable than exchanging data with an old, undocumented system.
4. User roles and permissions
Software with a single type of user is not the same as software where different roles, such as "manager, sales, field staff, accounting, customer," see different screens and have different permissions. Each role adds views, permission checks and test scenarios.
5. Platforms
Is it a dashboard that runs only in a web browser, or do you also need iOS and Android apps? Each platform affects the design, development, testing and release process. If you need a mobile app, approaches that ship to both platforms from a single codebase are an option that affects the budget, but they may not be the right choice for every project.
6. Level of design
There is a significant difference in effort between admin screens built with a ready-made UI kit and customer-facing screens designed specifically for the brand. For internal screens, simplicity and speed come first; for customer-facing screens, brand and user experience take priority.
7. Migrating existing data
Moving data that sits in Excel files, in an old program or in several sources into the new system often takes longer than expected. Cleaning, matching and validating the data is a separate job.
8. Security, backups and legal requirements
In software that processes personal data, measures such as access logs, authorization, encryption and backups should be designed in from the start. If your industry has specific legal requirements (e.g. electronic documents, record retention periods), these should also be included in the scope.
Costs after delivery
Thinking of software cost only as the development fee is the most common budgeting mistake. After delivery, these expenses continue:
- Hosting: Server, database, backup storage, domain and SSL. This cost changes as the number of users and the amount of data grow. We covered hosting options in our article What is web hosting?
- Maintenance: Updating the language, framework and libraries used, security patches, bug fixes. In software that isn't maintained, risk builds up over time; you can find the website equivalent in our article Why is website maintenance necessary?
- Further development: As your business changes, new features become necessary. Living software that evolves is more normal than software that never changes.
- Third-party fees: Services charged per use, such as SMS packages, messaging services, maps or payment services.
Putting off maintenance also has a hidden cost. In software, this is called technical debt: as Martin Fowler explains, problems in the internal quality of the code make every new feature take a little longer and cost a little more, just like the interest on a debt.
Ask how a quote handles these items. The answer to "How long does post-delivery support last, and what happens after that?" should be in writing.
The MVP approach: start small, grow with real data
MVP (Minimum Viable Product) is a Lean Startup concept popularized by Eric Ries in 2009. As the Agile Alliance explains, an MVP is the version of a product that delivers the maximum validated learning about users with the least effort. There is an important caveat: an MVP doesn't just mean "the fewest features"; it must be viable enough to produce meaningful results in real use.
In custom software, the MVP approach can be applied like this:
- Pick one core problem. For example, "service records get lost on paper."
- Define the shortest flow that solves that problem. Open a record, assign it, close it, report on it.
- Limit the first version to that flow. Leave integrations and "nice to have" features for the second phase.
- Use it with real users. Watch what the team uses and what it skips.
- Plan the next phase based on the data.
The effect on your budget: you don't spend money up front on features nobody will use, and you put most of the budget into work that has been proven to be needed.
How do you compare two quotes?
Two quotes with different prices often don't describe the same work. Before comparing them, look at:
- Scope list: Which features, roles and integrations does each quote include?
- Assumptions: Notes such as "data migration not included" or "design will use a ready-made template" change the price significantly.
- Testing and delivery: Who is responsible for the testing process, acceptance criteria and going live?
- Ownership: Who will control the source code, the server and the data? We covered this in detail in our article What is custom software?
- After delivery: How are maintenance, bug fixes and new development charged?
Stating your budget up front also helps. It lets the team propose the most useful scope possible within that budget.
Our experience
In custom software projects (CRM, dashboard, SaaS and API work), we base the price on the detail of the workflow, not on the number of screens. Before quoting, we write down the existing process step by step and list what goes into the first version separately from the later phases. That way you can see where the budget goes, and there are fewer "wasn't that included?" debates during the project. We describe how we work on our Engagement Models page.
Frequently asked questions
Why isn't there a fixed price for custom software?
Because the factors that determine the price (rules, integrations, roles, data migration) vary greatly from project to project. A price given before the scope is clear will either be unnecessarily high or a figure that has to change later. Once the scope is written down, the estimate becomes much more reliable.
Does MVP mean a cheap, half-finished product?
No. An MVP is a usable first version that genuinely solves one chosen problem. What's missing are the "nice to have" features left for later; the core flow must work completely.
Is a fixed price or time-based billing better?
For work with a clear scope that isn't expected to change, a fixed price gives predictability. For work whose scope will become clear during use, phased or time-based work is more flexible. In many projects, the first version is built with a fixed scope and later development proceeds in phases.
Can I know the maintenance cost in advance?
You can define the scope of maintenance (such as updates, backups, monitoring, bug fixes and monthly development hours) in advance. New feature requests are assessed separately as they arise.
Conclusion
What determines the cost of custom software is not what you see on screen, but the rules, connections and responsibilities behind those screens. Writing down the scope, starting with an MVP and discussing post-delivery costs from the outset are the most reliable ways to keep your budget under control. If you'd like to clarify your needs together, take a look at our Software and Digital Solutions page or get in touch with us.
Sources3
- Agile Alliance — Minimum Viable Product (MVP), glossary. — accessed: 2026-10 agilealliance.org
- Martin Fowler — Technical Debt. — accessed: 2026-10 martinfowler.com
- MDN Web Docs — Introduction to the server side. — accessed: 2026-10 developer.mozilla.org
