Every owner who has requested a quote for a custom system has had the same disorienting experience. You send the same one-page brief to three vendors and the numbers come back at 80 million, 210 million, and 400 million rupiah. Same brief, five-fold spread. It feels like someone is lying, and the natural instinct is to assume the cheapest one is honest and the rest are padding.
That instinct is usually wrong, and understanding custom software pricing is how you avoid the expensive mistake it leads to. The spread almost never comes from greed. It comes from each vendor quietly filling the gaps in your brief with different assumptions, and those assumptions are the entire cost.
Let me open the black box. I have sat on both sides of these quotes for years, and the mechanics are far less mysterious than they look.
What a manday actually buys
Most custom software pricing is built from mandays: one person working for one day. A vendor estimates how many mandays your project needs, multiplies by a daily rate, and that is roughly your number. Simple math, but three variables hide inside it.
- The rate. A senior engineer in Jakarta might be quoted at 1.5 to 3 million rupiah per manday. A junior might be 600 thousand. A quote built on junior rates looks cheaper on paper and costs more in rework.
- The roles. A real project is not just coding. It includes a business analyst, a designer, QA, a project manager, and often DevOps. A quote that only counts developer mandays is hiding the other roles, and those roles will either appear later as change requests or show up as bugs you pay to fix.
- The count. This is where estimates genuinely diverge, because it depends entirely on how the vendor interpreted your brief.
When you see a cheap quote, the honest question is not "why is this one so low." It is "which of these three variables did they shrink to get there." Cheap almost always means junior people, missing roles, or a smaller interpretation of your scope.
Why one brief produces five different numbers
Say your brief says "a system to manage our orders and inventory." Read that back slowly. It answers almost nothing a builder needs to know.
Each vendor now fills the blanks:
- Does "manage orders" include a customer-facing portal, or just an internal admin screen?
- Is inventory single-warehouse or multi-location with transfers?
- Do you need integration with your accounting software, or is manual export fine?
- How many user roles and permission levels?
- Web only, or mobile too?
Vendor A assumes the minimum on every question and quotes 80 million. Vendor B assumes the ambitious reading and quotes 400 million. Neither is wrong about the price. They are answering different questions, because your brief let them.
This is the single most important thing to understand: you are not comparing prices, you are comparing assumptions. The number is just the output of a scope you never fully specified.
How to compare proposals like an insider
Stop putting the totals side by side first. Instead, extract the scope each vendor assumed and compare those. Here is the practical method:
- Ask every vendor to list what is explicitly out of scope. The honest ones will have a clear list. Vagueness here is a warning sign, because everything unlisted becomes a paid change request later.
- Ask for the manday breakdown by role. If there is no BA, no QA, and no PM line, the quote is not cheaper, it is incomplete. You will pay for that quality gap in production.
- Normalize to the same scope. Pick the most complete proposal, then ask the cheaper vendors what it would cost to match it. Watch how fast the gap closes. That closing gap is your real answer.
- Ask who does the work. "We'll assign a team" is not an answer. Senior-led delivery and junior-led delivery are different products at different prices.
When you normalize scope, the terrifying five-fold spread usually shrinks to something like 1.5x, and that remaining difference reflects genuine quality and seniority. That is a difference worth paying for, or at least worth deciding on with open eyes.
The suspiciously cheap quote is deferred cost
I want to be blunt about the low bidder, because owners get burned here constantly. A quote that is dramatically below the others is not a discount. It is deferred cost, and you will pay it with interest.
It shows up as:
- Change requests. Everything the cheap vendor left out of scope comes back as a billable addition, often at a worse rate than if it had been quoted upfront.
- Rework. Junior teams ship faster and break more. The bugs surface after go-live, when fixing them is most disruptive to your business.
- Rebuild. The worst case. The system was built without the architecture to grow, and eighteen months later you are paying a second vendor to replace it. I have seen a distribution business in Tangerang do exactly this, and the rebuild cost more than the original honest quote would have.
Cheap software is the most expensive kind, because you pay for it twice. This is closely tied to why so many IT budgets fail: the initial number was never the real number.
The takeaway
Custom software pricing is not a mystery and it is rarely dishonest. The variation between quotes is the variation in assumptions each vendor made about the scope you left open. Your job as a buyer is to close that scope, then compare on equal ground.
Do three things. Tighten your brief until vendors are answering the same questions. Demand a role-by-role breakdown and an explicit out-of-scope list. And treat the suspiciously cheap quote as a bill you will pay later, not a saving you get today. If you are weighing whether to build this relationship as a one-off vendor engagement or something more durable, it is worth understanding the difference between a tech partner and an agency, or you can talk to me directly about a partnership. Get the scope right and the price stops being scary. It becomes a decision you can actually make.