Somewhere in your business right now, there is a process that doesn’t fit the software it lives in. Your team has invented workarounds: an extra spreadsheet, a shared inbox, a “just message K. Bee and she’ll sort it” step. It works, mostly. And every month it quietly costs you hours, errors and the occasional lost customer.
When that pain gets loud enough, businesses ask the classic question: should we buy something off the shelf, or build custom? After two decades of building systems, our honest answer is that the question is framed wrong. It is never all-or-nothing. The right question is: for this specific capability, is our way of doing it an advantage, or just a habit?
That reframing matters because the two are constantly confused. A habit is something you do a certain way because you always have, and generic software will do it just as well, if not better. An advantage is something you do differently that customers can feel. Software should conform to your habits and bend to your advantages. Most build-or-buy arguments are really arguments about which is which.
Where off-the-shelf wins, almost every time
Accounting, payroll, email, calendars, document storage, video calls: buy them. These are solved problems where your process should conform to the tool, because the tool encodes decades of best practice and compliance. Custom-building any of these is how projects go to die.
The same is true for standard CRM and e-commerce needs. If your sales process looks like most sales processes, a well-configured mainstream product will serve you better than anything built from scratch cheaper, faster, and maintained by someone else. You also get a steady stream of improvements you didn’t pay to build, a security team you don’t employ, and an ecosystem of people who already know the tool.
An engineering-led firm should tell you this plainly. If a consultancy’s answer to every problem is a custom build, they are selling billable hours, not outcomes.
Where custom earns its cost
Custom work earns its keep in exactly two places.
The first is your differentiator, the thing you do differently that customers choose you for. If your pricing model, logistics routing, booking flow or customer experience is genuinely unusual, forcing it into generic software sands off the edge that makes you competitive. This is where a custom application, or a custom module on top of a standard platform, pays for itself. The test is simple: if a feature is the reason a customer picks you over a competitor, you don’t want it working exactly the way that competitor’s off-the-shelf version does.
The second is the connective tissue. Off-the-shelf tools are built to be everything to everyone, which means they are rarely built to talk to your particular combination of other tools. Integration layers the pipes that move data between your website, CRM, inventory, accounting, and reporting are almost always custom, almost always small, and almost always the highest-ROI code a growing business can own.
The middle ground everyone forgets
The debate is usually framed as “buy this box” versus “build from nothing,” but most real systems live in between, and the middle is where a lot of money is saved.
A great deal of what feels like it needs custom software is actually configuration: mainstream platforms are far more flexible than their out-of-the-box defaults suggest, and an afternoon spent setting one up properly can remove the need for a build entirely. A step up from that is extending a platform through its own automation or app framework to genuinely custom behaviour, but riding on someone else’s maintained foundation. Only when neither of those fits makes sense does a ground-up build make sense.
The skill is knowing which rung of that ladder a given need sits on. Reaching for a full custom build when configuration would do is the most common and most expensive mistake we’re called in to unwind. Just as often, the opposite happens: a business bends painfully around a platform’s limits for years rather than commissioning the small extension that would have fixed it in a fortnight. Both errors come from treating build-versus-buy as a single yes/no rather than a question you answer capability by capability.
The hybrid pattern that actually works
The systems we build for clients usually follow the same architecture: standard products for solved problems, a custom layer where the business is genuinely different, and engineered integrations, so the whole thing behaves as a single platform. The custom portion is often less than 20% of the system, but it is the 20% that makes the other 80% fit your business, not the other way around.
This pattern also protects you from the two classic failure modes. All-off-the-shelf businesses stall because their processes slowly deform to fit their tools. All-custom businesses drown because they maintain software that solves problems someone else has already solved better.
Four risks to weigh before you decide
Cost is the obvious factor. These four are the ones that surprise people later.
Lock-in cuts both ways. Off-the-shelf can trap you through pricing that climbs as you grow and data that is hard to get out; custom can trap you if it was built by someone who documented nothing. Ask, of either path, “how hard is it to leave?”
Data ownership is easy to overlook until you want your history back. With off-the-shelf, know where your data lives and how you get it out. With custom, it’s yours by default an advantage worth counting.
Key-person risk is the quiet killer of custom projects. A build that only one person understands is a liability, not an asset. Insist on documentation and more than one pair of hands from the start.
Maintenance is not optional for either. Off-the-shelf hides it inside the subscription; custom makes it your responsibility. Neither is free; the difference is who does the work and whether you planned for it.
Count the full cost, not the sticker price.
Whichever way a decision leans, run the numbers over five years, not one. Off-the-shelf costs look small every month but compound: per-seat pricing that scales with your headcount, paid tiers you’re pushed into as you grow, and the hidden cost of staff hours spent working around the tool’s assumptions. Custom costs look large upfront and then behave differently: no per-seat fees, but a real ongoing obligation to maintain, patch and evolve what you own; budget roughly 15–20% of the build cost per year for that, and treat any estimate that omits it as incomplete.
The five-year view regularly reverses the instinctive answer. Picture a workaround that occupies most of one person’s time, say THB 40,000 a month in wages spent keeping disconnected systems in step. That’s THB 480,000 a year, and THB 2.4 million over five years, for work that adds nothing. A custom integration that removes it might cost a fraction of that to build and 15–20% of the build to maintain each year and still pay for itself several times over. But only if it was scoped by someone who priced the maintenance honestly.
The same maths can just as easily point the other way. A custom build that duplicates what a THB 1,500-a-month product already does will lose that comparison every time. The point of the five-year view isn’t to favour one answer; it’s to stop the sticker price from deciding for you.
A few objections worth answering
“Won’t it break when a supplier changes their software?” Connections need real maintenance, and any honest partner budgets for it. But a well-built integration is far more robust than a human retyping data, and when something does change, you fix one connection rather than retraining three people.
“Is our data safe if everything’s connected?” Connected is not the same as exposed. A designed system usually improves security, because data stops living in email attachments and unmanaged spreadsheets and starts living in one place with proper access control.
“Aren’t we too small for this?” If anything, the opposite. The smaller the team, the more a few hours of automated flow matter, because you don’t have spare people to absorb the friction.
“We tried automation before, and it turned into a mess.” Usually, that means someone wired tools together without first mapping the flow. Automation laid over a broken process makes the mess faster. The fix is the order of operations: understand the flow, simplify it, then automate what remains. Done that way, the result is something your team trusts rather than something they quietly work around.
If you do build, de-risk it.
Deciding to build is not the same as writing a blank cheque, and most custom software horror stories stem from treating it as such. The failures are predictable, which means they are avoidable.
Build the smallest version that delivers real value, and get it into daily use before expanding a system. Earning its keep in month two tells you far more than a specification signed off in month six. Insist on owning the code and the documentation, not renting understanding from the one developer who has it all in his head. And agree the maintenance arrangement up front, because software that isn’t maintained doesn’t hold still; it slowly stops working as everything around it changes. Scoped this way, a custom build stops being a gamble and becomes an asset with a known cost of ownership.
A short checklist before anyone writes code
The build-or-buy call should be made by someone who has seen both fail. Before any code, insist on three things: a map of the actual process, not the org-chart version, but what really happens; a hard look at whether the process should be simplified before it’s automated, and a total-cost view that includes maintenance, not just delivery.
A surprising number of “we need custom software” conversations end with “you need two integrations and one process change,” which is a much cheaper sentence.
That is the value of senior capability at the decision stage. Junior teams build what you ask for. Senior teams tell you what not to build.
WereHumans provides exactly that: senior engineering and design capability, without the cost or commitment of building an in-house team. We’re based in Pattaya, work globally, and we’re happy to be the people who talk you out of a build you don’t need.
Have a build-or-buy decision on your desk
Call Eve on: +66 89 354 9916 or visit werehumans.com.