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.

Screens Are the Least Expensive Part

A login page, a dashboard, a form to add a product. These are commodity work. Any competent team builds them fast because 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 Two Quotes for the Same Brief Differ 5x

Cheaper quotes are usually cheaper because the vendor scoped only the happy path, assumed integrations would be simple, and did not ask enough questions to discover the real workflow complexity. This is not always dishonesty. Sometimes it's 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.

The Practical Takeaway

Stop comparing quotes by screen count or feature list. Compare them by whether the vendor can describe your actual workflow, roles, exceptions, and integrations back to you in specific terms. 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.