Low-code vs custom development: choosing the route in the AI era

Most products eventually need a bit of both.

OutsourcingVN is operated by Netbase JSC, which sells custom development, so this comparison is written by a supplier with an interest in the custom answer. The criteria below hold regardless of who builds, and the page names where a low-code or AI app-builder platform is the better fit.

Contents

• How do the two routes compare?
• Which route fits the application?
• Worked scenario: an operations team automating supplier approvals
• What does Netbase bring to a custom build?
• Which questions should you ask a low-code vendor or a custom development supplier?
• What goes wrong with each route?
• How this guide is sourced and where it stops
• Where does AI fit in a low-code versus custom development decision?
• Common questions
• Scope the route before you commit

How do the two routes compare?

A low-code or AI app-builder platform (a visual, model-driven tool, or one that generates an application from a prompt and a schema) and custom development are not opposites so much as different places to put the same complexity.

No platform fits every workflow, so the questions below decide module by module rather than for the whole application at once.

Worked scenario: an operations team automating supplier approvals

An operations team at a mid-size distributor wants to replace a spreadsheet-and-email supplier approval process: a request form, a three-step sign-off, a record of who approved what and a monthly summary. Nobody on the team can write code, and the finance lead wants the first version running within a month.

A low-code platform fits every question above. The form, the approval steps and the audit trail are standard shapes the platform already models, the team can adjust the sign-off rule themselves as policy changes, and there is no integration beyond notifying people by email. Six months later, the same distributor wants the approval outcome to write directly into its ERP's purchase-order record through an API the platform's connector does not support. That one module moves to a small custom service that reads the platform's webhook and writes the order; the rest of the approval workflow stays exactly where it was, which is the mixed outcome most real products settle into once one integration outgrows the platform.

What does Netbase bring to a custom build?

Reusing Netbase productized modules can cut development time by up to 60%; that is an upper bound tied to module reuse, not a typical saving, and it narrows the speed gap a platform otherwise holds over a build from nothing. Netbase delivers remote-first from Hanoi in Agile increments with weekly reviews, using AI-assisted engineering under human review, which keeps a custom build's pace closer to a platform's iteration speed; AI-assisted software delivery sets out what that review discipline changes for the buyer specifically.

On the closest published example of a custom build at this scale, since 2020 Netbase has worked as offshore development and managing partner on a multi-tenant cloud ERP SaaS platform for a US client that is not named; phase one, from 2020 to 2023, covers CRM, real-time messaging, HR, a knowledge base, custom fields and workflows, work and project management and API integrations, on a stack that includes React and Next.js, Laravel and Strapi, PostgreSQL, MySQL, MariaDB and MongoDB on AWS. For custom development the client owns the IP created for it; Netbase productized modules and products are licensed, not transferred, so the ownership line in the comparison above is a contract term to check, not a given.

Which questions should you ask a low-code vendor or a custom development supplier?

• For a low-code vendor: what happens to our data, automations and logic if we leave the platform? Ask for the export format, not a description of flexibility.
• For a low-code vendor: where exactly does the platform's limit sit for our busiest workflow, in records, users or automation runs per period?
• For a custom development supplier: how much of the build reuses existing modules rather than being written from nothing, and on what licence?
• For either: who in the organisation can maintain this in a year, and what do they need to know?
• For either: what is the plan if one module outgrows the platform, or if the custom build needs a visual editor for business users later?

What goes wrong with each route?

• Outgrowing the platform mid-build. Signal: a workaround stacked on a workaround to make one screen do something the editor was never meant to do. Owner: the product owner, who should split that module to custom development rather than keep forcing it.
• Building a commodity workflow from nothing. Signal: months spent custom-coding a form, approval and dashboard that a platform already models. Owner: whoever scopes the build, who should trial a platform before committing to code.
• Ignoring the export path until it is needed. Signal: nobody knows what leaving the platform would produce. Owner: procurement, who should ask the export question before signing, not when leaving.
• Treating low-code as needing no governance. Signal: dozens of unaudited automations built by different people with no owner. Owner: IT or operations, who should apply the same change control a custom build would get.
• Choosing custom development to avoid a vendor relationship, not because the logic needs it. Signal: the requirements are standard forms and approvals, but nobody considered a platform. Owner: the sponsor, who should run the questions above before scoping code.

How this guide is sourced and where it stops

The multi-tenant cloud ERP record is the closest published example of a custom build at this scale, and the supplier-approval scenario above is illustrative.

Where does AI fit in a low-code versus custom development decision?

The clearest use sits at the handover point this guide's worked scenario describes: once a module outgrows its low-code platform, reading that module's screens, data model and automation rules to draft a first-pass technical specification, or a scaffold of the equivalent custom components, for an engineer to check against the platform's actual behaviour before building begins. The same reading can draft a first-pass list of which automations and connectors a given platform's export would need to reproduce, a starting point for the questions this guide already recommends asking a vendor. None of that drafting decides whether a module has really outgrown its platform, or whether the resulting custom build matches the original workflow; a named engineer checks and decides that.

Scope the route before you commit

Bring the workflow's forms, its busiest integration and who needs to keep changing it. Custom build vs SaaS covers the neighbouring decision when the alternative is a finished product rather than a platform you configure, SaaS product development is the workflow to scope once you are building a product to sell, and document and approval workflows and Laravel cover two of the shapes a custom build commonly takes. Custom Product Engineering is the service that delivers a custom build once you choose that route, with milestone project delivery setting out how that build is governed, and AI engineering enablement is the service to scope if your own team wants to adopt AI-assisted building rather than commission it.

OutsourcingVN is Netbase's own outsourcing-services platform. Submit a project with the workflow and the limit you are worried about, and a person will reply with whether a platform, a custom build, or a split between the two fits.

Related services and solutions

Sources

• IBM, "What is low-code?"
• OutSystems, "How to Avoid Vendor Lock-In When Choosing a Low-Code Platform"