Build, buy or compose: deciding between packaged software, low code and custom builds

Background

A distributor wants to move order taking off WhatsApp and spreadsheets. A clinic chain needs appointment booking that talks to its billing. A manufacturer wants shop floor data in the same place as its SAP Business One or Odoo records. In each case, someone has to decide whether to buy a product, configure a low code platform or have something built.

The decision is often made quickly and for the wrong reasons. A product is chosen because a competitor uses it. A custom build is chosen because a developer is available. A low code tool is chosen because the trial was free. The consequences show up later, in integration work nobody priced, in licences that rise with headcount, or in a custom system that only one person understands.

Approach

This paper is based on analysis of public documents and the practices we use in delivery. We used ISO/IEC 25010:2023 as a reference for the quality characteristics that any route has to meet, such as maintainability, security and compatibility, and the OWASP Application Security Verification Standard as a reference for the security work a custom or low code build cannot skip. Where personal data is involved, we considered the obligations in the Digital Personal Data Protection Act, 2023 (India), which apply whichever route you choose.

The decision path comes from how we advise clients before any build, including cases where our advice is to buy a product and not to build at all. Where we mention products such as Tally, Zoho, Odoo or SAP Business One, it is to illustrate a category, not to recommend or rank them.

Findings

1. Each route has a natural home

Packaged software fits processes that are broadly the same across businesses: accounting, GST returns, payroll, basic CRM, email. The vendor carries the cost of keeping up with regulation and security. You accept their way of working.

Low code fits internal workflows that change often and are owned by a business team: approvals, simple data capture, dashboards, forms that feed a packaged system. It is fast to start. It becomes harder to manage as logic grows and as more people build on it without review.

Custom builds fit processes that are genuinely different from competitors and worth protecting, or integrations that no product handles. They give full control and full responsibility, including security, hosting and maintenance for as long as the system lives.

2. Most real systems are composed

Few businesses run on one route alone. A typical arrangement is a packaged accounting and ERP core, a few low code workflows around it, and custom code where integration or differentiation demands it. The question is less "which route" than "which route for which capability".

3. Integration is the cost most often missed

Products are priced per user or per month. Builds are priced per feature. Integration between them, such as pushing orders into Tally, syncing stock with an online store or generating e-invoices through the IRP, is often priced by nobody until it is needed. It can easily become the largest single piece of work.

4. Exit cost is rarely considered

Leaving a product means exporting data, rebuilding integrations and retraining people. Leaving a low code platform can mean rebuilding every workflow, because logic built on one platform rarely moves to another. Leaving a custom system depends on whether the code, documentation and hosting are in your hands.

5. Compliance applies to every route

Buying a product does not transfer your data protection obligations. Under the DPDP Act you remain the data fiduciary, and the vendor is your processor. Low code platforms raise the same questions about where data is stored and who can see it. Custom builds put every control in your hands, which is both an advantage and a duty.

6. Change rate decides more than features

A process that will change every month suits configuration or low code. A process that is stable for years suits a product or a well built custom system. Choosing a route that cannot keep up with the rate of change produces either workarounds or constant rework.

A framework

We call this the Six Question Decision Path. Apply it to each capability separately, for example order capture, invoicing, inventory, approvals and reporting, one at a time.

1. Process fit. Does a mainstream product handle this process the way you need, with configuration only? If yes, lean towards buying. If the gap is small, consider changing your process to match the product before building anything.
2. Differentiation. Is this capability part of why customers choose you, and would a competitor gain from copying it? If no, do not build it. If yes, building or composing is justified.
3. Integration. How many other systems must this capability talk to, and do products offer reliable connectors for them? Heavy integration with local systems, such as Tally, GST portals or a particular bank, often points to custom integration code even when the core is bought.
4. Data and compliance. Where will the data live, who can access it, and can you meet your DPDP and sector obligations on this route? If a product or platform cannot give you the controls and contract terms you need, that rules it out regardless of price.
5. Change rate and ownership. How often will this change, and who will change it? Frequent, business owned change suits low code with review. Rare, technical change suits custom code with proper engineering practice.
6. Total cost over five years, including exit. Add licences, implementation, integration, hosting, support, internal time and the cost of leaving. Compare routes on this full figure.

Reading the answers

• Buy when process fit is high, differentiation is low and the product passes the compliance check.
• Low code when the capability is internal, changes often, has a clear business owner and stays within modest complexity.
• Build when differentiation is high, products do not fit and you can fund ownership for the system's life.
• Compose when the answers differ across capabilities, which is the common case: buy the core, use low code at the edges, build the integrations and the parts that set you apart.

Recommendations

1. List capabilities before choosing products. A one page list of what the business needs to do prevents the choice being made by the first demo.
2. Price integration explicitly. Ask every vendor and every builder to name the integrations and their cost.
3. Ask for the exit plan up front. How do you get your data out, in what format, and how long does it take.
4. Put review around low code. Treat low code workflows as software: version them, review them and know who owns each one.
5. Build only what you will maintain. If you cannot fund maintenance for five years, a custom build will decay. Buy or compose instead.
6. Revisit the decision. Products improve and businesses change. A capability that justified a custom build three years ago may now be served well by a product.

Limitations

The framework is qualitative. It does not weight the six questions numerically, because the right weights depend on the business, and a precise looking score can hide weak reasoning. Total cost estimates over five years carry real uncertainty, particularly for licence prices and internal time. The paper is written for small and mid sized businesses and may understate the procurement, architecture and vendor management concerns of large enterprises. We also deliver custom builds, which is a potential bias. For that reason the paper states plainly that buying is the better choice for most standard processes.

Sources

• ISO/IEC 25010:2023
• OWASP Application Security Verification Standard
• Digital Personal Data Protection Act, 2023 (India)