Most software firms don't publish their prices because software is hard to price. A building has a floor area and a fixed set of materials. Software has no equivalent measure. Two projects described in the same sentence can differ in effort by a factor of three or four. "A system to track orders" might be a simple list with a status field, or it might involve approvals, pricing rules that differ by customer, and connections to two other systems. The two descriptions sound alike, but the work involved differs a lot. Until the scope is understood, any cost is little better than a guess, which is why many firms prefer not to publish one at all.
We think a range is still more useful than nothing, so here is ours. Custom software from Bitnatives usually falls into one of three categories:
- Small, S$8,000–20,000. A few processes, one team.
- Mid-size, S$20,000–80,000. Several teams, several modules.
- Large, from S$80,000. A company-wide platform or ERP.
These are our own range of prices, not an industry average. Another firm may price differently. The rest of this article explains what sits behind each range, what moves a price up, and what it costs after launch.
The three ranges
| Small | Mid-size | Large | |
|---|---|---|---|
| Typical price | S$8k–20k | S$20k–80k | From S$80k |
| What it replaces | One Excel or email process | Several connected processes across teams | Most of how a company runs its operations |
| Who uses it | One team | Several teams with different roles | The whole company |
| Typical scope | A few screens | Multiple modules, reporting, one or two connections to other systems | Many modules, data moved from old systems, phased rollout |
Small. Small projects typically replace a workflow that is dependent on one or a few Excel spreadsheets. Such workflows usually start breaking down when multiple people edit the same file, nobody knows which is the latest version, and managers can't track the status of things locked up in their colleagues' spreadsheets. A small build replaces these processes with a proper tool. Some applications are job tracking, approvals, or a client request log.
Mid-size. Here the problem crosses teams. Sales hands off to operations, operations hands off to finance, and each team has their own spreadsheets and processes. A mid-size system gives each team its own view, controls who can see and change what, adds reporting for management, and connects to one or two other systems, such as the accounting package.
Large. A company-wide platform or ERP. It's honestly hard to even provide a ballpark estimate because the range is too wide to quote without understanding the business. When a project is likely to span 6 months or more, we typically prepare a feasibility study to help clients understand what we can build and the constraints we will face, and to produce a much more accurate quote in the process.
What moves the price
The price range within a category can be wide due to many factors, but here are the 3 main ones to consider.
Connections to other systems. Each system the new software has to talk to is another system to understand, test and keep working. A connection to an accounting package with a well-documented interface can take days. A connection to an older system with no interface can take weeks. This is the widest variable in most quotes, and it's often the one buyers haven't thought about when asking for a price.
Moving data from old systems. Moving ten years of records out of Excel or an old database sounds like a technical chore. In practice, years of inconsistent entry have to be sorted out first: same entities with different spellings, fields used for something they were never meant for, records that exist in two places and disagree. On projects with a lot of history, this work is often a large part of the budget. It also pays off afterwards, because the business ends up with one clean set of records.
Extra features and scope changing during the project. Features vary in complexity. A new report may be a day of work, but a new approval step can touch every screen, every permission and every test. So an extra feature or a few can change the estimate by quite a bit. A project starts as "replace the order spreadsheet" and grows as the team sees what's possible. Some of that growth is good, and some of it is the pattern we wrote about in The Optimisation Trap in Software Implementation: a tool bent around how people think they should work, not how they do. Either way, it changes the price.
An illustrative example
A small distributor with a team of 3 salespersons tracks customer orders in an Excel file. The sales team updates it whenever a new order comes in, but each keeps a private copy to avoid overwriting the others. Orders get missed, and the distributor has no idea how many are late until a customer calls.
A tool that replaces the file is a small project. It has an order list, status updates, a view of what's late, and a login for each of the salespersons. That sits in the small range.
Now suppose the distributor also wants orders to flow into the accounting package, so invoices stop being typed in twice. That adds a connection to another system. Suppose they also want five years of old orders brought across so customer history is searchable. That adds data work. Each addition is reasonable, and together they move the project toward the mid-size range. Neither is a bad request. The point is that they change the price, and a buyer is better off hearing that at the start than finding out at the invoice.
How we price it
We price by phase, with a fixed price for each phase. Scope and price are agreed before a phase begins.
For the buyer, the main benefit is that the cost is known before the work is done. If a phase finishes and the business wants to pause, change direction or stop, it knows exactly what it has spent and what it has. A first phase is usually a small, focused piece of the problem, often 4–8 weeks, and it shows how the rest is likely to go before the business commits to it. It also keeps extra features manageable: a new request becomes a clearly priced addition to the next phase, not a surprise on the current one.
What it costs after launch
The price of the build is not the whole cost. Hosting, support, fixes and small changes continue after launch. We budget 15–20% of the original build cost per year for this.
On a S$40,000 system, that is roughly S$6,000–8,000 a year, which is S$500–670 a month. It covers keeping the software running, fixing things that break, and small changes as the business changes.
Ask any vendor for this figure before signing. Quotes that look cheap on build cost sometimes look very different once the yearly running cost is added, and it matters just as much when comparing custom software against a SaaS subscription. For that comparison, see SaaS vs Custom Software: Which Is Right for Your Operations?
When it isn't worth building
Custom software is not always the right answer. If an off-the-shelf tool already fits how the business works, buying it will cost less and take less time. Custom software earns its price when the process is unusual, when the business has been bending itself around a tool that doesn't fit, or when the work is spread across spreadsheets that nobody fully trusts.
If an existing tool fits about 80% of the process, it's worth asking what the remaining 20% costs in workarounds. Sometimes it's a few hours a month and not worth fixing. Sometimes it's a person's whole week.
What to ask any software firm
Whoever builds it, three questions make quotes easier to compare:
- Is the price fixed, and for what? A fixed price per phase is easier to plan around than an hourly rate with no ceiling.
- What does it cost to run after launch? Get a yearly figure, in writing.
- Who owns the code? The answer should be the business paying for it.
If it helps to talk through where a project would land in these ranges, a free 30-minute call is enough to place it and flag what is likely to move the number.