Buying Software
Ask three studios what a system will cost and you will usually get three numbers and no way to compare them. The numbers are not dishonest. They are answers to three different questions, because nobody agreed on what was being priced.
We publish our package prices — Launch Site at S$2,800, Automation Sprint at S$4,800, App MVP at S$8,800, and a Custom Build scoped before it is priced — which helps with the starting point and not much else. A published price describes a shape of work, not your project. What follows is what actually moves the number, in the order it usually moves it.
Feature lists are a poor predictor of cost. Twelve screens that each do one obvious thing are cheaper than four screens full of exceptions.
What costs money is the branching — every except when, every case where the price is calculated differently for one client, every status that only applies on Fridays. Each of those is a decision someone has to specify, someone has to build, and someone has to test, and the testing is where the exceptions multiply against each other.
This is why our App MVP is written as one core flow, end to end. The word doing the pricing work there is "one", not "core". A build that covers one path completely is a different kind of project from one that covers four paths partially, even when the feature lists look similar.
The cheapest thing you can do before asking anyone for a price is to write down the exceptions yourself. They exist whether or not they are mentioned, and finding them mid-build is what turns a fixed price into a conversation about variations.
When a build has to talk to something you already use, the cost is set almost entirely by what that other system allows.
A tool with a documented API is straightforward work. A tool that can export a file on a schedule is workable, with more moving parts. A tool that holds your data behind a screen and offers no way out is either expensive to work around or genuinely impossible, and the honest answer is sometimes that the integration is not worth what it would cost.
Our Automation Sprint lists existing tool integrations at a fixed price because the sprint assumes the tools have a way in. That is not a hedge — it is where the price comes from.
So before you collect quotes, find out for each system whether it has an API, an export, or neither. That single answer will change your quotes more than any feature you add or remove.
Owners tend to assume the number of records is what matters. It is not. Moving many consistent rows is close to free; moving fewer inconsistent ones is not.
What costs is inconsistency: the same customer entered three ways, two date formats in one column, a notes field that has quietly become the place where important information lives, records that contradict each other and no rule for which one wins.
That last part is the real expense, and it is not really a software task. Somebody in the business has to decide what the true record is, case by case, and no developer can make those calls for you.
There is a cheaper option that is often the right one: start the new system clean, and keep the old one available read-only for history. It costs less, it removes the argument, and in most service businesses last year's half-correct records are not what the new system is for.
A system where everyone sees everything and anyone can do anything is the cheap version. Every step away from that is real work.
Different permissions for different roles, a quote that cannot go out until someone approves it, a record of who changed what and when — each of those is engineering, and more to the point, each is testing, because the interesting cases are the ones where the approver is unavailable, or changes their mind, or the thing gets edited after approval.
Worth choosing deliberately rather than by default. Oversight you will actually use is worth paying for; oversight added because it sounded prudent turns into a step people learn to route around. We have written before about what happens when everything waits on one person — building that bottleneck into software makes it permanent rather than fixing it.
Software is not finished when it is delivered. Dependencies age, platforms change their rules, browsers move, and the business itself changes in the first months of real use because people now see what they actually needed.
Two quotes can look the same and mean very different things here, so it is worth asking explicitly: what happens in the weeks after go-live, what counts as a fix versus a new request, and who is available when something breaks.
Our own packages state the boundary in writing — Automation Sprint includes revisions against agreed sample data and two rounds in the fortnight after go-live; App MVP includes weekly demos and two revision rounds per demo cycle. The point of publishing those is not that they are generous. It is that both sides can tell where the package ends before the work starts.
Narrow the flow. One complete path is cheaper than three partial ones, and it is also more useful, because a path nobody can finish helps nobody.
Keep the tools you already pay for. Integrating with working software is nearly always cheaper than replacing it, and your team already knows how to use it.
Buy the commodity parts. Accounting, payroll, email and storage are solved; a custom version costs more and does less.
Do the specification work yourself — the steps, the exceptions, the list of systems and whether each one can export. It is unpaid, it takes an afternoon, and it makes every quote you receive comparable.
And one case where the answer is to spend nothing: if the process is still changing every month, no price is trustworthy yet, including ours. A quote is a bet that the thing being described will still be the thing you want when it is built. Let the process settle, then scope it.
A Launch Site at S$2,800 is a site with a known shape and a known number of sections. An Automation Sprint at S$4,800 is one repeating workflow across tools you already have. An App MVP at S$8,800 is one core flow built end to end with tests on the critical paths. A Custom Build is scoped first and then delivered against fixed-price milestones, which is the only responsible way to price something whose shape is not known yet.
In every case you own the repository from day one, and anything past the agreed scope is quoted before it is built rather than billed after.
We publish the numbers because a price you can see is easier to argue with than one you have to request. If your project does not fit any of them — and plenty do not — the five things above are still what the quote will be made of, whoever writes it.
If a recurring administrative task is costing your business more time than it should, we offer a 20-minute workflow conversation — one task, and an honest answer about whether automation is appropriate. Get in touch.
More from the blog
Buying Software
We build custom software, and most businesses that ask us about it should buy something existing instead. Here is the line between the two, and the costs on both sides that get left out of the comparison.
Operations
Spreadsheets do not fail gradually — they fail in four recognisable ways. Knowing which one you have tells you whether you need a better spreadsheet or something else entirely.