“How much for custom software?” is the question I probably get asked most often, and it’s also the one I most often have to answer with more questions before I can give a real number. Here’s the honest breakdown of what custom software actually costs right now, based on real projects we’ve scoped and built, not marketing ranges pulled from an industry report.
Small utility tools and internal apps: $10,000-$30,000
Think a single-purpose internal tool — an inventory tracker, a simple multi-step approval workflow, a basic reporting dashboard pulling from one data source. Limited screens, one or two user roles, no heavy third-party integrations. This is the realistic entry point for “custom,” and it’s often cheaper than businesses expect once they compare it against the ongoing labor cost of the manual process it’s replacing. I’ve had clients hesitate at a $15,000 quote for a tool that was quietly costing them more than that every year in staff hours spent on spreadsheets and manual re-entry.
Mid-complexity business applications: $40,000-$100,000
This is where most real business software actually lands — multiple user roles with different permission levels, a proper relational database backing it, a handful of third-party integrations such as payment processing, a CRM sync, or automated email notifications, and enough distinct screens that the UX needs genuine design attention rather than just functional layout. A scheduling platform, a client portal, or an order management system typically falls in this range, and the spread within it usually comes down to how many integrations and how customized the permission logic needs to be.
Complex, business-critical platforms: $120,000 and up
Multi-sided platforms connecting different types of users, heavy real-time functionality, complex business logic with many edge cases, and integrations with several external systems that all need to stay in sync — this tier requires a real engineering team, proper QA processes, and ongoing architectural decisions, not just straightforward feature building on top of a template. Projects here also tend to need a dedicated technical lead making architecture calls throughout, not just at the start.
What actually drives the number up
Integrations are almost always underestimated by clients going in. Connecting to a third-party system sounds simple until you’re handling their rate limits, their inconsistent error responses, and the edge cases their documentation conveniently doesn’t mention. Custom UI design, rather than using existing component libraries, also adds real time. So does anything involving file uploads, payments, or user-generated content, because those require dedicated security and validation work that a simple contact form never needs. Even something as ordinary-sounding as “export this data to a spreadsheet” can balloon in scope once you factor in large datasets, formatting edge cases, and users who need scheduled automated exports rather than a manual button click.
Where the estimate gets padded, and how to tell
A vague, single-number quote handed to you in the first meeting, before any real discussion of your workflow, is either a guess or padded heavily to cover the agency’s own uncertainty. A properly scoped quote takes real time to produce, because it requires understanding your actual data model and user roles first, not just your general idea of what the software should do.
What you can actually do to control cost
Phase the build. Launch with the core workflow that solves your actual bottleneck first, and add secondary features only after you’ve watched how real users interact with version one. I’ve seen plenty of “must-have” features listed in an initial spec turn out to be unnecessary once the core tool was in daily use for a few weeks — cutting them before ever building them is the cheapest optimization available, and it’s far easier to add a feature later than to have paid for one nobody ended up using.
Get a detailed, itemized quote, not a single number
If a vendor can’t break down what’s driving their estimate — how much is backend logic, how much is UI, how much is a specific integration — they probably haven’t scoped the project carefully enough to hit that number reliably, and you should expect change orders later that erase any initial savings you thought you were getting.
Maintenance is a real ongoing cost, not a launch-day afterthought
Whatever you spend building the software, budget roughly 15-20% of that annually for maintenance — security patches, dependency updates, and small fixes that inevitably surface once real users start using the tool in ways you didn’t fully anticipate during design. Skipping this budget line is one of the most common reasons a “finished” custom tool quietly degrades within a year or two.
The bottom line
If someone quotes you a number in the first conversation before understanding your workflow, your integrations, and your user roles, that number is a guess dressed up as an estimate. A real quote comes after a genuine scoping conversation, and it should come with a breakdown detailed enough that you can actually evaluate whether it’s reasonable before you commit budget to it.