Low-Code at Enterprise Scale

The Management Model Behind Sustainable Delivery

BLUF: Low-code platforms can expand delivery capacity faster than an organization can govern a growing application portfolio. Sustainable scale depends on clear decision rights and ownership. Review depth should follow consequence so governance protects enterprise interests without becoming a routine source of delay.

Practitioner Perspective: This paper incorporates practitioner perspectives gathered through structured questionnaires with Brooke Apperson, Program Manager, and David Burnham, Senior Low-Code Developer. Their observations are included throughout alongside published research.

Low-Code Changes the Management Problem

Low-code development removes some of the work that usually sits between an idea and a functioning application. Visual models, reusable components, and platform services can take the place of tasks that would otherwise require custom code. Bock and Frank (2021), Bucaioni et al. (2022), and Luo et al. (2021) associate these platforms with faster delivery, greater agility, and broader participation in application development. Their findings also reflect considerable variation among low-code technologies, along with many of the same engineering concerns found in conventional software development.

Low-code also lowers the effort required to begin application development. Business units can address local needs without waiting for a traditional development path, which allows more ideas to reach delivery. Professional developers may work alongside non-technical staff on the same effort. As citizen development expands software creation beyond formal engineering teams (Ajimati et al., 2025), governance and standardization become recurring concerns at enterprise scale (Binzer & Winkler, 2024).

Delivery speed reveals little about whether a team is building the right application, who owns the asset long-term, or how the output will be validated and sustained. Critical decisions, including whether an existing enterprise tool already satisfies the requirement, must still occur. Low-code, however, often produces a functional interface long before this fundamental governance work takes place.

AI-assisted coding introduces another source of acceleration. He et al. (2026) observed a substantial initial increase in development velocity after open-source projects adopted Cursor. That gain later flattened while static-analysis warnings and code complexity remained elevated. Martin-Lopez et al. (2026) reported a related result in a controlled experiment: developers using AI completed more than twice as much of their assigned task, while their performance on technical questions about the code they had implemented fell by 12.5%.

These studies examine AI-assisted coding. Both show implementation capacity growing faster than code understanding, review discipline, or ownership. Once software enters an enterprise portfolio, that gap becomes a sustainment problem for the teams that inherit the application.

Program Manager Brooke Apperson describes the shift from isolated low-code projects to portfolio management. At that scale, priorities and dependencies cross project boundaries. Resources and stakeholders do as well, so a decision on one effort can affect another. Managers need clearer ownership and documentation, with enough governance to coordinate the portfolio without adding process that contributes little to the decision.

Senior Low-Code Developer David Burnham sees the same shift from the delivery side. Low-code can accelerate user-interface construction, basic integrations, prototyping, and simple internal tools. Architecture and data modeling still require engineering judgment. Security, testing, performance, and lifecycle management do too. The platform changes where effort is spent, leaving much of the engineering responsibility intact.

When Delivery Outpaces Understanding

Technical debt usually describes implementation choices that make later change harder or more expensive. Storey (2026) adds two forms of debt that become especially relevant when AI participates in delivery. Cognitive debt develops as the team loses shared understanding of the code. Intent debt accumulates when project records omit the goals, constraints, and reasoning that future developers or AI systems may need.

Low-code can create similar conditions. Abstraction and automation make it possible for working software to appear before the organization has captured much of the reasoning behind it. The application may behave correctly while its business intent or design rationale becomes difficult to reconstruct. AI-assisted implementation can widen that gap by producing artifacts faster than a team can develop a shared understanding of them.

At enterprise scale, an application must carry enough contextual history to survive the departure of its original delivery team. A future maintainer (human or AI) needs a transparent path to trace the operational need through to what was accepted for use. Preserving that long-term continuity is a core responsibility of any sustainable management framework.

From Application Backlog to Portfolio

