No-code software application development is a paradigm shift sweeping the technology world. The research firm Gartner estimates that by 2025 around 70% of new applications created by enterprises will use low-code or no-code technologies (compared to just under 25% in 2020).
These figures are drawn from enterprises in high income countries. What does the picture look like in the international development sector? In this post I explore the implications this shift has for governments and other development agencies in low and middle income countries.
What is no-code?
Wikipedia offers this definition for no-code:
No-code development platforms allow programmers and non-programmers to create applications through graphical user interfaces and configuration instead of traditional computer programming.
The article touches on the difference between no-code (which often include pre-built templates that require no code writing at all) and low-code (which often use standardised configuration files that enable you to easily modify an application). In reality this is often more of a continuum, with graphical tools that enable you to do simple tasks and the option to add in code to do more complex things.
There are many different no-code and low-code platforms available, with new ones emerging all the time. They may focus on specific use cases such as building websites, to creating mobile apps to automating back-office processes (like time sheets, expenses and leave requests). At Kwantu we’re working on a platform to enable government to create applications to monitor the delivery of large public programmes.
What are the benefits of no-code?
Research and case studies identify four consistent benefits for no-code.
Benefit 1: Faster
No-code is typically at least twice as fast as traditional development. One brief example from our work: At the height of the COVID pandemic, Kwantu was asked by the Free State Department of Small Business Development, Tourism and Environmental Affairs (DESTEA) to help them create a digital grant application system to support small businesses. Using our low-code platform the entire process from design to configuration to testing and rollout to users took only six weeks.
Having created that system, cloning it and adapting it to cover additional grant programmes (for DESTEA and other parts of government) then took only a few days. These time savings will grow as more customisable ‘templates’ are created that respond to common use cases.
Benefit 2: Cheaper
No-code can cut the cost of development by up to 80%. It avoids the needs for software developers (who tend to be expensive) and takes less time, which in turn saves money. However, there are further savings to consider during maintenance. Simple (but important) changes to an application (such as small tweaks to forms and permissions) can now easily be done in-house by existing staff. This avoids the need for an expensive maintenance contract.
Benefit 3: More scalable
With no-code any prototype built for demonstration purposes is already scalable. Further, no-code platforms typically include tools to deploy new applications quickly to a wide range of users.
In a recent project in Malawi we were asked by the World Bank to create a prototype application to track infrastructure projects implemented by local government. This was further refined in a series of workshops with the government agency responsible for this area. Once finalised and tested the prototype can be deployed immediately to all 28 district councils with confidence that the infrastructure is in place to operate at national scale.
Benefit 4: Shared Platform Services
Cloud based no-code platforms enable different applications to use a common architecture for back-up, security, deployment, payments, messaging and other core services. This has enormous efficiency savings.
If your application needs to use SMS to communicate, simply use the SMS module to integrate with the approved gateway provider. If you need to make payments, use the payments module that is already connected to a payment provider. In both cases the organisation operating the platform can procure one provider for each of these areas that are then used by multiple different applications.
What are Benefits for LMIC Governments?
As no-code matures we will see a shift to applications that can be quickly and easily assembled by the teams that will use and manage them. They will draw on common templates and building blocks (already tried and tested by others) that can be modified to meet their needs. This has enormous implications for low and middle income governments.
Benefit 1: Reducing design-reality gap
Were you aware that around 85% of government technology projects fail to meet their objectives? Research from the University of Manchester, suggests that “a key factor is the level of difference between the current reality and the model/conception and assumptions built into the project’s design. The larger this design-reality gap, the greater the risk of failure, conversely, the smaller the gap, the greater the chance of success”.
In my experience this design-reality gap is exacerbated when the people that will use the technology are not sufficiently involved in it’s design, creation and testing. No-code can help overcome the dis-connect. People can see what is being built by IT teams in real time, ensuring that nothing gets lost in translation. If they are confident enough, they can also get involved in making changes that refine an application, ensuring it really meets their needs.
Benefit 2: Addressing software skills shortage
Governments largely lack the skills to develop new applications in-house and are overly reliant on outsourcing. This problem is not unique to LMIC’s. The UK parliament found that government has “failed to develop a modern professional approach to IT operations needed to support business change and transformation and have created an over-reliance on outsourcing”
But what if existing IT teams and other skilled individuals in government could play a bigger role?
Gartner describes this opportunity as ‘harnessing the power of business technologists’. Their research finds that 41% of employees already identify as business technologists, meaning they report outside of IT departments and create technology or analytics capabilities for internal or external business use.
This in turn can accelerate digital transformation. The same Gartner research found that:
Organizations that successfully enable business technologists are 2.6 times more likely to accelerate digital business outcomes than organizations that do not empower business technologists.
Benefit 3: Lower Maintenance Costs
There is clearly a lot more to creating a well-designed application than a no-code platform. Thinking through how to architect and design an application is a skill in and of itself. In my view the most likely starting point for government is to contract out the creation of new applications, but bring maintenance in-house.
Maintenance is a major cost driver. The annual cost is often in the region of a quarter of the cost of application development.
This covers things like server maintenance and security updates, which in a no-code context are now centralised for all applications. It also covers small changes to forms, roles, permissions and other application logic as the business needs change. These are now simple tasks that internal IT teams can do without the need for an expensive maintenance contract.
Benefit 4: Shared libraries of interoperable template apps
The 80:20 rule applies well to government applications. That is to say that 80% of the requirements are typically the same, while 20% vary from one programme or department to another. This means that once an application has been created that serves one programme, it is much easier and faster to adapt it to serve another programme.
The implication for ‘business technologists’ in government is the creation of shared libraries of applications that they can draw on as a template to adapt and customise to serve their own needs. This avoids the need to design an application from scratch. It also ensures that similar design patterns are employed across government.
At Kwantu we see this going one step further to create shared libraries of data objects. Think of data objects as the data building blocks for applications. They represent the data model for concepts like a person that participates in a programme, a project description, a project budget and so on.
If a core library of data objects are created and curated centrally in government – prioritising areas where interoperability is needed – these can then be incorporated in applications. This in turn bakes in standard data definitions from the beginning, making it easier to answer questions like ‘How many climate change projects are we implementing and what is our current spend on these projects?’
When will No-Code become a reality?
There are many no-code platforms available now. However, they are mostly designed for environments where reliable Internet and electricity are assumed. At Kwantu we’ve taken an offline and mobile first approach to no-code. This ensures that any application created works by default offline and on a wide range of mobile devices. This open source platform has been widely used to create management information systems for cash transfer and citizen engagement programmes.
As demand grows we will no doubt see a range of other options emerge focusing on different use cases.
By Rob Worthington, Senior Business Analyst at Kwantu
Thanks for the overview of some of the benefits of no/low-code platforms and the effort of positioning them as a tool for LMIC government systems. While I subscribe to many of the cited benefits, I would have liked to see a more balanced article that also talks about some of the drawbacks.
Just to pick on two of the mentioned benefits: the “design-reality gap” and “software skills shortage”.
The design-reality gap is not a fault of “full-code” platforms. it’s a fault of a bad design process. The author addresses the “translation challenge”, the transformation of client intentions into a software product. If the intentions are not captured and continuously refined (which is part of the design process), no-code won’t make a difference, even if it tremendously facilitates scrutinizing the “creation process” (assuming that “under the hood” things really work as specified on the no/low-code layer).
Regarding software skills, no doubt I can create a tool for my team, program, department, etc., but creating something that integrates into a complex digital systems landscape and that can be maintained over a longer time frame is a different ballgame and requires software architecture, interoperability/integration skills and more.
While there are many ifs and buts to my points, what I’m trying to get across here is that yes, no/low-code platforms are great for some use cases. They are not so great for others. And looking at potential challenges/downsides doesn’t diminish the potential of no/low-code. It avoids creating false expectations among a less technical audience that this blog also caters to.
May I comment on your statement “that yes, no/low-code platforms are great for some use cases. They are not so great for others”.
I think you might be missing the central point here, at least in the way that we understand the low/no code environment. Low code is an abstraction rooted in a context. Attempts to stretch it beyond that context are bound to fail. At Kwantu we are focusing on a specific set of use cases, and given our deep knowledge of those, have been able to build a platform that have all the building blocks that you need for that context. For example, if you manage a large programme (or similar distributed activities of any kind), and you need forms to collect data, and workflows to manage the processes securely. Particularly if these processes are distributed widely from end users with simple mobile devices tracking day to day activities, right to a backend where these activities result in secure approval processes and payments into their bank accounts, what we have works exceptionally well. Trying to use this to build enterprise accounting systems we would never do. Its not the right context.
In our view, the strength of the Kwantu platform over many of the the no-code systems around is exactly this domain specificity. The more generic it becomes, trying to cover more contexts, the more complex it becomes. We anticipate that domain specific no-code platforms will keep growing in importance, particularly if the messaging backends to integrate with other contexts develop further. Our experience is that the “complex digital systems landscape” and integration with it is actually much simpler that what you realize, if you see that very systems architecture of the of the no code platform was designed with that very integration in mind. Whether it is a banking platform, a central government registry of citizens, or a secondary projects system in use somewhere.
Hi Willem,
I agree with almost everything you said, and my point was that I would’ve liked it if some of these considerations were part of the article.
To your last paragraph, and the question how well requirements, including around integration, can be supported, I agree that complexity can and should be managed, and that the proverbial “80%” and some of the last “20%” can often be built nicely in no-/low-code. In practice, I have seen that at some point the client wants to tackle the last 20%, which can get very complex (or, the system/requirements evolve and additional complexity is introduced). I’m sure you are familiar with these challenges and how to address them, but in an article for a less-expert audience I’d like to have seen a more balanced discussion to not create wrong expectations about capabilities and limitations of no-/low-code. Alternatively, the article could have been explicitly written about kwantu and the scenarios it targets.
Dear Heiko,
You are very right to consider the drawbacks as well. Technology is rarely simple and almost never a solution on it’s own.
That said, this is an emerging area where we are still experimenting and learning. Most of the no-code tools I’ve come across are fairly simple in nature (building a survey or making it easier to work with a database in a collaborative way). As such it’s much easier to try and predict some of the benefits at this stage!
There are relatively few examples of complex systems being created using no-code technology yet which are used at ‘enterprise’ scale. I think the drawbacks will become clearer as we see adoption grow.
I disagree with you to an extent on the translation challenge. While the challenge of moving from idea to software remains the same, no-code makes it easier to adapt software that is demonstrated to that requirement well in one area to meet it in another area. Further, it can do this in a much more iterative way that involves the end user.
In relation to maintenance, I see several layers to that in my work. The first and simplest layer is making small adjustments to a system based on user feedback. In my experience these are typically very basic things like changing the wording of a question, modifying a dashboard or changing user access permissions.
While these type of maintenance still needs to follow a robust change management and testing process, they are much simpler than (for example) integration with a new system.
The most obvious drawback I can see is that of managing platform design patterns that are generic enough to meet a wide range of needs, yet still specific enough to provide a high quality user experience. I think the work of the UK Government Design Service is very instructive in this area.
I will share more learning as we make progress in this area.
Dear Rob,
Thanks for your answer. I agree that no-code can make it easier to adapt, adjust, iterate faster, and involve the end user more. I still think it requires a strong design process (as it is easier to build/test/evaluate things, including by the end-user themselves, it’s also easier now to make the system worse), and if a system is built for beneficiaries that are not involved in this process, the design-reality gap might still exist (just by introducing no-/low-code, a person’s/team’s practices don’t automatically get human-centered, etc.
I’m excited to hear more news and learnings about Kwantu!