Insights
Operations

What custom software actually costs in the Philippines

Every quote you will receive is built from an hourly rate. That is the least useful number in the conversation, and here is what to ask for instead.

Ask what custom software costs in the Philippines and you will get an hourly rate. Somewhere between twenty five and seventy five US dollars, depending on who you ask and how senior they say the developer is. The number is real. It is also close to useless for deciding whether to proceed.

An hourly rate tells you what an hour costs. It tells you nothing about how many hours the thing you want will take, and that second number is where every budget actually goes wrong.

Why the rate is the wrong question

A rate prices labour. Your problem is not a shortage of labour. Your problem is that approvals are scattered across three chat threads, the stock figure disagrees with the invoice, and one person is holding the whole operation together inside a spreadsheet nobody else fully understands.

Buying hours against that does not fix it. It converts an operational problem into a software project, hands the software project to people who have not studied the operation, and bills you by the hour while they learn it. The learning is real work and somebody has to pay for it. The question is whether you pay for it as a defined study up front, or as unexplained overruns later.

There is a second problem with rate-first quoting. If you are billed by the hour, then hours are the product. Nobody in that arrangement is paid to tell you the honest answer, which is sometimes that your process needs changing and no software is required at all.

What actually moves the number

Five things drive the cost of an internal system far more than the day rate does.

How many places the truth currently lives. A system that replaces one spreadsheet is a small build. A system that has to reconcile a spreadsheet, a chat thread, a supplier portal and a bookkeeper's file is a large one, because most of the work is not writing screens. It is deciding which source wins when they disagree, and getting the people who own each source to agree to that.

How many exceptions the process really has. Every operation has a documented process and a real one. The real one is full of special cases: the client who is invoiced differently, the branch that books stock a day late, the approval that gets skipped when the manager is on leave. Exceptions are not edge cases. In an internal system they are most of the logic, and a build that discovers them late gets expensive fast.

What it has to connect to. A system that stands alone is cheap. A system that has to move data to and from accounting, a supplier, a POS, or a government filing is not, and the cost sits in whatever those systems will and will not let you do.

Local obligations. BIR filing formats, SSS, PhilHealth and Pag-IBIG contributions, official receipt and invoice requirements, LGU and DTI permit trails. None of this is exotic and all of it is specific. It is a well understood cost when it is scoped at the start, and a nasty one when it turns up after the build is supposedly finished.

Who is going to run it on Monday. A system that fits how people already work needs little training and gets used. A system that demands new habits from twelve people needs a rollout, and the rollout is part of the cost whether or not anybody put it in the quote.

A more useful way to size it

The honest sequence is to spend a small, fixed amount finding out what the build is, before committing to the build.

That is what a discovery study is for. It maps how the work moves today, counts what the current way of working costs, and produces a written account of both. At the end you hold something you can actually price against, and you own it regardless of who builds the thing or whether anybody builds it at all.

It also gives you a real option to stop. A study that concludes your problem is a process problem, not a software problem, has saved you the entire build budget. That outcome should be available, and with an hourly arrangement it quietly is not.

What to ask any provider

Four questions separate a scoped engagement from an open meter.

  1. What will you study before you quote the build, and what do I get in writing at the end of it?
  2. Which of my existing systems will this have to exchange data with, and have you checked what those systems permit?
  3. What happens to the price when we find an exception you did not know about? Not whether that will happen, but what happens when it does.
  4. Under what circumstances would you tell me not to build this?

The fourth one is the most useful. Anyone who cannot answer it is selling hours.

The short version

Rates are comparable across providers and tell you almost nothing. Scope is not comparable and tells you everything. Pay a defined amount to establish the scope, then decide, with the option of deciding no.

If you want to talk through where your operation actually gets stuck, that conversation takes about thirty minutes and does not require a deck.

If any of this describes your operation, the next step is a conversation, not a proposal. Thirty minutes, no deck.

Book a 30-minute call