An isolated low-code project can often be managed within a single team. As adoption spreads, portfolio effects become harder to ignore. Teams may solve legitimate local problems while the enterprise accumulates duplicate workflows, fragmented data practices, redundant integrations, and applications with no clear long-term owner. Alamin et al. (2023) found recurring developer concerns around customization, data and file management, platform adoption, maintenance, and third-party integration. Low-code changes the mechanics of delivery. Those engineering concerns remain in the portfolio.

Portfolio control begins before development. Intake should collect only the information needed for a disposition: the business problem and intended outcome, plus ownership and material data or security constraints. The review then determines whether to reuse an existing capability, enhance one, build something new, or decline the request. Figure 1 places that decision before work enters the delivery pipeline.

Decision authority should be established before delivery. Brooke begins with the problem and considers reuse, enhancement, or process change before approving a new build. A designated decision-maker can weigh those options with input from technical, program, and operational staff while maintaining portfolio visibility. Routine implementation decisions remain with the delivery team. Additional review is warranted when the work introduces greater risk or creates shared dependencies.

Requirements Still Matter When Development Gets Faster

A low-code user interface can take shape before the underlying business logic is fully understood. Rapid visual feedback can help discovery, but visible progress may arrive before the team has resolved the rules behind it. A field or workflow branch may depend on an exception that never surfaced during intake. Permissions, data definitions, and external interfaces can create the same problem. A developer can configure one interpretation quickly; the team still has to determine whether that behavior matches the operational need.

GAO's Agile guidance makes the distinction more concrete. It advises programs to define acceptance criteria for each user story before development begins and to use those criteria, along with the definition of done, to determine whether the requirement has been satisfied. The guide also calls for requirements to be refined as the work evolves and for traceability to remain intact as higher-level needs are decomposed into more detailed requirements (U.S. Government Accountability Office [GAO], 2020).

Requirements readiness is part of portfolio control. Before development begins, the team needs enough clarity on business rules and known exceptions to understand the behavior being requested. Data constraints and user permissions also need to be visible. The sponsor needs a defined basis for acceptance. Requirements will change during delivery. Those changes should remain on the record, carry the appropriate approval, and reach the testing and acceptance evidence.

Requirements also retain part of the system's intent after development starts. Storey (2026) describes the risk of losing that record as intent debt. When the record weakens, later teams may have to reconstruct rationale from code, old tickets, chat threads, or someone's memory. Later decisions are safer when authoritative intent remains available.

Brooke Apperson expects Agile teams to establish a clear problem and desired outcome before sprint work begins. The definition of success should also be explicit, while smaller details can be refined during delivery. When those foundations are vague, she has seen scope growth, conflicting expectations, and rework. An application can operate as designed and still miss the customer's actual problem. Low-code shortens the time between those decisions, which can put additional pressure on sponsor review and approval.

David Burnham sees the same issue during implementation. A request for a simple approval form can expose routing rules, exception paths, audit requirements, or data dependencies that were not identified during intake. The interface may be assembled quickly even when the underlying logic remains unsettled. David uses prototypes to surface those unknowns. He then resolves the data model and business rules before production work proceeds, with acceptance defined before release.

Standards Without Excessive Review

Enterprise controls extend beyond functional requirements. Independent teams can introduce drift in security, data handling, integrations, and release practices when shared standards are unclear. Central governance should focus on the areas where inconsistency creates portfolio risk. Delivery teams can retain discretion elsewhere.

NIST's Secure Software Development Framework is useful here because it is technology-neutral. It expects security requirements to remain visible throughout the software development life cycle and to be verified at appropriate points. Those concerns do not end when the initial build is complete. NIST also calls for organizations to retain and protect release-related information needed to support later verification and maintenance. The principle applies whether an application is handwritten, generated, configured, or built on a low-code platform (Souppaya et al., 2022).

Binzer and Winkler (2024), drawing on citizen-development leaders across 16 enterprises, found that standardization emerged as a distinct phase as adoption matured. Governance continued to evolve as the initiative spread. Figure 2 translates that pattern into review depth. Bounded, low-impact work can use established patterns and a short review. Higher-consequence changes require additional oversight.

