What Determines Custom Software Development Cost?

Why does every project come back with a different figure?

With custom software you are not buying a package; you are having your own process turned into a system. Two companies in the same line of business will still differ in approval steps, document types, exceptions and the other systems they run. Those differences land directly in the development scope.

So "how much does a mobile app cost?" has no single answer. Ask it as "how many screens, which user roles, integrated with which system, does it need to work offline?" and the answer starts to take shape.

The headings below are the work items behind a quotation. When each of them is priced separately, quotations from different firms become genuinely comparable.

Scope: how many processes, screens and exceptions?

Scope is the single largest driver. A purchase request system can be nothing more than raising a request and one level of approval, or it can include budget control, multi-level approval, supplier comparison and pushing the order into the ERP. Both go by the same name; the work involved is nowhere near the same.

Exceptions are part of scope too, and they usually surface late. Rules such as "above a certain amount the general manager also approves", "urgent requests are approved afterwards" or "if an item can be met from stock it never reaches purchasing" do not add screens, they add logic.

• Which processes are in the first release and which are deferred?
• How many different document or record types will be created?
• How many decision points and exception rules does the process have?
• Which screens only display data and which capture it?

Users and role structure

Role count matters more than user count. An application five hundred people use through the same screen can be simpler than one ten people use across six different roles. Every role means its own screen, its own permission rules and its own test scenario.

If users from outside the company are involved (dealers, customers, suppliers), the scope moves up a level: an application exposed to the outside has different authentication, data separation and security requirements than an internal one.

Web, mobile, or both?

If a process runs only in the browser, development stays on one platform. If the same process also has to run in the field on a phone, the mobile side brings its own design, its own testing and its own distribution work.

In some projects a mobile-friendly web application covers the requirement. Where the camera, barcode scanning, location or offline working are needed, a mobile application is the right answer. That distinction is one of the questions that decides scope, and with it the budget.

Integration: how many systems, in which direction?

Every integration is a separate work item. What drives the cost is less the number of integrations than the direction the data flows and what the other system offers. Reading data one way is not the same job as a two-way document flow that can be rolled back when something fails.

Where the other system has an official interface, the work is predictable. Where there is none, or it is limited, the route to the data has to be designed separately and that adds effort. On the SAP Business One side we work through the service interfaces shipped with the product, which makes the scope of an integration definable from the start.

• Which systems are involved: ERP, CRM, e-commerce, banking, shipping, production machinery?
• Does data flow one way or both ways?
• Is the transfer immediate or on a schedule?
• Does the other system expose an official API?
• Where do failed records collect, and who acts on them?

Data migration and existing records

A new application does not open on an empty screen. Business partners, items, users and often historical transactions come across. The duration of this item depends far more on data quality than on volume: where the same customer is recorded under three different spellings, the real work is cleaning rather than transferring.

How much history to bring is a decision in itself. In some projects only open records are migrated and the rest stays in the archive. Taken early, that decision reduces the scope.

Offline working and device capabilities

In field applications the most commonly overlooked item is offline working. If data has to be captured where there is no connection, the application must hold it on the device, send it once connectivity returns and prevent the same record being created twice. That does not change the screen count, but it noticeably enlarges the logic behind them.

Barcode or QR scanning, camera, signature capture, location and printing are each assessed separately. All of them need development and testing on real devices.

Reporting and management screens

Who will see the data the application produces, and at what level of detail, should be agreed at the start. A handful of list screens and a role-filtered, exportable dashboard with charts are jobs of different sizes.

A practical approach is to deliver the lists the operation needs in the first release, then build the dashboard once real data has accumulated, around the indicators people actually look at.

Security, testing and go-live

Authentication, permission separation, input validation and an audit trail are not features added later; they are part of the design and they carry a cost. In applications exposed to the outside, this heading weighs more.

On the testing side, the checks made during development are joined by an acceptance test in which users run their own work through the system. Go-live then means training, first use with real data and close support in the opening period. When the schedule leaves no room for these steps, problems surface in live operation instead, where they cost more to fix.

Maintenance and further development

The project does not end at go-live. Operating system and browser updates, version changes in the systems you integrate with, regulatory changes and new requests from users all generate work over time.

So the budget should be planned not around the first delivery alone but around the period the application will stay in use. How maintenance is defined — who responds, within what time, covering what — belongs in the quotation in writing.

How to prepare your scope before asking for quotations

Put the following in writing and quotations from different firms become comparable. The same list also reduces scope disputes later in the project.

• Which process, through which steps, is moving into software?
• How many users, how many roles, with what permissions?
• Which screens are web and which are mobile?
• Which integrations are mandatory and which can wait?
• Which existing data is migrated and which stays in the archive?
• Which reports are required in the first release?
• Are offline working, barcode scanning, camera or signature capture needed?
• How will post-go-live support and maintenance be defined?
• Who holds the source code, the documentation and the hosting environment?

Conclusion

The cost of custom software is the sum of scope, role structure, integration count, data condition and go-live discipline. A figure given before those are clear is a guess; a figure given afterwards is a plan both sides can agree on.

If you would like to work out your scope together, and decide which requirements are met by configuring what you already have and which genuinely need development, get in touch.

Frequently asked questions