What does a custom web application cost in Cambodia?

The most common first message I get is some version of "how much for a system that does X?" It is a fair question and an unanswerable one, for the same reason a builder cannot price a house from the word "house".

What I can do is explain what the number is made of. Almost all of the cost of a custom web application comes from four things, and none of them is the programming language.

1. How many kinds of user does it have?

This is the single biggest cost driver, and the one clients most often underestimate.

A system with one type of user is one set of screens. A system with three — say a staff member who enters data, a manager who approves it, and a director who reads reports — is not three times the work, but it is considerably more than one times. Each role needs its own screens, its own permission rules, and its own testing. Worse, the roles interact: what happens when a manager edits something a staff member already submitted? Every pair of roles adds a question that has to be answered and built.

When someone describes a project and mentions "and then the supervisor checks it", that sentence usually costs more than the entire feature it was attached to.

2. How many workflows is it replacing?

A workflow is a complete path through the system — a sale, an audit, a booking, an order. Each one has a beginning, a set of states, and an end.

Clients often describe a project as a list of features: "we need inventory, and reports, and notifications, and a customer list." But features are cheap; workflows are expensive. Inventory that only goes up when stock arrives and down when it sells is one workflow. Inventory that also handles returns, damages, transfers between locations, and supplier credit notes is five — and the fifth one always turns out to have an exception nobody mentioned.

The honest way to estimate a project is to count the paths, not the screens.

3. Does it have to talk to something else?

Integration cost is almost entirely outside the developer's control, which makes it the riskiest part of any quote.

Connecting to a well-documented modern API — a payment provider, a messaging service like Telegram — is predictable work. Connecting to an accounting package with no API, or a supplier's system that exports a fixed-width text file every night, is not. The work is not harder in principle; it is that you discover what you are dealing with only after you start, and the other system will change without warning at some point.

If your project involves an integration, expect the quote for that portion to be less firm than the rest, and be suspicious of anyone who prices it confidently without having seen the other system.

4. What has to happen to your existing data?

Every business that needs custom software already has years of data somewhere — spreadsheets, an old system, a set of paper files. Nobody wants to start from zero.

Migration cost depends almost entirely on how consistent that data is, and real data is never consistent. The same customer appears under three spellings. A column that should contain dates contains dates, empty cells, and the word "pending". Someone used a cell for a note in 2019 and it has been there since.

Cleaning this up is unglamorous work that no one budgets for and every project needs. On some builds it is the largest single line item.

What about hourly rates?

Rates in Cambodia vary widely — a student doing their first freelance project, an experienced local developer, and an international agency with a Phnom Penh office are three genuinely different markets, and they can differ by an order of magnitude.

But comparing rates is mostly a distraction. A developer charging half as much who takes three times as long, needs the work redone, or disappears after delivery is not cheaper. The number that matters is the total cost of getting a working system you still own in two years, and that is not visible in an hourly rate.

A more useful question to ask anyone quoting you: what happens if you are unavailable six months from now? If the answer does not include documentation, a repository you own, and a deployment someone else could run, the quote is incomplete regardless of the number.

Five ways to make your project cost less

Most of the savings available on a custom build are decided by you, before a developer is involved.

Cut version one down to one workflow

Pick the single process that hurts most and build only that. You will learn more from three weeks of real use than from three months of planning, and the second version will be better specified because it will be based on evidence instead of guesses.

Postpone the second user role

If managers currently approve things verbally, let them keep doing that in version one and record the outcome. Adding a proper approval flow later, once you know how approvals actually behave, is cheaper than building the wrong one now.

Clean your data before you hand it over

An afternoon spent making your spreadsheet consistent — one date format, one spelling per customer, no notes in number columns — removes work that you would otherwise pay developer rates for.

Choose one person to make decisions

Projects slow down when "we need to check with the team" appears between every question and its answer. One person with authority to decide is worth more to a budget than any technical optimisation.

Check whether a product already does it

If an off-the-shelf tool covers 90% of your needs, adapting your process to it is almost always cheaper than building. Custom software earns its cost when the remaining 10% is the part that makes you money — and you should be able to say clearly what that 10% is.

So what should you actually do?

Write down the process that is causing trouble, in the order it happens, including the workarounds. Note who touches it and what each of them is allowed to decide. That document — a page is plenty — is enough for any competent developer to tell you whether your project is small, medium, or large, and roughly what it will cost.

It also does something more valuable. About a third of the time, writing it down reveals that the problem is a process problem rather than a software problem, and you have saved yourself the entire budget.

Related reading

• What I build — the services and what a typical project includes.
• Hiring a web developer in Cambodia — how working together locally or remotely actually runs.
• POS Flask case study — a worked example of a single-workflow system.