Quick answer: when to buy and when to build
The short rule: if a process does not create competitive advantage (accounting, email, timekeeping), buy existing software and adapt your process to it. If the process is what differentiates your business, consider building or commissioning that core. Most organizations sit between the two extremes, so the realistic choice is usually a combination.
This framing follows Martin Fowler's “utility vs strategic” argument: what separates the two is whether the underlying business function is a differentiator. Fowler argues that for a utility function you buy the package and adjust your process to match it, while for a strategic function using the same software as your competitors would cripple your ability to differentiate. He also notes that only a few projects are truly strategic.
The UK government's technology blog (GOV.UK) points the same way: the most important thing is that a solution works and meets user needs; if requirements are very common and easily met by suppliers, buy, for example an email service. A tool tied to your core competency may be worth building.
Four options: SaaS, configure/low-code, custom, hybrid
“Build or buy” is not really a binary choice. There are at least four routes, and each shifts risk and control in a different direction.
| Route | Fits when | Trade-off |
|---|---|---|
| Off-the-shelf SaaS | The process is common and non-differentiating; you need it soon | You follow the vendor's roadmap; customization is limited; you depend on the terms of service |
| Configure / low-code on a platform | You need custom forms, approval flows and reports but the logic is not very complex | Platform dependency; complex configuration gradually becomes hard-to-maintain “code” |
| Custom software | The process is a competitive advantage, or no product fits | You own long-term operation, maintenance and security, whether built in-house or outsourced |
| Hybrid | Buy the utility parts, build the core, connect them via APIs | Requires integration skills and data governance across several systems |
The package customization trap
Fowler highlights a common mistake: buying a package for a utility function and then spending heavily to customize it, which he considers just as wasteful. In “Package Customization” he notes that the problem tends to surface when the vendor releases an upgrade and the customizations break, and he recommends treating upgradeability as a first-class requirement for packages.
Hybrid is the default for many organizations
The GOV.UK post describes a combined approach: building some components to limit the number of platforms in use, or hiring specialists to build the product for you. A common pattern for Vietnamese businesses is to use existing accounting, e-invoicing and email products, then build custom software for distinctive processes and integrate the systems through APIs.
Decision criteria table
Score each option against each criterion. There is no standard scoring formula; the point is to make operations, finance and engineering state their assumptions explicitly.
| Criterion | Question to answer | Leans to buy | Leans to build / commission |
|---|---|---|---|
| Differentiation | Does this process make us better than competitors? | No, everyone does it the same way | Yes, this is how we compete |
| Fit | How much of the core need does an existing product meet without customization? | Most of it; we can change our process | Only with deep customization |
| Total cost of ownership (TCO) | Have all lifecycle cost components been counted? | Predictable subscription, little operating effort | Customization and upgrade costs of a package exceed building |
| Time to value | How soon must it be usable? | Immediately | Can be phased, starting with a minimum version |
| Integration | Which systems must it connect to? Are there APIs, webhooks, exports? | The product has APIs and ready connectors | Needs data flows the product cannot support |
| Data control | Where is data stored, in what formats can it be exported, who can access it? | Full export in open formats | Strict data control requirements SaaS cannot meet |
| Vendor lock-in | How hard and costly would switching be? | Clear exit path, open standards | Every buy option locks you into one platform |
| Team capacity | Who will manage, operate and oversee it long term? | No internal engineering team | Have or will build engineering capability, or have a long-term partner |
Components of total cost of ownership
The GOV.UK Service Standard asks teams to understand the total cost of ownership of technology and preserve the ability to make different choices in future. When comparing, list all of the following for each option instead of comparing only the initial price:
- Licence or subscription fees, and how they scale with users and data.
- Implementation: configuration, data migration, training.
- Development and customization, including internal effort.
- Integration with existing systems and maintenance of those connections.
- Infrastructure, monitoring, backup and security.
- Maintenance, upgrades and bug fixes over the lifecycle.
- Process change and lost productivity during transition.
- Exit costs: data export, migration, running systems in parallel during replacement.
You cannot outsource risk
GOV.UK stresses that whichever route you choose, you cannot outsource risk, and you need the resources and knowledge to manage your products long term. It also observes that organizations with strong technical expertise are more likely to consider building. That is why the team capacity criterion deserves an honest assessment.
Questions to ask vendors
Answers should be written into the contract, not just the proposal. For the stages of a project, see our custom software development process guide.
When buying SaaS or a low-code platform
- In what formats can we export all our data, how often, and at what cost?
- Is there a public API, what are the rate limits, and is the documentation complete?
- Where is data stored, and who on the vendor side can access it?
- What is the policy and notice period for price and feature changes?
- On termination, how long is data retained and how is it deleted?
- Can the configuration, workflows and forms we build on the platform be exported?
When commissioning custom software
- Who owns the source code, design documents and infrastructure accounts after handover?
- Does the code use the developer's proprietary libraries or frameworks? What are the licences of the open-source libraries?
- Will we have access to the code repository throughout the project?
- Could another team take over and continue developing the system? (A detailed handover list is in our custom software development process guide.)
Source-code and IP ownership
Vietnam's Law on Intellectual Property (consolidated text 11/VBHN-VPQH of 2022) has two directly relevant articles. Under Article 39(2), an organisation or individual that enters into a contract with an author to create a work owns the rights in Article 20 (economic rights) and Article 19(3) (the right to publish the work), unless otherwise agreed. Under Article 41, an organisation or individual to whom some or all of those rights are transferred under a contract becomes the copyright owner.
Law No. 131/2025/QH15 amending the IP Law, in force from 1 April 2026, does not change these two articles, but it amends Article 22(1): computer programs are protected as literary works whether in source code or machine code, and the author and the copyright owner may agree in writing on repairing and upgrading the program.
The key phrase is “unless otherwise agreed”. Rights to source code, the developer's pre-existing libraries, design documents and data are all determined under contract; also spell out who may modify and upgrade the software after handover, and have a lawyer review the clauses before signing.
With SaaS you usually receive a right to use the software, not ownership of its code. What you must hold on to is control of your data; GOV.UK recommends always keeping full control of any data you store.
Exit strategy: plan it from day one
GOV.UK's guidance on lock-in describes it as the situation where switching from one technology or provider to another is difficult, time-consuming and disproportionately expensive. Not all dependency is bad: GOV.UK says the value of a less portable service can outweigh the risk, but you should consider in advance how you would change providers and under what circumstances. For SaaS it advises choosing products that use open standards and formats so you can export data to a new environment. It also notes that a common cause of lock-in is the availability of skills and knowledge.
- State in the contract: export formats and the period of migration support on termination.
- Test real data exports periodically rather than trusting the documentation.
- For custom software: keep the code in a repository you control, with deployment and architecture documentation.
- Keep cloud accounts, domains and certificates in the company's name.
- Integrate through APIs and avoid scattering business logic across hard-to-move configuration.
- Make sure at least one person on your side understands the system well enough to oversee the vendor.
A five-step decision process
If you build the core, the architecture must be solid enough not to need a rewrite as you grow; see SaaS systems that survive growth. EYC builds custom software and SaaS products, including Early Years Circle for early childhood education, so we have an interest in this topic. For our services see software and SaaS; scope, source-code ownership and support are defined under contract.
- Map the current process and user needs; you can use the approach in mapping a workflow before automating.
- Classify each part as utility or strategic. Following Fowler, keep the strategic bucket small.
- Survey existing products for the utility parts and try them without customization first.
- Score the options with the criteria table, listing all TCO components and an exit plan.
- Start small with a minimum version or pilot phase, then expand based on real usage.
Frequently asked questions
Should we build custom software or buy off-the-shelf?
If the process is common and does not create competitive advantage, buying is usually more sensible. If the process differentiates you or no product fits, consider building the core. Many organizations combine both.
Who owns the source code when you hire a software company?
Under Article 39(2) of Vietnam's IP Law, the party that contracts the author owns the economic rights and the right to publish the work, unless otherwise agreed. Source-code ownership is therefore set by the contract; write it explicitly and have a lawyer review it.
What does total cost of ownership for software include?
It includes licences or subscriptions, implementation, customization, integration, infrastructure, maintenance and upgrades, process change, and exit costs when replacing the system. Comparing only the purchase price usually makes the "cheap" option look cheaper than it is.
Can low-code replace custom software?
Low-code suits forms, approval flows and reports with moderate logic. As logic grows complex, configuration can become hard to maintain and platform-dependent, which is the point to reassess.
How do we avoid vendor lock-in?
Choose products with open standards and formats, put data export rights in the contract, test exports periodically, and keep source code and infrastructure accounts in the company's name.