If you’re asking “What will this cost us, and why are the quotes so far apart?”, the second half matters as much as the first. Quotes for “the same” project differ because each vendor assumed a different project. Once you know which assumptions drive the number, you can control most of them.
The short answer: custom software cost depends on things you can control
Custom software development cost follows effort, and effort follows decisions you make: what goes into the first release, who has to use it, what it connects to and how it’s looked after. The same drivers apply whether you’re pricing a custom web application, a customer portal or an internal tool. Here’s the quick version of what affects software development cost, and which way each driver pushes it.
Scope: count workflows and screens, not features
A feature list like “user management, dashboard, reporting, notifications” is a poor basis for an estimate, because each item can mean two screens or twenty. Engineers estimate from workflows: a job a person does from start to finish, such as “a customer reorders from a past order.” Each workflow breaks down into screens, the rules behind them and the exceptions.
What to count before you ask for a quote
- Workflows. Each start-to-finish job, written as “who does what.”
- Screens per workflow. Forms, lists, detail pages and confirmation steps.
- Rules and exceptions. Approvals, limits, “unless the account is on hold,” and what happens when information is missing. This is where a lot of the effort hides.
- Reports and exports. Only the ones someone actually reads, and who reads them.
- Notifications. Every email or text the system sends, and what triggers it.
Example (hypothetical): a distributor’s customer reorder portal
Not client data. A regional industrial-supply distributor takes orders by email. Inside sales re-types each one into the order system, and customers phone to ask where their orders are. The wish list says “customer portal.” Counted as workflows, it looks like this:
Phase one is four workflows and 12 screens, and it removes the re-typing and the status calls. The catalog and reports wait until customers are using the portal. Deciding what has to work on day one, and what can follow, is the biggest lever you have on cost.
Phasing in practice
We’re modernizing Amusement Advantage’s existing contractor portal page by page, each page tested on a staging copy before production, instead of holding everything for one big launch. Read the Amusement Advantage case study.
Users, roles and devices
Every distinct type of user adds work. Each role needs its own permissions, often its own screens, and its own test cases: someone has to check that one customer can’t see another’s invoices and a sales rep can’t approve their own order. Three roles is a different project from eight.
Devices matter just as much. “Our contractors need to do this from their phones” changes the design of every screen: bigger touch targets, shorter forms, camera uploads and testing on the phones people actually carry. Planning for phones from the start avoids redesigning screens later. If you already have a desktop-only system, a mobile-friendly retrofit can be an alternative to a rebuild.
Responsive web app, native app or both
If native apps are on the table, budget for the store accounts too: Apple’s Developer Program is 99 USD per membership year, and a Google Play developer account carries a one-time US$25 registration fee. Our guide to mobile web apps vs native apps for field teams walks through the trade-off.
Other user requirements that add scope
- Poor signal or offline use on a plant floor, in a basement or on a remote site. Saving work on the device and syncing it later is real engineering work.
- More than one language for screens, emails and error messages.
- Accessibility for customer- or public-facing portals. If you need to meet the W3C’s Web Content Accessibility Guidelines (WCAG) 2.2, say so up front; it affects the design and testing of every screen.
- Audit trails that record who changed what, and when.
Integrations and existing data
Connections to the systems you already run can be the least predictable part of an estimate, because the effort depends on what’s on the other side. Before anyone quotes, list every system the new software must read from or write to, and how data gets in or out of it today.
Data migration and reporting
Moving existing data is a job in its own right: finding every source, mapping old fields to new ones, cleaning duplicates and deciding what to do with records that don’t fit. One tidy table is quick. Five spreadsheets that disagree about customer names are not.
If people already work from dashboards, say which tool. Storing data so that tool can read it, such as SQL Server tables that Tableau reports on, is part of the design, not an afterthought. Our guide to eliminating double data entry shows how to scope these connections, and our API and database integration page explains how we build them.
Building new vs improving or taking over what you have
You don’t always need a new system. If the current one still matches how you work but is hard to use, slow to change or unusable on a phone, improving it in stages usually means a smaller first project and less disruption than replacing it. If the business rules have changed underneath it, or nobody can change the code safely, rebuilding some or all of it may be the better spend.
Any price for finishing someone else’s code that comes before anyone has read the code is a guess. Our legacy modernization and software project rescue pages explain how we approach each situation.
Not sure what your first phase should be?
Your first call is with an engineer, who can talk through your workflows and systems with you and suggest what a sensible first piece of work looks like.
The costs after launch: hosting, maintenance, support, change
Software your operations depend on keeps costing money for as long as you use it. Budget for four things:
- Hosting. Servers or cloud services, databases, backups, file storage and email or text sending. Cloud bills grow with usage; AWS publishes a pricing calculator for modeling them.
- Maintenance. Security patches, framework and library updates, certificate renewals, and keeping up as browsers, phone operating systems and the systems you connect to change.
- Support. Answering user questions, fixing bugs and responding when something breaks in the middle of a shift.
- Change. Your process will change: new products, new rules, a new customer requirement. Each change is a small project of its own.
A low build price with no plan for maintenance isn’t a low cost. Our web application maintenance checklist lists what needs regular attention.
At Effortless Presence, the same crew that builds the software hosts and maintains it, so changes come from engineers who already know your system. See maintenance and support.
Pricing models and how they shift risk
The pricing model doesn’t change how much work there is. It changes who carries the risk when the work turns out bigger than expected, and that shows up in the price you’re quoted.
No model is cheaper by default. A fixed price on a vague scope either carries a large contingency or grows through change orders. Time and materials can cost less on a well-run project, but only if you can see where the time goes. Our guide to fixed price vs time and materials covers the contract clauses that protect you under each model.
How to get software development quotes you can compare
Every vendor fills the gaps in your request with its own assumptions. Close the gaps: send the same written brief to every vendor and ask each to answer in the same structure.
What to put in the brief
- The problem in your own words: “Our existing system is difficult to use,” or “We need software that follows our specific process.”
- Who uses it, roughly how many people, and on which devices.
- The workflows, each marked must-have, should-have or can-wait.
- Every system it must connect to, and what existing data has to move.
- Constraints: security reviews, where it must be hosted, your own target date and, if you’re willing, a budget range.
- What you expect after launch: hosting, maintenance, support and who handles changes.
Our software RFP template and project brief generator walks you through each of these and produces a brief you can send to any vendor, including us. Nothing you type is sent anywhere unless you choose to send it to us.
What to ask every vendor to spell out
Compare the answers line by line, not just the totals; our guide to choosing a software development company has more questions worth asking. Still deciding whether to build at all? Start with custom software vs off-the-shelf or the build vs buy calculator.
Our custom business software page explains how we build around the way your company works, and the guides library has more plain-language help for operations and IT leaders.