David would standardize the parts of the portfolio that cross team boundaries, including core data definitions and identity or access controls. Shared integration patterns and business rules also need enterprise treatment. Delivery teams can retain discretion over local implementation choices. This keeps common dependencies consistent without prescribing the same design for every application.

Brooke places the boundary at the decisions governance can materially improve. Review should expose dependencies and clarify ownership. It should also resolve priority or approval questions when needed. A review that seldom changes a decision or reduces risk adds delay without improving control.

Ownership Continues After Deployment

Low-code platforms can shorten the path to release, yet the resulting applications may remain in service for years. Long-term authority therefore needs to be clear from the start. Programs need to know who can change a governing business rule and who owns an integration after the original builder leaves. They also need enough traceability to connect an operational defect to the requirement the sponsor accepted. Alamin et al. (2023) identified maintenance and integration as recurring concerns in low-code developer discussions. Once released, the application becomes an operating asset with an owner responsible for its continued support.

Under this management model, sustainment ownership is established at intake and confirmed before release. The owner may delegate routine maintenance but remains accountable for the application's direction, including consolidation and retirement. Souppaya et al. (2022) recommend retaining and protecting release information needed for later verification and maintenance. The lifecycle record therefore has to remain available after the original delivery team has dispersed.

Post-deployment changes should follow the same risk logic used at intake. Routine maintenance and minor fixes can remain with the delivery team. A change that adds a data source, expands the user population, alters a governing business rule, or creates a new enterprise dependency may require portfolio review. The record should retain why the change was approved and the evidence used to accept it.

Martin-Lopez et al. (2026) raise a sustainment concern at the developer level. Participants using AI assistants showed weaker command of technical details in code they had implemented, which the authors connect to lower code ownership. Storey (2026) extends the concern to the organizational level through cognitive debt and intent debt. As those forms of debt accumulate, future maintainers may have less access to the reasoning, domain assumptions, and dependencies that shaped the system. That loss of context can make later changes more difficult to assess and sustain.

For David, safe change begins with the original business intent and a dependency map that someone else can use. A maintainer needs to know the rules and exceptions built into the application, the data it reads and writes, the systems connected to it, the users and processes affected, the tests already in place, and who has authority to approve a change. Low-code interfaces can make an application look simpler than its dependencies really are. A small edit on the screen may therefore affect far more than the component being changed.

Brooke would establish sustainment ownership before production while the delivery team is still available for handoff. Operational support requires a designated owner and an agreed support model. Documentation should be sufficient for a new maintainer to assume responsibility without reconstructing the project history. She divides accountability across five roles:

• Business Owner: Retains primary accountability for the business need, funding, and target outcomes.
• Product Owner: Directs ongoing requirements, scope prioritization, and feature roadmaps.
• Delivery Team: Constructs, tests, and validates application capabilities against defined acceptance criteria.
• Platform Team: Maintains the underlying technical environment, platform health, and shared governance standards.
• Program Office: Coordinates cross-cutting schedules, risk posture, resource allocation, dependencies, and executive communications.

Measure Portfolio Capability

Delivery metrics like velocity, cycle time, and release frequency measure execution flow within a single team, but they offer little insight into the health of an enterprise portfolio. An executive leading an enterprise low-code capability requires a higher-level governance view: whether incoming demand aligns with strategic priorities, whether active applications retain accountable owners, whether delivered solutions achieve their intended operational outcomes, and where technical or cognitive debt is making sustainment more difficult.

Recent AI research shows why delivery speed can give an incomplete view of portfolio health. He et al. (2026) observed a large initial increase in velocity after Cursor adoption. That gain faded while static-analysis warnings and code complexity remained elevated. Martin-Lopez et al. (2026) found another version of the tension: AI-assisted participants completed more work but demonstrated lower code ownership. Higher output can coexist with conditions that make later review and change more difficult.

