Choose no-code when the economics fit

In 2020, AWS Honeycode joined a growing group of tools for building internal applications with limited custom code. This article compared that approach with custom development and Microsoft Power Apps.

The product landscape and pricing have changed since publication. The useful part of the article is the decision method: match the application, audience, integrations, lifespan, and operating model before selecting a platform.

Where no-code can fit

No-code or low-code tools can work well when:

• the application serves a defined internal audience
• the workflow and data model are understood
• standard controls and interface patterns are acceptable
• supported connectors cover the required systems
• the organisation can govern makers, environments, and releases
• faster initial delivery is worth an ongoing platform dependency

The original article included an internal triage interface and a Teams-based workflow over a legacy system. It also described an on-demand warehouse control and a simple project tracker.

Where custom development may fit better

Custom code deserves consideration when:

• the interface is the product
• the audience is public or very large
• performance or accessibility needs exceed the platform
• the workflow depends on unsupported integrations
• the application requires fine-grained control over deployment or data
• long-term licensing changes would materially alter the business case

This is not a claim that one approach is universally better. It is a reminder that delivery speed is only one part of the decision.

Price the full life of the application

A no-code platform can reduce initial engineering work while introducing per-user, per-app, connector, environment, or capacity costs. A custom application can cost more to build and still require ongoing hosting, maintenance, security, and support.

Model at least three scenarios:

1. current users and transaction volume
2. expected growth
3. a high-use or integration-heavy case

Include development, licensing, support, change, monitoring, training, and exit cost. Use current vendor terms rather than the 2020 prices that appeared in the original post.

Treat connectors as architecture

A connector can save development work, but it also defines an identity and data boundary. Confirm:

• which account or workload identity the connector uses
• what data it can read or change
• how secrets and tokens are managed
• which failures are retried
• where activity is logged
• who reviews new connectors

A visual builder does not remove software engineering. It moves some engineering decisions into platform configuration and governance.

Plan for product and team change

The original article discussed earlier business-app tools that were later superseded. That history matters: an internal app may outlive the product version used to create it.

Keep source definitions, data contracts, owners, test cases, and an export or migration plan. Train more than one person to operate the application.

Make the choice around the workflow

Choose a representative workflow and build the smallest test that exposes the hard parts: permissions, integration, exceptions, mobile use, accessibility, and lifecycle.

Then compare the measured result with custom development and the organisation’s operating skills. The right answer may be low-code, custom code, or a combination of both.

This archive does not retain the original vendor links or price claims. The products and commercial terms have changed since publication.