You are paying for three subscriptions, a spreadsheet holds the real numbers, and someone on the team spends Friday afternoon copying figures from one screen to another. Do you buy a better product, build your own, or fix what you have? This guide gives a Thai SME a straightforward way to answer that question without a sales pitch in either direction.
Start with the short rule
Buy the boring parts. Build the parts that make you different. Connect the rest.
The first half of that sentence is not controversial. The second half is where most people go wrong, because "different" is easy to claim and hard to prove. The sections below give you tests you can apply to your own business.
When off-the-shelf wins
Off-the-shelf software wins when your need is the same as thousands of other businesses' needs. The product has been through years of edge cases that you would otherwise pay to discover.
- Accounting and bookkeeping. Packages like Xero and QuickBooks, or a Thai accounting product your accountant already uses, exist because the rules are shared. Rebuilding that is almost never worth it. If you need a tax or filing answer, ask your accountant, not a developer.
- Payroll. Same reasoning. The rules change, and a maintained product changes with them.
- Standard e-commerce. If you sell products at fixed prices with ordinary checkout, a mainstream shop platform or a marketplace like Shopee or Lazada is a good fit.
- Email, calendar, documents. Google Workspace or similar. Do not build these.
- Customer chat inbox. A standard shared inbox for your LINE Official Account may be all you need while volume is low.
If your need is on that list, the question is not "build or buy". It is "which product, and how do I connect it to the others".
When custom software earns its cost
Custom software is worth considering in three situations. Any one is enough to start a conversation. Two or three together make a strong case.
Your process is the differentiator
If how you quote, schedule or deliver is what customers pay you for, a generic tool will flatten it. A cleaning company with a pricing model built around condo size, building access rules and photo-proof reporting will fight a generic booking app every week. Software that encodes your way of working becomes part of the product itself.
The tool does not speak Thai properly
Some global products handle Thai poorly. Thai has no spaces between words, which breaks search and sorting in some tools; addresses use a structure of soi, tambon and amphoe that foreign forms do not expect; names and invoices often need Thai and English together; receipts and tax invoices in Thailand have their own conventions. If your staff keep a parallel spreadsheet because the product cannot cope, or customers get confusing messages, that is a real cost. Test any product with your actual Thai data before you commit.
You are paying people to re-type between systems
This is the clearest signal. A LINE message arrives, someone types it into a sheet, someone else messages the technician, a third person raises the invoice. Each hand-off takes minutes, introduces errors and scales with volume. If you add up the weekly hours, the cost is real, and it keeps growing as you do. We cover the first fix in our guide to LINE OA automation.
The honest middle: integrate what you already have
Most businesses that think they need a custom system actually need their existing tools to talk to each other. That is a smaller, cheaper and lower-risk project.
Examples from our own stack: stock figures kept in line between marketplaces and a stock sheet; payment slips matched to invoices; a booking in one tool appearing as a job on a board; a calendar entry created from a confirmed booking. None of these requires replacing the accounting package or the marketplace. They need a connection and a place to flag errors.
Our integrations service starts from ฿39,000, and typical projects take 2 to 3 weeks. If the project is larger, you are into the custom software range, and an internal tool starts from ฿180,000. The best way to decide between them is a scoping call, where we look at what you run today and say plainly whether integration is enough.
A decision table
| Situation | Likely answer | Why |
|---|---|---|
| Bookkeeping, payroll, tax filing | Buy | Shared rules, maintained by the vendor |
| Standard online shop with ordinary checkout | Buy | Mature products, low risk |
| Orders arrive on LINE and are re-typed into a sheet | Integrate or automate | The tools are fine; the copying is the cost |
| Stock on two marketplaces and your own shelf drifts apart | Integrate | One source of truth, synced |
| Your quoting or scheduling rules are your edge | Build | A generic tool flattens it |
| Product breaks on Thai names, addresses or invoices | Build, or buy a Thai-first product | Workarounds will grow |
| One-off idea, not yet proven | Start with a spreadsheet or a small automation | Prove demand before you build |
| You plan to sell the software to others | Build (a SaaS project) | The product is the business |
If you sit between two rows, take the cheaper and more reversible one first.
How to compare costs over three years
The day-one price is misleading in both directions. A subscription looks cheap and a build looks expensive, until you put both on the same timeline.
For off-the-shelf, add up:
- Subscription fees, including per-user pricing as the team grows.
- Add-ons and higher tiers you will need to get one missing feature.
- Staff time spent on workarounds each week.
- The cost of leaving: can you export your data in a usable form?
For custom, add up:
- The build, at the fixed price in the proposal.
- Hosting and other third-party costs, which are listed separately.
- Ongoing support, either your own developer or a care plan. Ours start from ฿4,900 a month and are optional.
- Changes you will want in year two.
Put both on a three-year line with your own numbers. We avoid giving a break-even figure here because it depends entirely on your team size and workload, and any universal number would be invented. The exercise is more convincing when you do it with your own staff hours. See what software costs in Bangkok for the price drivers behind the custom side.
A worked example: a small delivery business
Consider an illustrative business, not a client: a Bangkok florist taking orders on LINE and selling on a marketplace.
- Accounting. Buy. Use an established package.
- The online shop and marketplace listings. Buy. Standard platforms are fine.
- Order capture. Orders come as LINE messages with a delivery address, a card message and a time slot. Re-typing them onto a delivery sheet takes real time each day. Automate this step.
- Delivery routing by area. If the rules are simple, a spreadsheet and the automation are enough. If they involve drivers, traffic windows and building access rules, a small internal tool might earn its cost later.
- Stock. Fresh flowers are perishable, so stock changes daily. Sync marketplace stock with one sheet rather than building inventory software.
Result: two bought tools, one automation and perhaps one small internal tool later. No giant custom system. That pattern is common.
If you do build, build small first
The safest custom project is the smallest one that removes the pain. Pick one process, build it end to end, run it for a month and watch what staff actually do with it. Then decide whether to extend it. This is why a first project is often a single automated workflow rather than a platform, and why we scope in fixed, signed-off pieces.
Two habits keep a custom build healthy. First, keep your existing tools wherever they work, and connect to them rather than rebuilding them. Second, write down who owns the tool inside your business: someone who can explain what it does, request changes and notice when it stops. Software with no internal owner decays quietly, however well it was built. If you would like help after handover, an optional care plan covers hosting, monitoring and a block of build time, but a sensible build never depends on one.
Questions to ask before you build
- Can the problem be solved by connecting tools I already pay for?
- Is this process really different from how other businesses do it, or does it just feel that way?
- Who in my business will own this when the developer is not around?
- What will I do if the supplier disappears?
- Can I start with the smallest useful version?
If you can answer the last two clearly, you are in a good place to proceed.
Protect yourself either way
For off-the-shelf products, check that you can export your data and what happens to it if you cancel. For custom work, check ownership. At DigitalRova, source code, accounts, credentials and documentation are handed over at the end of every project, so another developer can maintain it. Whoever you work with, get that in writing.
If you are not sure which side of the line you are on, tell us how your process runs today and we will say honestly whether you need to build, buy or connect.