For many years 'no code' and 'low code' have been pitched as the answer to the integration problem. The promise has been simple: no developers, no code, just draw a few arrows between systems and everything is solved. Read on to see why 'much code' is a better option.
For many years "no code" and "low code" have been pitched as the answer to the integration problem. The promise has been simple: no developers, no code, just draw a few arrows between the systems and everything is solved. Nice.
It sounds tempting. But it builds on a shaky conclusion: that integrations are transport stretches where the shortest route is the best route. That is not how it is.
Integrations are not just arrows between systems. They are the place where business logic, data quality, responsibility and customer experience meet. That is where an order flow becomes robust or fragile. Where product data becomes comprehensible or misleading. Where stock status, prices, customer data, payments, returns and campaigns either hang together or slowly begin to fall apart.
In other words: much of a company's own digital value sits in the glue between the systems.
No code and low code often work well when the problem is simple, standardised and relatively static. "When something happens in system A, send something to system B." That kind of flow is easy to demonstrate, easy to sell and easy to understand.
But real-world integrations are rarely that simple. In practice, integrations need to handle errors that only happen sometimes, they need access to history and other data for troubleshooting. They also need to be able to express exactly the logic that makes a company unique.
This is where no code often becomes a dead end. First it goes fast. Then come the edge cases. Then come the workarounds. Then in the end no one really understands why the flow behaves the way it does. And then you have not escaped complexity. You have just moved it from code to a visual tool where it is harder to test, version, troubleshoot and develop further.
I do not love articles that are ecstatic about all the possibilities with AI, but regardless of what development lies ahead, you cannot ignore that the technology we have available here and now changes what is possible, and perhaps above all what is reasonable, when it comes to code.
The strongest argument for low code has traditionally been that code is expensive. It requires developers, time, structure and maintenance. But that equation looks different today.
When AI makes it faster and cheaper to write, understand, test and develop code further, the question becomes different. It is no longer about "code or no code". It is about what kind of code base you want to own. Do you want to own integration logic that is clear, testable, version-controlled and can be adapted to your needs when they arise?
Or do you want to own a collection of visual flows in a tool where business-critical logic is spread across clicks, rules and configuration?
AI does not put developers out of work (I think it is rather the opposite). But AI makes it more reasonable to choose real code even in areas where people used to try to avoid it. Especially when the area is strategically important.
A modern e-commerce company often consists of many systems: e-commerce platform, ERP, PIM, OMS, WMS, CRM, POS, payment, shipping, marketing automation, BI and external vendor flows.
Each system has its own view of reality. A product is not exactly the same thing in the PIM as in the ERP. An order is not exactly the same thing in the e-commerce as in the warehouse system. A customer profile is not exactly the same thing in CRM as in checkout. And so on.
The integration's job is therefore not just to move data. It has to translate meaning. What does "available stock" mean? Which system owns the truth about price? When should an order be considered ready for fulfilment? What do we do if one system accepts an update but the next rejects it? Which representation of the product should apply in which channel?
This is where the value is created. And this is where you need precision, clarity and choice.
This article can of course be read as a covert ad for our integration platform Nexus, but since we give Nexus for free to our clients, it is more a slightly smug "what did I tell you?" article. But a bit of an ad it is, of course, this is our blog and our integration platform, so why not.
Nexus is built on the philosophy of "much code" rather than anything else. Nexus is the developer's best friend when it comes to integrations, letting you focus on what is important without having to think about error handling, retries, traceability and so on.
That does not mean code for the sake of code. It means that integration logic deserves to be treated as real software. When something goes wrong you should be able to see what happened. When a flow needs to change you should be able to change it in a controlled way. When the business grows the integration layer should be able to grow with it.
One of the most common weaknesses in integration solutions is not that they lack features. It is that no one really knows what is happening when they run.
Nexus therefore focuses on visibility: queues, logs, failed messages, retries, health checks and clear monitoring. Nexus is a cornerstone at many of the Nordics' larger e-commerce companies, including Lyko, Cervera, Kjell & Company, Thule, Lekia, Nordic Nest, Ark, Hatstore, and others.
It is no coincidence. The more business-critical the flows become, the more important it becomes to be able to understand them.
An integration that works 99 percent of the time but is impossible to troubleshoot the last percent is not robust. It is just quiet until it becomes expensive.
There is also a more forward-looking point: AI works best when it can work with clear components.
Code is such a component. It can be read, refactored, tested, compared in PRs and documented. AI can help write new features, create tests, analyse errors, propose improvements and explain existing logic.
A low-code flow is often harder. It can be visual, proprietary and fragmented. It can be hard to export, hard to test and hard for AI to reason about in the same way as a normal code base. The more AI becomes a natural part of development, the more valuable it becomes to have your critical integrations in a form AI can actually help develop further.
The conclusion is simple: own the glue
Companies should not put all their energy into avoiding code. They should put energy into owning the right code. AI makes it possible for companies to produce code at a furious pace. And the amount of code being produced will in all likelihood grow dramatically. But you still have to choose which code you actually want to own, because it is not free to own code.
Integrations are not peripheral. They are often entirely central in a modern e-commerce company. They determine how well data flows, how accurate information is in each system, and how quickly the business can change when the commerce demands it.
No code and low code can absolutely have their place. But when the integration layer becomes strategic, complex and business-critical, it is the wrong path to try to hide the logic behind clickable flows.
The future is better code, made faster, more clearly monitored and closer to the business.
That is why we believe in "much code". And that is why Nexus exists.
Related articles
AI makes it possible to produce code faster than ever, but more code does not automatically mean more value. What AI really does is amplify the skill and judgement already present in the person or team using it. That makes the ability to understand the problem, spot risks and know what not to build more important than ever.
Technical debt is more than a technical concept, it is a business-critical reality that affects everything from time-to-market to customer experience. In e-commerce, where every millisecond and every click counts, the choices you make in your technical platform can have far-reaching consequences. When quick fixes are prioritised over long-term durability, an invisible but growing debt is built up. It affects not only development speed and stability, but at worst can slow the company's ability to innovate and compete. To face the future the right way, technical debt has to be understood, quantified and managed as the strategic investment it actually is.
Price changes in e-commerce are often planned in advance and scheduled: either a change to the list price or a campaign price that takes effect on a specific date. Getting every system to show the new price at the right moment is a harder challenge than you might think, and in this article we walk through how to solve it with Nexus.
