Off-the-shelf, no-code or custom software: when to use each

The question rarely arrives as a technology question. It arrives as a complaint. Renewal dates live in one person's calendar and a contract lapses. Field engineers photograph job sheets and someone rekeys them on Monday morning. Then one person proposes a product, another proposes building something, a third has already made a spreadsheet that half the team relies on, and the discussion becomes a preference argument. The three options are genuinely different tools, and the choice gets easier once you know what each is good at and where it stops.

What do off-the-shelf, no-code and custom software actually mean?

The words get used loosely, so be precise before comparing them.

Off-the-shelf software is a product many companies license and use much as it comes. Today that usually means software as a service (SaaS), which the vendor hosts and updates while you pay a subscription. You accept the vendor's data model and its assumptions about the work.

No-code platforms let someone build a working application through a visual interface, without writing code. Low-code platforms do the same but let a developer drop into real code for the parts the visual builder cannot express. The line between them is commercial rather than technical, and most serious platforms sit somewhere in the middle.

Four that operations teams meet most often:

• Microsoft Power Apps, Microsoft's low-code app builder, which stores data in Microsoft Dataverse and reaches Microsoft 365 and external systems through connectors.
• Retool, aimed at internal tools, which builds interfaces on top of any database, API or model you already have rather than holding the data itself.
• Airtable, once a shared database, now an app-building platform with automations, AI agents and role-based access controls.
• Google AppSheet, a no-code builder that sits on data you already keep in Google Workspace, Microsoft 365, Salesforce, Cloud SQL or REST APIs.

Custom software is an application designed around your process: an internal tool, a customer or supplier portal, a pricing engine, a mobile app for field staff. You set the workflow and the data model, and you can own the code outright if the contract says so.

When is off-the-shelf software the right answer?

Start here for any standard process, because a vendor building the same thing for thousands of customers will almost always do it better and cheaper than you can. Accounting, payroll, e-signature, help desk ticketing and applicant tracking are settled categories. Building your own version is very hard to justify.

The test is fit against your real work, not against a feature list. Take your three most awkward cases, the non-standard discount, the client with two billing entities, the order that ships from two warehouses, and walk them through a trial with your own data. Demos are built to show breadth. Your exceptions are where the workarounds will live for the next five years.

One caution: buying is easy, and that is the problem. Zylo's 2026 SaaS Management Index reports an average of 305 applications per organization in its dataset, with 78% of IT leaders seeing unexpected charges tied to AI features or consumption-based pricing and 61% cutting projects because of unplanned SaaS cost increases. Every subscription needs an owner, a renewal date in a diary and an exit plan.

When do no-code and low-code platforms fit?

These platforms are at their best on the work that sits between the big systems: the intake form, the approval chain, the inspection checklist, the operations dashboard, the small register that currently lives in a spreadsheet. That work is real, it rarely justifies a development project, and nobody sells a product for it because it is specific to one team.

Good candidates share a shape:

• A small number of users, usually inside the company.
• Modest data volume, thousands or low tens of thousands of records rather than millions.
• Logic a person can explain on one page.
• Integrations the platform already supports through a maintained connector.
• A process still changing month to month, where adjusting it on Thursday afternoon matters more than elegance.

There is a structural argument too. The 2025 MuleSoft Connectivity Benchmark Report found the average enterprise manages 897 applications with only 29% integrated, and that IT teams spend 39% of their time building custom integrations. If the central team is that stretched, letting the people closest to the work build the small pieces is capacity, not compromise.

Where do no-code platforms run out of road?

Every platform has a ceiling. The failure is not hitting it. The failure is hitting it without noticing, then stacking workarounds until an important process depends on something nobody can safely change.

Five limits show up repeatedly:

1. Volume and performance. Screens that felt instant with 2,000 records get slow at 200,000. Platform query and automation limits are usually documented and usually discovered late.
2. Logic complexity. Multi-step state, conditional pricing, scheduling across constraints and anything with real concurrency push past what a visual builder expresses cleanly.
3. Integration depth. A maintained connector covers common operations. The specific field, the custom endpoint on your ERP, the batch reconciliation at 2am often are not covered, and the workaround is a manual export.
4. Testing and change control. Custom code gets version history, automated tests and a review step. Many platform apps get edited live, by whoever has the rights, with no record of what changed or why.
5. Cost at scale. Per-user licensing rewards small apps and punishes popular ones. Microsoft's published price for Power Apps Premium is $20.00 per user per month paid yearly, with extra Dataverse capacity at $40.00 per GB per month. Excellent value for 15 people in finance. For 400 warehouse staff, model it against the cost of owning an application outright.

