An operations manager at a retail chain in Istanbul submits a request to IT for a better store-level inventory tracking tool. The request sits in a queue behind dozens of other projects for three months. Impatient, the manager builds the solution herself on a no-code platform and has it running within two weeks. What looks like a success story carries a different meaning for the company’s IT manager: Which data is being accessed? Is there a backup? What happens to this application if the manager leaves? The speed that no-code tools give business units is real. But when that speed grows without institutional control mechanisms, it creates problems larger than the ones it solves. The issue is not about restricting business units; it is about clearly defining the boundaries within which they are free to act.
No-code platforms allow users to build applications through visual interfaces without writing code. Forms, workflows, simple databases, notification systems, and reporting dashboards can be set up in hours. In Turkey, corporate interest in these platforms grew noticeably through 2018 and into 2019; in an environment where currency pressure was squeezing software budgets, the desire of business units to produce their own solutions intensified. But the ease the platform offers is also the source of the governance problem. Applications that IT has not approved, that are not integrated into the data architecture, and that have not passed security review multiply across the corporate environment. This brings back the ‘shadow IT’ problem that organisations spent years fighting, now in a different form. No-code tools do not eliminate that problem; they simply lower the access threshold.
What organisations need here is not a ban but a classification framework. Dividing applications into tiers based on their criticality level opens a meaningful space of freedom for business units while keeping institutional risks manageable. The first tier covers personal productivity tools used by a single person or a small team, with no direct connection to corporate systems and no customer or financial data. In this tier, the business unit can be fully autonomous; IT approval is not required. The second tier covers applications that affect more than one department, use shared data, or require process integration. Here the business unit can develop, but within IT-approved templates and through defined checkpoints. The third tier covers critical applications involving financial transactions, customer personal data, or legal reporting. In this tier, development authority stays with IT; the business unit is only the requirements owner.
For a tiered authority model to work, the classification must be written down and understandable to everyone. In many Turkish organisations, frameworks like this either do not exist or remain buried in IT’s internal documents, leaving business units unsure what is permitted and what is not. The result: either everything goes to IT and slows down, or nothing goes to IT and risks accumulate. A well-designed authority model should include a criticality questionnaire the business unit can complete in five to ten minutes before starting development. Questions such as ‘Will this application process personal data under KVKK scope?’, ‘Will it exchange data with the ERP or accounting system?’, and ‘Will more than one department depend on this application?’ place the application in the right tier and activate the appropriate oversight mechanism before the project begins. Since KVKK came into force in 2018, bypassing the personal data question in any application is now a legal risk, not just an operational one.
For the authority model to be sustainable, the technical infrastructure must be built to match. How the no-code platforms open to business units integrate with the corporate IT environment, which data sources they can access, and which authentication mechanisms they use must all be defined in advance. A common problem in mid-sized Turkish companies runs like this: a platform is purchased, a few pilots are built, then business units start growing on their own. Six months later, IT does not know which applications are running where or what data they touch. Walking back at that point, decommissioning or restructuring working applications, costs far more than establishing proper governance from the start. The platform’s central management panel, application inventory, and access logs are therefore not optional features; they are operational necessities.
There is also a cultural dimension. When business units see IT as a speed-reducing obstacle, they use no-code tools precisely to bypass that obstacle. When IT sees business units as uncontrolled sources of risk, it tries to centralise every request under tight oversight. When these two perspectives clash, the potential value that no-code platforms bring is lost beneath institutional friction. The solution is to build a shared language: the business unit defines what problem it wants to solve; IT defines under what conditions that solution can be supported. Some Turkish holding companies are running this process through a ‘digital product team’ model, where small teams combining IT and business unit representatives keep no-code development both fast and controlled. This structure is not perfect; it requires resources and carries coordination costs. But the alternative, uncontrolled growth, eventually produces an application sprawl that becomes a burden for the entire organisation.
No-code tools open a real space of freedom for business units, but the boundaries of that freedom must be drawn by the organisation itself. Application criticality classification, a tiered authority model, and a centralised application inventory: without all three in place, no-code adoption does not produce institutional value; it produces a new wave of shadow IT. In Turkey’s 2019 reality, where business units are chasing speed under budget pressure and IT departments are struggling with limited resources, the tension between the two can be turned into a workable collaboration with the right governance framework. The starting point is straightforward: write down, in language everyone can understand, which applications can be built by whom and under what conditions.
This article was originally written in Turkish by Gökhan MERCANOĞLU on April 8, 2019 and has been automatically translated into English and other languages using machine translation.