Is it time to deprecate “Make or Buy”? A developer’s thoughts on the NoCode world.
What is NoCode?
I’ve been looking into NoCode for some time now, and I thought I’d sum up what I’ve learned up to now.
I’m a developer at heart. I was a developer for roughly 15 years before moving onto architecture as a full time job. And even though I don’t write code anymore, I live in a world of code: I read it, I talk to developers who do write code and I’m heavily involved in managing complex systems built on code.
When I started working it was all about RAD with Visual Basic, Delphi and such. Yes, that was a long time ago, now shush. Then we progressively moved out of that paradigm for an hail-to-the-code world. Nowadays, everything can (should?) be code: your business logic of course, but also your tests, your user interfaces, your infrastructure, your CI/CD pipelines… This has one huge advantage: code is easily versioned, reviewed, packaged and deployed. We developers love that.
But this all-code paradigm also has downsides. How many languages to master? User interfaces are written in markup languages (HTML, Markdown, XAML…) and prettified with CSS, SASS, SwiftUI, Jetpack Compose… Business logic is in the best case written in one general usage language for backend and frontend (Javascript, Typescript, C#…). More often, you’ll have one language (likely Javascript or Typescript) for the frontend and another language for backend. You’re bound to need a scripting language at some point, so you’ll learn Bash, PowerScript or such. To automate your infrastructure and CI/CD pipelines, you’ll learn DSLs for Terraform, Jenkins, Github Actions or whatever. So this may all be code. But that’s a lot of different flavours of code. This has one direct consequence: being a developer in 2022 can be a fantastic job, but it definitely is a hard one. It requires time, effort, dedication and the right context. And don’t get me started at how good we are at gatekeeping.
Now, we live in a world where every single aspect of our professional and personal lives involve software — and that trend will only come to an end if and when this world collapses. Which might happen, but that’s probably another conversation. So we do have an issue here. Our capacity to train (and keep!) developers does not follow the trend of our needs for software.
I attended the NoCode Summit last week in Paris, and I learned a few interesting facts and figures:
- 0.4% of the population can code
- most of the software we want hasn’t yet been written, and will most probably never be written. Add the fact that many features we do build are rarely or never used — fun times!
Soooo… Building software is hard, there aren’t enough software engineers today and things are just going to get more complicated overtime. This is precisely the problem NoCode vendors are trying to solve.
Now, NoCode is not a new concept in any way. Excel has been around since 1985 (yup, you read that right) and entire businesses are built around spreadsheets. WYSIWYG editors have also been around the ages. BUT we have reached an interesting point where integration is standardised using REST APIs. So a lot of things can now be done by fitting pieces together like Lego bricks.
Add the fact that a lot of the software we build are variations on the same theme : basic CRUD apps, simple automation of boring tasks, forms… There are thousands of apps out there that aren’t — yet — built because the ROI is not high enough. There’s even a term for that: being roadmapped. Now, ROI is simply a subtraction of the expected added value minus expected cost.
ROI = added value — cost
We can expand this to estimations, which is basically how we build roadmaps:
Expected ROI = expected added value — expected cost
What often happens is that people are exceedingly optimistic about the expected added value. Yes marketing people, I’m talking about you. Just kidding. But still. On the other hand, if the cost of software is reduced enough, ROI goes up. This could change a lot of things.
What can you build with NoCode tools?
And here are the types of tools that seem the most interesting to me :
Apps
These tools enable to build quick and cheap mobile and web apps. The biggest names are Bubble and Glide. Out of the box, you get an interface that enables you to quickly design interfaces, flows from one page to another, actions behind buttons to perform standard tasks like calling an API, storing data in a local database, sharing content, etc. You can also customise the look and feel of your app up to a certain extent. And finally, these tools will assist you in making your app available to your users by hosting the web app or publishing it to an app store.
Databases (and data centric apps)
Who runs the world? G̷i̷r̷l̷s̷ Data. Data is everywhere. Data is power. But data is bloody expensive to make accessible. Building and maintaining databases is complicated. And we don’t all need massive PostgreSQL or MongoDB databases to store a few hundred or thousand lines. People have been using Excel for years to build tools for themselves or a few people. But Google Sheets and Airtable take things a few steps further with features such as adding interfaces and forms interacting with data, automation, synchronisation, and finally integration through a set of built in connectors and a REST API.
Automation
Everyone hates repeating boring tasks over and over again. Tactics can widely vary: hire an assistant, postpone a̸n̸d̸ ̸f̸o̸r̸g̸e̸t̸, get your IT department to build a tool… But Zapier, Make and such have another opinion: do it yourself. The central concept of these tools is a workflow. A workflow is a set of tasks that start with a trigger. Out of the box, you’ll get a nice clean interface to build these workflows, leveraging impressive amounts of built in integrations with other tools: calling an API, sending a Slack message, creating a Salesforce case, listing your AWS Lambda functions… And whatever connector is not built in, you can call the API for yourself.
For example, I automated a simple task I was doing every Monday: checking the number of available seats on Github, and sending an email to my sales rep if there were less than X seats left. It took me roughly 1h to do, including learning how the automation tool works. A few months ago, I would have probably written a console app in C# and triggered it from a scheduler.
Of course at some point, you’re going to have to learn a few fundamental concepts, such as conditions, loops, reusing error management and monitoring. But you’re up and running very fast, and you can learn as you go.
Collaboration
No need to go into details regarding things like Notion, Microsoft365 or the Google Suite. The amount of features each of these tools have is massive.
The NoCode stack
One very nice thing is that NoCode tools integrate very nicely with all sorts of other tools. Including of course other NoCode tools. You could have your backend in Airtable, frontend apps built with Bubble, recurring tasks automated using Make and documentation in Notion. During the NoCode Summit, I saw examples of companies going full NoCode, and others building custom apps for their core business and leveraging NoCode for less critical use cases. I like the philosophy of flexibility. But does that mean you should go heads in without thinking? Nope.
When to use NoCode tools?
In my — biased — opinion, here are the 3 scenarios I believe NoCode tools are the most relevant, at least to start with.
- Internal user tooling. Think really carefully before you build complex custom tools for your internal users. What tasks do these users accomplish that are not accomplished (as well) anywhere else?
- Automating your own work. That’s a real winner in my opinion. Massive time saving to expect here.
- Innovation and learning. NoCode tools can help you get very fast on the market and test things in the real world. Maybe you’ll switch to a custom built app later on, but maybe not.
What to pay attention to?
All that being said, here are a list of things I believe you should look into before diving in.
Vendor locking and price of exit
When using a NoCode tool, everything you don’t do yourself is done by the vendor. So pay attention to the solutions you choose. You can’t just lift and shift a NoCode app out of one platform and into another. Some don’t even have any feature to export your work.
What happens in the worst case scenarios? e.g.
- Vendor goes bankrupt
- Vendor deprecates a feature you use
- You reach the limit of a tool and need to figure out an alternative solution
Customisation
How much graphical customisation do you want or need? None at all? Just a logo? Your company’s colours? Your own CSS sheets?
And when you need a feature the vendor doesn’t provide, can you build it yourself somehow?
Basic programming concepts
Although NoCode tools target a large population, you’ll still have to learn some basics, such as naming, sharing logic, loops, conditions, error handling, observability…
NoCode apps are still software. And running software does require knowing most of all this. But the good thing is the vendors know this and you’ll find clear documentation, videos and examples to help you through.
Scaling up and collaboration
Working alone is one thing. Working in a team and building working software on the long run is another. Think onboarding new team members, think source control, think reviewing changes, think testing, think deployment, think monitoring, think how to deeply refactor your system… These are problems that have been solved for a long time in the development world. But not yet in the NoCode world.
Fitting NoCode in your company’s strategy
You definitely don’t want an army of rogue NoCode builders starting to build and automate stuff without control. Define where NoCode is useful, and learn how to work with these tools. Define where they sit regarding your current strategy. Define how these tools fit in with your current stack if you have one. Define how people work together, and how and when to specialise them.
Make or buy or…?
Make or buy is a classic. Should I build a piece of software myself or buy something of the shelf? There is also the option of having it built for me, but let’s keep things simple. It’ll still be a custom app.
The NoCode movement introduces an interesting 3rd option somewhere halfway between the custom app and the off-the-shelf option. I’d suggest to extend the question:
Code or build or buy
Final thoughts
I would strongly suggest people in the software industry to keep an eye on what’s happening in this space. CTOs, CPOs, managers, developers, PMs, stakeholders… There are some really interesting things going on. I don’t believe we’re even going to stop building custom software. But I do believe we can avoid building some custom software. And build the software we want that does not yet exist.
The NoCode vendors and integrators actually call it a revolution. I’m not as convinced as they are about the impact of this revolution, but there is definitely something happening.