Illustrative example: Consider a third-party logistics company with roughly 180 staff. A depot supervisor builds a no-code app so drivers can record delivery exceptions on a phone instead of calling the office, and it works. Within a year three depots use it, it holds two years of records, and someone has bolted on a customer-facing status screen. Now pages take eight seconds to load, that screen needs data the platform cannot pull from the transport management system, the license bill covers every driver, and the supervisor has moved to another region. Nothing has failed. The app simply grew past the tool, and a live operational process now has no owner, no documentation and no plan.

How do you use no-code without creating shadow IT?

Shadow IT means technology the business runs without the knowledge, standards or support of whoever is accountable for systems. A no-code platform does not create it, but it makes it far easier to produce, because the barrier to a new app is an afternoon.

The answer is not to ban the tools. It is to apply the expectations you would apply to any business system, proportionate to what the app touches:

1. Register every app that more than one person depends on, with what it does and what data it holds.
2. Name two owners, one business and one technical, and put ownership transfer in the leavers process.
3. Set data boundaries centrally. Power Platform data policies, for example, let an administrator control which connectors makers can use, and an app that breaks a policy is suspended rather than quietly leaking data.
4. Separate build from production, with a deliberate step between experimenting and the business relying on the result.
5. Tier by consequence. A team checklist needs light touch. Anything holding customer data, financial records or a regulated process gets reviewed before it goes live.
6. Review access quarterly, especially for apps reaching outside the company.
7. Require an export path. An app you cannot leave is a decision you cannot revisit.

Applied proportionately this takes very little time, and it prevents the expensive version of the problem: finding out during an audit that a core process runs on an app in a former employee's personal account.

When does custom software earn its cost?

Custom software is worth commissioning when at least one of these is true, and rarely otherwise:

• The process is specific to how you compete. Your pricing logic, your routing rules, your service model. If a customer would notice you doing it differently, a generic tool will grind against it forever.
• No product fits the core steps. Gaps at the edges point to buying and integrating. Gaps in the middle, where every workaround adds manual effort or risk, point to building.
• It has to sit on top of a system of record. A portal or internal tool that reads and writes through your ERP or CRM API, so staff and customers never work inside the ERP itself.
• Volume, performance or integration exceeds the platform. The limits above, met rather than anticipated.

Be equally clear about what you take on. Custom software means someone must host, secure, update and improve it for as long as the business depends on it. Our guide to what drives the cost of custom software breaks that down, and technical debt in business systems covers what happens when maintenance is never funded.

How do the three options compare?

Most companies of 20 to 500 people use all three at once, and that is the right answer rather than a failure of discipline. The judgment is matching each process to the right tool and revisiting it when the process changes. Our pillar guide on build, buy or integrate works through that decision in more depth.

How do you move from no-code to custom without a painful rebuild?

A move usually happens under pressure, which is why it goes badly. Planned properly it is one of the lower-risk software projects you can run, because you already know what the software has to do.

1. Treat the existing app as the specification. It is a working, tested statement of the process, including the exceptions someone added at 6pm in March. Screenshot every screen, export the rules and interview daily users.
2. Get the data out early. Export a full copy and check that it is complete and usable, not just that the button works. Attachments, audit history and lookup relationships usually do not travel.
3. Rebuild the workflow, not the interface. Copying screens faithfully carries across every compromise the platform forced on you.
4. Move one slice at a time. Martin Fowler's strangler fig pattern describes this well: new components take over behavior gradually while the old system keeps running, so value arrives early and each step is small enough to reverse.
5. Decide deliberately what stays. Often the right outcome is a custom core plus a few no-code apps at the edges that are well served where they are.

Write the requirements down first, even for a rebuild. How to write a requirements brief a development partner can use covers the structure.

How Kastling approaches this choice

Kastling is an AI solutions and implementation partner. Custom software sits alongside AI integration and automation and AI and cloud infrastructure, so the recommendation can be a product you buy, a platform app your team maintains, an integration between systems you already pay for, or something built for you.

We start by understanding the work before the technology, and we prefer to connect existing systems rather than replace them. Where a build is the right answer, Custom Solutions covers internal tools, dashboards, customer or supplier portals and web or mobile apps, with or without AI.

An engagement starts with a free discovery call. A clearly defined brief can move straight to a scoped proposal, while broader operations work often begins with a separately scoped, paid audit. Before anything is built we agree the scope, how success will be measured and who owns the data, the code and the accounts. Maintenance is optional and covered by a separate agreement.