Research does not prescribe a single dashboard for low-code portfolios. The implication is narrower: delivery velocity alone cannot show whether the capability remains healthy. Portfolio measures should reflect the organization's operating model and the decisions leaders are expected to make about the applications they fund and retain.

GAO's Agile Assessment Guide makes a similar management point. Metrics should align with organization-wide goals and support decisions. The guide distinguishes among the information needs of technical management, program management, and Agile teams (GAO, 2020). A low-code portfolio dashboard should therefore show whether work is moving for the right reasons, whether delivered applications remain useful, and where ownership or sustainment demands require attention. Table 1 offers a starting set of measures tied to those questions.

Table 1. Candidate portfolio measures for a low-code program

Brooke assesses portfolio health by whether the organization is delivering the right work and whether people use what was delivered. Adoption and customer satisfaction sit alongside requirements, schedule performance, open risks and dependencies, and work stalled while waiting for a decision. High activity can mask blocked priorities or continued investment in applications that see little use.

A Governed Path from Demand Through Sustainment

The management model depends on keeping the record connected from intake through sustainment. Intake captures the disposition and expected outcome, with an owner identified before work proceeds. Review depth increases when consequence warrants it. Figure 3 shows how approved intent and verification evidence can remain attached to the application as it moves through delivery and later change.

AI-generated implementation makes provenance more relevant. Kashif et al. (2026) found that developers who self-declare AI-generated code cite later tracking, review, and debugging as reasons to preserve that information. A portfolio can retain provenance selectively, concentrating on consequential artifacts that later reviewers may need for accountability or change analysis.

Requirements tooling can help keep that record connected. ACC3 describes Alchemist AI Pro™ as converting unstructured business concepts into development-ready specifications that can support downstream technical work (ACC3 International, n.d.). Alchemy SDLC™ carries the approved record into build and verification. Brooks (2026) describes how acceptance criteria can feed structured automated-test definitions. Preyna (2026) addresses traceability among source business artifacts, requirements, implementation code, and verification evidence. Portfolio intake, asset ownership, and acceptance authority remain enterprise decisions.

Alchemy SDLC™ carries the management model into delivery by keeping approved business intent connected to the artifacts produced during implementation. The organization still decides why an application should exist, who owns it, and what evidence is sufficient for release. Those decisions remain visible as the work moves through the SDLC.

Low-code teams may change applications quickly, so later maintainers need a usable record of what changed and why. Carrying the requirements baseline and verification evidence forward reduces reliance on old tickets, messages, or the memory of the original team. Governance establishes decision rights. The lifecycle record preserves the evidence those decisions create.

Brooke and David describe the management problem from different vantage points. Brooke looks across the portfolio at work in progress, ownership, and decision authority when priorities compete. David focuses on the delivery record, especially shared data definitions, technical rules, test evidence, and dependencies. Their concerns intersect when duplicate work appears, ownership is unclear, integrations fall outside shared architecture, or later maintainers can no longer explain system behavior.

Portfolio problems usually appear through ordinary signals: an application without a willing owner, a business rule with no clear source, a duplicate workflow, or a change that cannot be tested against the need that justified it. AI-assisted development can make those gaps less visible when implementation moves faster than understanding or when intent never reaches the record (He et al., 2026; Martin-Lopez et al., 2026; Storey, 2026). Brooke's management test is direct: can leaders explain what is being worked on, why it matters, and who is responsible? Six months after release, those answers should still be available without relying on the original builder.

Organizations preparing to expand low-code should test the management model on one bounded workflow before applying it across the portfolio. Start with a live request and trace the decision from intake through acceptance and sustainment, noting any break in ownership or decision authority and any point where evidence is lost. ACC3 International can facilitate that assessment and show how Alchemist AI Pro™ and Alchemy SDLC™ can support the resulting governance model while preserving the delivery speed that made low-code attractive.

