What Actually Drives the Cost of Custom Software

·6 min read·Ervandra Halim

Key answer

Custom software cost is driven by decision logic, not screen count: user roles and permissions, approval workflow states, legacy-system integrations, exception handling, and data migration. In my experience leading technical delivery, two quotes for the same brief can differ by 5x because one vendor scoped only the happy path while the other actually asked about your approval chains and legacy integrations before pricing. Compare vendors on how specifically they describe your workflow, not on price alone.

  • Screen count tells vendors almost nothing about cost; the real cost driver is the decision logic underneath each screen, such as conditional tax rules, rounding logic, and balance checks.
  • The five cost drivers that most often blow up an estimate are user roles and permissions, approval workflow states, legacy-system integrations, exception handling, and data migration.
  • A quote that stays silent on your specific roles, exceptions, and integrations is a guess dressed up as a number, and the gap surfaces later as unbudgeted change requests.

Every founder who asks three vendors for a quote on "the same app" ends up with three wildly different numbers, and then assumes someone is lying. Nobody is lying. Custom software development cost almost never tracks with what the client thinks they are paying for, which is screens and features. It tracks with what the vendor actually has to build, which is decision logic, and those two things are only loosely related.

I have sat on both sides of this. As a vendor, I have quoted a project at 5x what a competitor quoted, for what looked on paper like an identical brief. As a client-facing technical lead, I have had to explain to a business owner why "just add an approval step" cost more than the entire original module. The gap is real, and it is explainable once you know where to look.

Why Are Screens the Least Expensive Part of the Build?

Screens are the least expensive part of custom software because a login page, a dashboard, or a form to add a product is commodity work: any competent team builds them fast, since the patterns are well understood and mostly reusable. If your RFP describes the product as a list of screens, you will get quotes that vary wildly, because screen count tells the vendor almost nothing about the actual engineering effort underneath.

What actually costs money is what happens when a screen has to make a decision. A "create invoice" screen is cheap. A "create invoice that changes tax treatment based on customer type, applies a different rounding rule for cash versus transfer, and blocks submission if the customer has an overdue balance" is the same screen, five times the cost.

The Real Cost Drivers

In order of how often they blow up an estimate:

  1. Number of user roles and permission combinations. Two roles (admin, staff) is simple. Six roles with overlapping permissions and role-based visibility on every screen multiplies testing and edge-case handling, not just the permission table.
  2. Approval chains and workflow states. A single-step approval is one status field. A three-step chain with conditional routing (skip step two if amount is under a threshold, escalate if step three is delayed 48 hours) is a state machine that needs its own design pass.
  3. Integrations to legacy systems. This is usually the biggest single line item vendors underquote, because nobody knows the legacy system's real behavior until they are inside it. An accounting system integration that's "just an API" can turn into weeks of handling undocumented field quirks, rate limits, and silent failures.
  4. Exception handling. What happens when the internet drops mid-transaction. What happens when two staff edit the same record at once. What happens when a customer's data does not fit the model you designed. Systems that only handle the happy path are cheap to build and expensive to run.
  5. Data migration from whatever exists now. Spreadsheets with inconsistent formatting, a legacy database with no documentation, years of manual workarounds baked into "how staff actually enter data." Migrating that mess is often harder than building the new system.

None of these show up when you count screens. All of them show up in the invoice.

Why Do Two Quotes for the Same Brief Differ by 5x?

Two quotes for the same brief typically differ by 5x because the cheaper one scoped only the happy path, assumed integrations would be simple, and did not ask enough questions to uncover the real workflow complexity hiding underneath the brief. This is not always dishonesty; sometimes it is inexperience. Either way, you find out the truth mid-project, when the change requests start, which is the worst time to find out.

More expensive quotes are sometimes padding, but often they reflect a vendor who actually asked about your approval chains, your exception cases, and your legacy systems before pricing. That conversation is worth having before you sign, not after.

If your business has already outgrown ad hoc spreadsheets and manual workarounds, the jump to custom software is usually not about the interface, it's about encoding the workflow correctly. Related read: Seven Signs Your Business Has Outgrown Spreadsheets.

Questions That Expose the Real Difference

Before comparing quotes on price alone, ask each vendor:

  • How many user roles did you assume, and what permissions differ between them?
  • Which of my current systems does this need to talk to, and have you seen their API documentation?
  • What happens in your design when [specific edge case in your business] occurs?
  • Is data migration from my current system included, or is that a separate line item?
  • What's your assumption about approval workflow, in plain language, not features?

A vendor who answers these specifically has actually scoped your business. A vendor who answers generically has scoped a generic app that happens to resemble yours.

A Concrete Example

A multifinance company I worked with requested a "simple" internal tool to track vehicle repossession cases. The first quote treated it as a CRUD app: create case, assign field agent, mark closed. Rp180 million, four weeks.

The actual requirement, once we dug in: 15 different user roles across branches, a four-stage workflow with conditional escalation depending on debtor response, an integration to the core financing system that had no API documentation and required reverse-engineering a legacy database, and audit trail requirements for every status change because of regulatory compliance. Real cost: closer to Rp850 million, and worth every rupiah because getting the workflow wrong would have meant reprocessing cases manually anyway.

The screens looked almost the same in both scopes. The decision logic underneath did not.

How Should You Actually Compare Quotes?

Quotes should be compared by whether the vendor can describe your actual workflow, roles, exceptions, and integrations back to you in specific terms, not by screen count or feature list, since only the former predicts what the build will really take. A quote that is silent on those things is a guess dressed up as a number, and the real cost will surface later as change requests you did not budget for. If you want a second opinion on a quote before you sign, that's a five-minute conversation worth having: reach out through /partner.

custom software costpricingestimationscopeprocurement

Frequently asked questions

Why did a repossession tracking tool that looked like a simple CRUD app end up costing nearly 5x the first quote?

The tracker's cost went from Rp180 million to nearly Rp850 million because the real requirement included 15 user roles across branches, a four-stage escalation workflow, an undocumented legacy integration requiring reverse engineering, and audit trail requirements for regulatory compliance, none of which show up when you only count screens like create case or assign agent.

Does a low quote mean the vendor is being dishonest?

Not usually. Cheaper quotes are typically cheaper because the vendor scoped only the happy path, assumed integrations would be simple, and did not ask enough questions to uncover the real workflow complexity, which is inexperience more often than dishonesty. The gap surfaces mid-project, once change requests start, which is the worst time to find out.

Why can 'just add an approval step' cost more than the entire original module?

Because a single-step approval is only one status field, but a three-step chain with conditional routing, such as skipping a step under a threshold or escalating after a 48-hour delay, becomes a state machine that needs its own design pass rather than a quick field addition, which is why it often outprices the module it was added to.

Should data migration be part of the core quote or a separate line item?

It should be scoped explicitly rather than assumed. Migrating spreadsheets with inconsistent formatting, an undocumented legacy database, and years of manual workarounds baked into how staff actually enter data is often harder than building the new system, so a quote that treats migration as an afterthought is likely underscoped.

Ervandra Halim

Ervandra Halim

CPTO & Principal Architect

Ervandra Halim helps owners and leaders modernize operations and put AI to work daily. He partners with a few businesses at a time, mostly by referral.

Keep reading

© 2011–2026 Ervandra Halim