Software choices / Low-code and custom
Put custom behavior where it belongs.
A standard approval screen, a connection to an existing system and a business-specific calculation are different implementation decisions. Compare the work each option must cover before choosing a platform or commissioning an application.
Separate the decisions
One workflow can use several approaches.
Consider an illustrative returns process. Existing commerce software holds the order and may already support return reasons. Staff need an exception queue. A connection sends the approved outcome back to the order system. A special eligibility calculation may need custom code. Replacing all four parts with one new application requires a reason for each replacement.
- Configuration
- Use supported settings and rules in software you already operate. Confirm that the required behavior fits without a growing collection of workarounds.
- Low-code development
- Build an application with a platform's visual tools, models and extensions. The platform supplies capabilities; the team still owns the application's behavior and operation.
- Integration and custom code
- Integration connects systems; custom development implements behavior in code. Either can support a configured product or a low-code application. These choices are not mutually exclusive.
Four implementation choices
Compare the responsibility each option takes on.
Use the same real task, exception and acceptance criteria for each candidate. A polished happy-path demonstration is insufficient. The returns examples below are illustrative.
Configure the existing product
01Choose when: Its supported behavior covers the task and the business can accept its constraints.
- Potential fit
- Standard fields, roles, statuses and approval rules already exist in the system of record.
- Inspect first
- Actual edition, supported customization, update behavior and the list of exceptions.
- Returns example
- Use existing return reasons and status settings without creating another order database.
- Accountable owner
- The process owner accepts the workflow; the product administrator owns configuration.
- Proof to request
- Representative records pass the full process, including correction and cancellation.
- Watch for
- Hidden manual steps or unsupported modifications are counted as standard functionality.
- Ongoing work
- Document settings, review vendor changes and retest affected rules.
Build on a low-code platform
02Choose when: Its data, interaction and lifecycle capabilities fit the application under realistic conditions.
- Potential fit
- A staff queue or form-based workflow can use the platform's supported building blocks.
- Inspect first
- Access model, extensions, environments, deployment process, licenses and service limits.
- Returns example
- Create an exception queue that displays order references and records a review decision.
- Accountable owner
- A named application owner and platform administrator share clear operating responsibilities.
- Proof to request
- Real roles, long records, failed connections, peak usage and release rollback are exercised.
- Watch for
- A visual editor is mistaken for an application that needs no testing or maintenance.
- Ongoing work
- Maintain models, flows, connectors, extensions and the people able to support them.
Integrate systems that already fit
03Choose when: The main gap is a handoff between systems rather than missing application behavior.
- Potential fit
- Each system performs its own job and a supported interface can carry the required records.
- Inspect first
- Record identifiers, authoritative fields, interface contracts, duplicate handling and failure recovery.
- Returns example
- Send an approved return result to the commerce system and reconcile its acknowledgement.
- Accountable owner
- System owners agree data authority; an integration owner handles failed handoffs.
- Proof to request
- Repeated delivery does not duplicate the action, and interrupted work can be reconciled.
- Watch for
- A listed connector is assumed to cover every required operation and failure state.
- Ongoing work
- Monitor queues, credentials, interface changes and unresolved records.
Develop the behavior in custom code
04Choose when: Specific rules or interactions justify owning their implementation and lifecycle.
- Potential fit
- The important requirement cannot be represented acceptably by the evaluated products or platforms.
- Inspect first
- Executable rule examples, interaction requirements, operating constraints and a maintenance owner.
- Returns example
- Implement a special eligibility calculation behind a defined interface used by the review queue.
- Accountable owner
- The business owns the rule; engineering owns its implementation and supporting evidence.
- Proof to request
- Accepted rule cases, boundary conditions, failure behavior and a reproducible release.
- Watch for
- Source ownership is mistaken for freedom from cloud, library, supplier or knowledge dependencies.
- Ongoing work
- Fund maintenance, testing, dependency updates, observability and support.
A comparison that survives the demo
Record the constraints before selecting the tool.
Evaluate every serious candidate against these six questions. Where approaches are combined, make the handoffs part of the acceptance scope.
| Decision area | Record | Exercise | Review with | Unresolved when |
|---|---|---|---|---|
| Workflow fit | Normal task and exceptions | Complete a real case | Process owner | Manual repair is omitted |
| Data authority | Record and field ownership | Correction and duplicate delivery | System owners | Two systems can disagree silently |
| Access and experience | Roles, devices and task needs | Denied access and keyboard use | Relevant reviewers | Only an administrator has tried it |
| Operating limits | Usage model and service constraints | Peak load and interrupted work | Technical owner | Daily allowances stand in for load tests |
| Lifecycle cost | Same scope and comparison period | Growth and maintenance scenarios | Budget and delivery owners | Only initial development is counted |
| Exit and continuity | Data, rules, code and runtime needs | Restore or migrate a representative slice | Application owner | An export button is the only evidence |
A practical selection method
Test the awkward part early.
The differentiating evidence often comes from an exception, integration failure or later change rather than the first screen.
- 01
Map the work and existing capability
Identify the task, systems of record, real exceptions and current manual work. Check supported configuration before assuming another application is required.
- 02
Draw the proposed boundaries
Assign each screen, rule and handoff to a candidate component. In a hybrid design, keep the eligibility rule in one authoritative place and define what happens if that component is unavailable.
- 03
Exercise a representative slice
Use suitable test data to run the normal case, a difficult exception, a denied action and a failed handoff. Include the people who will use and support the workflow.
- 04
Compare operation and change
Estimate licenses, usage, configuration or development, integration, testing, support, training and migration over the same period. Record assumptions and test a plausible increase in users or activity.
- 05
Choose with conditions
Record the accepted design, remaining constraints and owner. Define what would trigger reassessment, such as unsupported rules, operating limits or a material change in cost. Preserve the trial's checks for delivery.
Keep the choice supportable
The platform does not remove application ownership.
These are evaluation controls for all four approaches, not claims that any category is inherently safer or easier to operate.
- Count real activity
- Model the actions needed for a task, including retries and pagination where applicable. Microsoft documents that these count for Power Automate request consumption, and that daily allocations coexist with other service-protection limits. Check the exact product and license rather than copying a generic capacity number.
- Keep releases and recovery explicit
- Identify development, testing and production boundaries, release approval and recovery procedures. Microsoft's reliability guidance describes the operating complexity and security tradeoffs that additional reliability components can introduce. A low-code application still needs an agreed recovery approach.
- Test what can leave
- Separate data export, application definition, editable source and a runnable deployment. Mendix documents app packages for backup or sharing and reimport into an app. That export description alone does not establish independent execution. Rehearse the intended exit and record the required runtime, rights and reconstruction work.
- Avoid duplicated business rules
- If a queue calls a custom eligibility service, define which component decides and which displays the result. Keep rule versions and correction behavior clear. A hybrid approach loses its value when several layers independently interpret the same policy.
Buyer questions
Choose from evidence about your workflow.
The category name is a starting point for investigation, not an answer about cost or suitability.
- Is low-code cheaper than custom software?
- It depends on fit and the comparison period. Evaluate the same accepted workflow, users and operating needs. Include platform charges, integration, extensions, testing, support and exit work alongside development effort. A lower initial build estimate is not a complete ownership comparison.
- When is configuration enough?
- When supported settings cover the required task and exceptions with acceptable operation and user experience. Demonstrate the complete process and disclose manual work. Customizing a familiar product beyond its supported behavior can create a different maintenance problem.
- Can low-code and custom development work together?
- Yes. A platform application can provide a staff workflow while a defined interface calls custom behavior. Verify the particular platform's extension and integration support, keep rule authority explicit and test failures across the boundary.
- Does owning source code eliminate vendor lock-in?
- No. Code can still depend on a runtime, managed service, proprietary interface or specialist knowledge. Inspect rights and dependencies, then test the actual handover or migration you need. Exporting data, exporting a project and operating it elsewhere are separate capabilities.
- What should a proof of concept include?
- A normal case, a difficult exception, realistic permissions and an interrupted integration. Include representative usage and a later change or restore exercise. Record limitations so that a successful demonstration is not treated as production readiness.
Source basis
Sources behind the control model.
- 01
GOV.UK Service Manual
Choose the right tools and technologyJanuary 2026 guidance supports build-or-buy evidence, ownership cost, future choice and legacy dependency review. Government context, used here as evaluation principles.
- 02
Microsoft Learn
Power Platform Well-ArchitectedArchitecture framework for platform workloads. Its pillars are design responsibilities, not automatic application outcomes.
- 03
Microsoft Learn
Requests limits and allocationsRequest definitions and limits sections distinguish consumed actions, license allocations and additional service-protection constraints. No numerical entitlement is reproduced.
- 04
Microsoft Learn
Reliability tradeoffs for Power Platform workloadsExplains reliability decisions across security, operations, experience and performance. Used to challenge the assumption that platform development removes operational design.
- 05
Mendix Documentation
Export App PackageStudio Pro 10 documentation reviewed for package types and optional data export. Backup and sharing capabilities do not by themselves prove an independently runnable exit.
Start with one real workflow
A Systems Audit is the usual starting point. If the opportunity is already clear, we can move directly into a focused build.
Show Us the WorkflowStart with the free automation readiness checklistOBSERVEQUANTIFYDECIDEBUILD