References

ACC3 International. (n.d.). Alchemist AI Pro™. Retrieved August 8, 2026, from https://acc3int.com/alchemist

Ajimati, M. O., Carroll, N., & Maher, M. (2025). Adoption of low-code and no-code development: A systematic literature review and future research agenda. Journal of Systems and Software, 222, 112300. https://doi.org/10.1016/j.jss.2024.112300

Alamin, M. A. A., Uddin, G., Malakar, S., Afroz, S., Haider, T., & Iqbal, A. (2023). Developer discussion topics on the adoption and barriers of low code software development platforms. Empirical Software Engineering, 28, Article 4. https://doi.org/10.1007/s10664-022-10244-0

Binzer, B., & Winkler, T. J. (2024). Die vier Phasen von Citizen Development-Initiativen: Treiber, Herausforderungen und Handlungsempfehlungen [The four phases of citizen development initiatives: Drivers, challenges, and recommendations]. HMD Praxis der Wirtschaftsinformatik, 61, 1136–1158. https://doi.org/10.1365/s40702-024-01088-x

Bock, A. C., & Frank, U. (2021). Low-code platform. Business & Information Systems Engineering, 63(6), 733–740. https://doi.org/10.1007/s12599-021-00726-8

Brooks, K. (2026, July 19). From acceptance criteria to automated assurance: How the Alchemy SDLC™ feeds Playwright-enabled testing from a traceable requirements baseline. ACC3 International. https://acc3int.com/whitepapers/acceptance-criteria-to-automated-assurance/

Bucaioni, A., Cicchetti, A., & Ciccozzi, F. (2022). Modelling in low-code development: A multi-vocal systematic review. Software and Systems Modeling, 21(5), 1959–1981. https://doi.org/10.1007/s10270-021-00964-0

He, H., Miller, C., Agarwal, S., Kästner, C., & Vasilescu, B. (2026). Speed at the cost of quality: How Cursor AI increases short-term velocity and long-term complexity in open-source projects. In Proceedings of the 23rd International Conference on Mining Software Repositories (MSR ’26) (pp. 181–193). Association for Computing Machinery. https://doi.org/10.1145/3793302.3793349

Kashif, S. M., Liang, P., & Tahir, A. (2026). On developers’ self-declaration of AI-generated code: An analysis of practices. ACM Transactions on Software Engineering and Methodology, 35(7), Article 200, 1–37. https://doi.org/10.1145/3771937

Luo, Y., Liang, P., Wang, C., Shahin, M., & Zhan, J. (2021). Characteristics and challenges of low-code development: The practitioners’ perspective. In Proceedings of the 15th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM) (pp. 1–11). Association for Computing Machinery. https://doi.org/10.1145/3475716.3475782

Martin-Lopez, A., Tufano, R., Guglielmi, E., Sánchez, A. B., Sanz, A. L., Scalabrino, S., Oliveto, R., Segura, S., & Bavota, G. (2026). More code, less understanding? On the impact of AI assistants on developers’ productivity and code ownership. IEEE Transactions on Software Engineering, 52(7), 2173–2187. https://doi.org/10.1109/TSE.2026.3679627

Preyna, D. (2026, July 25). The lifecycle evidence boundary. ACC3 International. https://acc3int.com/whitepapers/lifecycle-evidence-boundary

Souppaya, M., Scarfone, K., & Dodson, D. (2022). Secure software development framework (SSDF) version 1.1: Recommendations for mitigating the risk of software vulnerabilities (NIST SP 800-218). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-218

Storey, M.A. (2026). From technical debt to cognitive and intent debt: Rethinking software health in the age of AI. Queue, 24(2). https://doi.org/10.1145/3807966

U.S. Government Accountability Office. (2020). Agile assessment guide: Best practices for Agile adoption and implementation (GAO-20-590G). https://www.gao.gov/products/gao-20-590g