Buying custom software as a Singapore SME

When custom software is the right call

Most of the time, it is not. If an off-the-shelf product covers eighty per cent of what you need and the remaining twenty per cent is preference rather than constraint, buying the product and adapting the process is almost always cheaper over three years than building and maintaining your own.

Custom software earns its keep in three situations:

• The workflow is the business. If how you quote, dispatch, schedule or reconcile is a genuine differentiator, generic software flattens the thing that makes you competitive.
• The integration is the problem. When the work is mostly moving data between systems that will not talk to each other, the value is in the connective tissue, and that is rarely something you can buy.
• The manual cost is compounding. When several people spend hours a week on the same repetitive handling, the annual cost of that time is often larger than the cost of removing it.

If you are not sure which side of the line you sit on, that is a scoping question rather than a build question. A paid planning and scoping engagement is usually cheaper than discovering the answer three weeks into a build.

What actually drives the cost

Quotes vary far more than buyers expect, and the spread usually comes from four things rather than from hourly rates.

The number of user roles

One user type doing one job is a fraction of the work of three user types with different permissions, views and edge cases. Each additional role multiplies the states that have to be designed, built and tested.

Integrations and who controls them

Connecting to a system with a documented API and an owner who answers email is routine. Connecting to one where nobody knows who holds the credentials is where timelines go. Ask who owns each system before you ask what it costs.

How production-ready it has to be on day one

An internal tool used by five colleagues who can tolerate a bug is a different engagement from a customer-facing system that takes payments. Both are legitimate; they are not the same price.

Data sensitivity

Personal, financial or regulated data raises the bar for access control, audit trails and review. That work is real and should be priced rather than assumed.

For reference, published starting ranges at this studio run from S$750–S$1,500 for planning & scoping, through S$8,000–S$18,000 for a bounded first release, to S$15,000–S$40,000 for a workflow automation pilot. Where a specific engagement sits inside a range depends on the four factors above, and the final figure is always confirmed in writing before work starts.

Fixed scope or time and materials

Fixed-scope engagements put the risk of estimating on the vendor. Time and materials puts it on you. Neither is inherently better, but they suit different situations.

Fixed scope works when the outcome can be described precisely enough to write acceptance criteria for it. The trade-off is that changing your mind mid-build has a defined cost, because the price was set against a specific definition of done.

Time and materials works when discovery is genuinely part of the work and the destination will move. The trade-off is that you carry the overrun risk, so it needs a budget ceiling and a real review cadence, not just good intentions.

A common middle path is to buy the definition first — a paid scoping engagement that produces an architecture, user flows and written acceptance criteria — and then buy the build at a fixed price against that document.

How to write a brief that gets a useful answer

A vague brief gets a vague quote, usually a high one, because the vendor is pricing their uncertainty. Four things make the difference:

• Describe the current process, not the solution. “Three staff re-key orders from email into two systems, and we find the mistakes at month end” is more useful than “we need a dashboard”.
• Name the one workflow that matters most. If everything is priority one, the estimate covers everything and the number frightens you off a project that would have paid for itself.
• Say what success looks like. Not a feature list — the observable change. Fewer errors, faster turnaround, a report nobody has to assemble by hand.
• Give the real deadline and what it is tied to. A date attached to a trade show, a lease or a funding milestone is planning information. A date with nothing behind it just compresses quality.

What to agree before anyone writes code

These are the terms that decide whether a project ends cleanly, and they are much easier to settle before the work than during it.

Written acceptance criteria

What has to be true for the work to be finished. Without this, “done” is a matter of opinion and the last ten per cent takes as long as the first ninety.

Code ownership, in writing

Who owns the project-specific code after payment, and what is carved out. Pre-existing tools, open-source components and hosted platforms keep their own licence terms — that is normal, but the exceptions should be named in the agreement rather than discovered later.

What handover includes

Repository access, credentials, deployment, documentation and training. If you cannot hand the system to a different engineer and have them work on it, you have bought a dependency rather than an asset.

Third-party costs

Hosting, domains, email, payment processing, data providers and model usage are usually billed by those providers, not included in a build price. Ask which services the design assumes and who pays for them.

What happens after launch

What the warranty covers and for how long, and whether ongoing support and maintenance is a defined service with a written capacity or an open-ended retainer.

Data and AI considerations

Singapore’s Personal Data Protection Act governs how organisations collect, use and disclose personal data, and it applies to your business whether or not your vendor raises it. If the system will hold customer records, ask early who can see what, how long data is kept and where it is stored.

Where AI is part of the build, three questions matter more than which model is used:

• What data goes to the model, and has anyone confirmed it is appropriate to send? Sensitive, regulated or confidential information should not reach an external service without an agreed basis and safeguards.
• Where does a human approve? Anything with a consequence — money moving, a customer being told something, a record being changed — should have a named reviewer rather than running unattended.
• How will you know it is still working? Automation without evaluation or monitoring degrades quietly. Acceptance tests you can re-run are worth more than a demo that went well.

Be wary of guaranteed accuracy claims. A responsible vendor will describe an evaluation approach and the conditions under which the system should not be trusted.

Government support schemes

Singapore operates support schemes that some SMEs use toward technology projects. The two most often mentioned in a software context are the Productivity Solutions Grant (PSG), which supports adoption of pre-approved solutions, and the Enterprise Development Grant (EDG), which supports broader capability and business transformation projects.

Practically: plan the project on the basis that you are paying for it. If support is confirmed later, that is upside. Projects structured around an assumed grant tend to stall when the assumption does not hold.

Questions worth asking any vendor

Including this one. The answers tell you more than a portfolio does.

• Who exactly will do the work, and will I speak to them?
• What is explicitly excluded from this price?
• What happens if it takes longer than you estimated — who absorbs that?
• What do I receive at handover, and can another team pick it up?
• What would make you tell me not to build this?
• Which third-party services will this depend on, and what do they cost me monthly?

A vendor who answers the last two directly is usually a safer bet than one who agrees with everything you say.