‘Buy a low-code platform, let your business unit experts build their own apps, and watch the pressure on IT disappear.’ That pitch travels fast through vendor presentations. By early 2021, dozens of Turkish companies had put it to the test. Some found what they were looking for. The majority ran into something different: applications built entirely by business unit staff that quietly fell apart — integrations broken, data inconsistencies accumulating, KVKK compliance gaps quietly widening. IT departments, rather than getting relief, spent months on cleanup projects for code they had never reviewed. Low-code’s real value does not live in making business units independent from IT. It lives in putting a business unit expert and a software developer on the same platform, inside the same delivery cycle, building together. That model is commonly called a fusion team, and in enterprise low-code adoption it is the single variable that most reliably separates working outcomes from expensive regrets.A machine manufacturing firm in Konya with 372 employees makes this concrete. Their ERP system’s standard modules were not covering the purchase request and production order approval workflow. That flow lived outside the system entirely — spread across Excel files and WhatsApp threads. The production manager put it plainly: ‘information doesn’t reach the right place on time.’ A low-code platform was purchased, the most process-literate person available — the procurement coordinator — received training, and the build was handed over. Fourteen weeks later a working approval flow existed. But it spoke to nothing else in the technology stack. It did not connect to the ERP. Data entry was still manual. Role-based access was undefined. Supplier data stored on the platform had no documented handling procedure for KVKK compliance. When IT eventually stepped in, they were inheriting an undocumented structure someone else had built, without design records or test cases. This was not a low-code failure. It was a fusion team failure.The fusion team model does not make the business unit the sole owner of the platform. What it does instead is define, up front, which role is responsible for what. The business unit expert holds the process knowledge: which condition triggers an approval, what constitutes an exception, what sequence of screens a user should see and why. They use the platform’s visual tools to translate that knowledge directly into application logic. The professional developer does not touch process decisions. Their scope covers technical architecture: the ERP integration layer, authentication and authorisation, error handling, data residency. Both roles work inside the same sprint cycle. The business unit expert drafts a flow, the developer adds the technical scaffolding, both review together and advance to the next iteration. This cycle sustained itself even through the shift to remote work that defined much of 2020 and carried into 2021. Teams that had documented role boundaries before the pandemic transitioned more smoothly, because the model did not depend on people being in the same room.Quality assurance is the most consistently underbuilt layer in this model. When the framing is ‘business unit builds, developer supports,’ testing falls into a gap. The business unit expert validates functional behaviour from their perspective. The developer checks technical components. But integration points, edge cases, and end-to-end scenario tests between the two layers go untested. In the Konya firm’s first attempt, that is precisely what happened: the approval flow worked in isolation and the ERP order record worked in isolation, but no one had run them together. Preventing this requires the fusion team model to define shared quality ownership explicitly. For every application component, the question ‘who is responsible for this?’ needs a named answer. Authorisation logic and KVKK data handling belong to the developer. Process correctness belongs to the business unit expert. End-to-end scenario testing is a joint task — it cannot be delegated to either side alone. Teams that skip this step typically discover the gap at the worst possible moment: during a production incident, not during review.Shared ownership does not end at deployment. A pattern visible across Turkish SME environments: the business unit expert builds the application, it runs for several months, then that person moves to a different role or leaves the organisation. No documentation exists, no named successor was assigned, and the platform license keeps renewing while the application slowly becomes a liability. This ‘orphaned application’ problem is not unique to low-code, but it appears faster and more frequently in low-code environments precisely because the low entry threshold means more applications get built more quickly. The structural answer is to assign every application a minimum of two owners at creation: one from the business unit, one from the technical side. That ownership pair reviews the application every six months, tests its alignment with the current process, and decides whether an update is needed. In manufacturing and supply chain contexts — where applications may be handling live production data, supplier records, or approval chains tied to purchasing commitments — this discipline is not optional.There are genuine conditions under which this model does not work, and naming them matters. Fusion team requires that both parties have enough time and commitment to collaborate regularly. When developer capacity is constrained and existing project queues are already full, business unit requests for fusion team cycles lose priority and the model collapses into the unstructured pattern it was meant to replace. In Turkey’s 2021 context, cloud-based low-code platform licensing was priced in foreign currency; for SMEs already under significant exchange rate and inflation pressure, that cost was a real barrier to scaling the model across multiple departments simultaneously. Additionally, the model assumes that the business unit expert can articulate their process clearly enough to build against. Experts who cannot define their own process logic do not produce better input on a low-code platform than they would in a traditional requirements document — they just produce it faster and with less oversight. Where these conditions are absent, low-code adds another unused software license to the balance sheet.The Konya manufacturer eventually rebuilt correctly. The procurement coordinator and a developer were placed inside a shared sprint cycle. The developer built the ERP integration layer and handled access controls; the coordinator built the approval logic. Unlike the first fourteen-week attempt, this one delivered a live, ERP-synchronised approval workflow with defined role permissions in nine weeks. The production manager’s complaint about information not reaching the right place dropped by 63 percent; the remaining gap traced back to structural ERP limitations, not the low-code layer. That is what the model actually delivers: reduced translation loss between business intent and technical execution, measured in outcomes, not in how many apps a business unit produced without IT involvement. The platform is the instrument. The model is the work. The question worth asking in your own organisation is whether you have built the model, or only purchased the instrument.
This article was originally published in Turkish by Gökhan MERCANOĞLU on March 15, 2021. The English edition has been reviewed and edited by the author.