Perspectives on NoCode

Last week we wrote about how three civil society organisations worked with NoCode to improve their digital services.

NoCode refers to a collection of apps which allow you to develop digital services without having to write code. Instead, you assemble it from building blocks. NoCode may lack some flexibility compared to writing code yourself, but it requires less knowledge. It's the Ikea flat pack way of building digital tools - simple, functional, easy, and often good enough.

This week we hear more from our digital leads about how they worked with NoCode.

Why did your organisation choose NoCode? 

Sonja 

• We were at a dead end. We had spent 4 months trying to procure something but we couldn’t find anything within budget. 
• Cost! NoCode systems are cheap. Once we had proved it could work at such a low cost, it was an easy decision for senior management. 

Joey

• Previous beta tests had been let down by technology. We need to find a more flexible approach. 
• Maintainability is a big plus. With NoCode, maintenance of the actual tool is someone else's job, but we can still update and change processes ourselves, using systems we set up and understand well.
• Reducing the engineering cost: both the cost of initial build and the cost of ongoing maintenance. 
• I can’t code! For Carefree, it is either NoCode or spending a fortune on external agencies. 

Sara

• Drupal had turned into such a hassle. We were looking for something lighter. 
• In our history, we’ve had many occasions where someone has come in, built something and disappeared. NoCode prevents us getting stranded with a system that no one understands. 
• Speed! We couldn’t have done what we’ve done any other way.
  

What is your organisation's view about NoCode? How did you get your organisation to adopt NoCode? 

Sonja 

• An initial concern was ‘if it’s that cheap, it can’t be secure’. Luckily Knack has a good security page that I was able to point people to. Now I feel we’ve won that battle. 

Joey

• Our trustees had some initial concerns about scalability and security. Then there was a day when I fixed a website problem during a call with a trustee. The trustee had assumed the problem would take weeks to solve. From that moment on, he’s been a big advocate.

Sara

• We’d become very reliant on NoCode, because previously we had experiences of getting stuck with unsupported code. Over the last six months, we’ve come to more of a compromise position. We still start with NoCode but we are more willing to use custom code to soup things up.

What’s the skill set of the person implementing NoCode at your organisation? 

Sonja

• I haven’t got a technical background but it was important that Rosie and I made the first version. We are the people facing the problem: needing better access to programme data.  We were better placed to create the system than any software designer could have been. That said, it took 50 to 70 percent of our time for a year and it wasn't part of our job descriptions. 

Joey

• I’ve got zero coding skills. But I’ve always been good at thinking ‘if this, then that’. 
• I’m the sort of person who likes to make decisions fast. NoCode allows me to go right ahead and implement ideas. 

Sara

• We were very lucky. A seriously hardcore software developer walked through our door at the right time and asked to volunteer. We couldn’t have done this without him.
  

Tell me about some difficulties you've had using NoCode

Sonja

• NoCode is good for what you want to do in 90 percent of situations. NoCode will always be a generalisation of what most people want to do most of the time. I don’t think you could build a tech business on NoCode. Traditional software developers work with atoms. As a NoCoder, you are working with lego blocks. If your business is trying to do something genuinely new, you probably need atoms.
• I struggled to make things look as good and user friendly as we’d like. Perhaps that’s a limitation of the particular tools we were using. 
• Sometimes you just find yourself using the wrong tool for the job. We were bashing heads with other tools before we moved to Knack.
• It has been time consuming for Rosie and me to maintain the tool and respond to requests for improvements. We recently hired someone with a more technical background to look after Knack full time. That has been life-changing. Szelim is giving it a makeover. He can make it do enormously helpful things that would have been impossible without custom code.

Joey

• It can be hard to find the right tool for the job. It’s tricky to stay up to date. There are so many tools out there. I keep an eye on Makerpad and Product Hunt and try to be active on the NoCode community on Twitter.
• You can end up with complex systems stringing together multiple NoCode tools. A well-documented tech architecture is important.
• Once you’ve had some big wins, people sometimes act like it is easy. It’s quick, but it still takes time to research the possibilities and implement solutions.   

Sara

• A hard thing is knowing what is possible with a tool and whether it is a fit for your situation. 
• Every time you want to make an improvement, you tend to break everything and start again. 
• Finding the right person to do the implementation. Also, someone needs time to muck around with the tools, to discover which is a fit for your task. We don’t have people sitting around with the free time to do that. 
• You still have to budget for maintenance. Maintenance might be less of an issue but it still needs to be done. 
  

So there we go. NoCode is very much a "good enough" tool. It's not a magic bullet, and it comes with limitations. But it's a tool ordinary people can wield and understand, not something mysterious, and so it it puts more power over your services in your hands.

Next week, we'll look at some of the key themes involved in NoCode.

‍