Six weeks after a sales team received their Power Apps licences, the sole IT contact at an Ankara-based insurance intermediary with 295 employees found 14 new application requests waiting on his desk. Nine of them wanted connections to company data sources. Three were requesting access to policy profitability figures that had previously been visible only to senior sales managers. Nothing had been breached. Nobody acted with bad intent. The problem was something more fundamental: buying a low-code platform is not the same as managing one.The citizen developer movement has been a fixture in enterprise technology discussions since 2018. The premise is straightforward: a sales manager, logistics planner, or HR specialist who cannot write code can build their own business applications using drag-and-drop low-code tools. Microsoft Power Platform, Mendix, and OutSystems have brought this movement to enterprise scale. The logic is clear — shorten the IT backlog, give business units autonomy, grow digital capabilities from the edges rather than the centre. The problem is not that this idea is wrong. The problem is that most organisations adopt the platform without ever building the governance framework that makes it safe.In Turkey, the KOBİ (SME) reality adds a particular dynamic. IT departments either do not exist or consist of one or two people. Software expenditures are denominated in foreign currency, and in the inflationary environment of early 2022, that cost is being recalculated nearly every quarter. Custom application development is expensive. Customised ERP modules take four to six months to deliver. Under these constraints, the idea of letting a sales manager build their own tool looks not just attractive but necessary. That pragmatism, however, does not eliminate the obligation to pair the platform licence with a governance structure. If anything, organisations with limited IT capacity face a more dangerous governance gap: when problems compound, there is no team large enough to untangle them quickly.Shadow IT — software and systems used outside IT department knowledge or approval — has been a chronic enterprise security problem since the mid-2000s. Files uploaded to personal cloud storage, customer data shared via messaging apps, commercial offers built on personal spreadsheets emailed to clients. Did low-code platforms solve this? No. The institutional licence created a feeling of legitimacy while the same risk continued under a different name. The distinction matters: old shadow IT was invisible, running entirely outside corporate infrastructure. The new version runs on the company’s own licensed platform and therefore appears sanctioned. Appearing sanctioned is not the same as being governed.There is a real counterpoint worth acknowledging here, and it belongs in the middle of this argument rather than at the end. In environments where data boundaries were defined in advance and application approval steps were built into the workflow, low-code genuinely delivered. A representative case from a mid-scale machine manufacturing facility in Gaziantep: the production planning team built a shift-tracking application in 11 days using a low-code tool, bypassing an ERP customisation queue that would have meant a four-to-five-month project timeline and a budget the facility did not have. The benefit was real and measurable. But the conditions that made it work included pre-defined data access rules, a mandatory BT sign-off before the application went live, and a named application owner in a central log. Remove those conditions and the same process delivers a different result.Three failure points appear consistently in low-code adoption patterns in Turkey right now. The first is ambiguous data access boundaries. It is reasonable for a sales specialist to access their team’s pipeline data. It is not reasonable for them to access the company’s full pricing parameters or competitive bid history. But low-code platforms do not configure these boundaries by default. Users connect to whatever data source the connection wizard shows them. In the Ankara insurance case, claims processing data and policy profitability data shared the same API connection layer, with no permission gate between them.The second failure point is application lifecycle orphaning. A citizen developer builds an application, it runs for a few months, then that person moves to a different role or leaves the company. The application keeps running with no owner. Who will update it? Who will troubleshoot it? Who will decommission it? In sectors where Turkish employee turnover is high — retail, call centres, logistics — the stack of ownerless applications grows quickly. When a platform administrator eventually audits, a significant share of active applications have never been formally closed down. This is not a number I can cite from a published study; it is a pattern that appears consistently across field observations, and I flag it as such.The third failure point is KVKK compliance blindness. When a workflow containing personal data migrates into a citizen developer’s application, the fact that it falls under KVKK obligations is rarely recognised by the person building it. Data processing records go unupdated. Clarification texts are not revised. Data transfer security is not checked. Because IT is outside the loop, these controls do not run. As of 2022, KVKK audits are becoming more sector-specific and more consequential. This blind spot is not a future risk — it is an active one.Three actionable steps for Monday morning. First, produce a data classification and access map: document who can connect to which data source under what conditions. Without this document, granting low-code licences is equivalent to distributing warehouse keys without organising the warehouse. Second, build an application approval layer: any application heading toward production must pass at minimum two checks — data access appropriateness and a KVKK scope assessment. This does not require a complex process; a structured form of 12 to 15 questions and 30 minutes of IT review time is sufficient for most SME contexts. Third, maintain an ownership register: every application needs a named owner, logged centrally and kept current. When that person leaves the company, the application either transfers to a new owner or is decommissioned. No third option.Back in Ankara, the insurance firm’s IT contact approved 6 of those 14 applications, revised 5 with data access restrictions, and closed 3. The entire process took 3 weeks. The actual time cost was not the review itself — it was the governance work that should have been done before the first licence was issued. Low-code speed is real and the value it creates is genuine. But that speed is only sustainable when the organisation knows which data cannot be touched by whom, and has written that knowledge into a framework that runs before the first application goes live. Without that, the platform does not liberate citizen developers. It just licenses the chaos. How many ownerless low-code applications are running in your organisation right now? If you do not know the answer, that is where to begin.
This article was originally published in Turkish by Gökhan MERCANOĞLU on March 14, 2022. The English edition has been reviewed and edited by the author.