We love being a part of the conversation around the subject of whether ‘no-code will replace software developers’. There are so many opinions and ideas – and we’re here to listen to all of them! With that in mind, here’s the story of how a freelance software developer with 40 years of experience switched to a no-code first strategy for all his clients.

Hi, my name is Fraser Gorrie! I've been writing code for clients for over 40 years. I didn't start out that way. I'm a marine biologist and zoologist that settled 1000 miles from the sea.

When I left university, I started working on other people's data: modeling processes and writing statistics. That quickly led to writing custom applications for environmental agencies and later business. After the thrill of solving real problems set in I was hooked.

I just never looked back.

I have been developing traditional software solutions for clients for 40 years. I love it. I truly enjoy the process of taking a set of desired outcomes, sandwiching those within a hedge of contraints and limitations and providing a custom, lasting software application, be it for desktop, mobile or the web.

What is this new world of no-code?

In March of 2021, I had a pivotal conversation with a no-code founder who was looking for help to convert his no-code ensemble application into a fully coded one. Here, I thought, was someone who had come to his senses and realized that serious apps, especially those gaining traction (which has was), need to be in a fully coded environment. Yet, after speaking with him, I was impressed.

More than impressed – I was curious.

What is this new world of no-code really? What can it do? How deep does it go? Is it a serious contender for building serious apps? It turned out that this no-code needed someone a little more attuned to his industry and needs and so we didn't start working together.

He did, however, mention a tool he thought I might enjoy: Bildr.

And so began my journey into no-code: Completely from the perspective of someone who can code serious applications. I looked at Bildr, and then did my research on what is available in this space.

Exploring this new world

I found a great many tools with various focuses and specializations. I had a list of must-haves that I would use to create a short list of tools. I believed my must-haves would be quite different from what, say, a SaaS no-code, corporate team, or hobby user would consider important.

For example, I needed to be able to use javascript wherever I wanted to customize functionality. I also needed to be able to override CSS at will. I also wanted things which are missing from traditional software development tools.

For example, I wanted to be able to visualize flows initiated by events in the DOM or from the user. I needed access to API calls, any data source I might need, and the ability to roll-back to previous states of development.

What I found was that I was naively imposing coder logic onto a principally no-coder terrain. I found many of my must-haves but didn't find others. But like car buying, it was in the combination of features that each tool offered where you have to face the fact that I cannot think only as a coder in this brave new-ish world of no-code.

It is an extremely quick-evolving space where you have to choose one tool now, work with what it has now, and pray for what it could be soon.

So, I got my shortlist and found many very good no-code/low-code contenders for my client work. In the end, I went for a relative newcomer to no-code: Bildr as the team is wonderful to work with, is responsive to feedback, open about its development, and have themselves been using Bildr (and its previous incarnations) for their own client work with a team that has remained together for 10+ years.

It helps that Bildr as a tool is built with Bildr. The meta appeals to me greatly.

How I apply no-code to my work

I use a number of no-code tools, because the client's needs/preferences often direct the choice of tools I can use. But in general, I pick the best tool for the job depending upon the project. Some of the client-side tools I have used in addition to Bildr are AppGyver and AppSmith.

Apps also need back-end services. You need to connect your client-side app to data and other services. Here again, the no-code space is quite rich in back-end tools.

I have used Airtable and Google Sheets directly as data sources, but what I have been super intrigued about is the growth of middleware tools where you can connect to databases and other services yet write complex business logic and perform optimizations in the data that you deliver to the client app via a REST API.

I'll mention a few here that I find excellent: Node-Red, XANO, Canonical, and Supabase. There are a few others as well, that I am hoping to find the time to try.

The combination of no-code/low-code on both the client-side (browser) and on the server-side has convinced me of something I wouldn't have entertained a year ago: all new client projects should start off (and likely finish) as no-code projects: a no-code–FIRST strategy.

As a coder, I feel welcome and eager in this no-code space.

The gaps that I see in no-code as a coder

One BIG issue with some no-code/low-code tools stems from their very nature: users don't create code (text-based data files) as their base layer. No-coders build on top of code written by the vendors and presented as pre-written blocks they can arrange and configure.

No-coders largely string together these pre-written components into either visual presentation or flows of actions that respond to events originating from both the user and the page. There is code there, but a no-coder is changing the parameters of code, not the code itself.

So a coder's safety net: a repository of all the code they have written on their current coded project, date- and time-stamped, able to show what has changed between two commits to the repo is not there!

Imagine delivering a no-code app to a client, having the app stop working, and not knowing exactly what has changed since it left your control? I lose sleep at night over this one!

The question for me becomes, what do you store in a repository that you can use to recreate your no-code app? I think the answer lies, at least initially, in exporting the parameterization of your no-code app's visual and flow components into JSON and then saving that to a Github repository.

That is the first step, and it is probably not far off in some of the tools out there. In the case of Bildr, its internals are already JSON based and thus it offers the most hope for an export-to-GitHub tool being developed that will do just this.

I hope to develop such a tool soon, but others in the community have both the skills and interest to do this as well.

In the meantime, my current solution for every no-code tool I use is to:

1) manually copy the parameterization of the components I'm using into another tool,

and 2) create frequent backups (if provided by the tool).

Take your time to pick the right tools

Investing in a no-code/low-code tool is a major decision. Whether you are developing apps for yourself or for clients, you need to pick the right tool that both suits your approach and serves *all* of the future needs of your app.

There are so many tools available now, just as there are many ways to develop apps with them. If you are going the no-code route, then spend some time investigating the big players as well as the up-and-comers and a few of the newcomers.

Test them all out. Take a few days to feel how you personally will be with them a month from now. Try to find the edges of what your app must ultimately be 2 years or so down the road.

See how you like working in each tool's interface. Check out their Discord or other user forum. See how responsive the developer team is. Watch the /nocode subreddit and ask your questions.

Why so much effort?

Because you are going to be spending a lot of time learning and developing. I have seen too many who reach significant progress with their app using a particular tool before finding out they cannot do the rest because the tool doesn't support what they need to do in the way they need to do it. And that is a serious blow to your morale and to the continuance of the app you are building.

And if you are building for others, there is no room for failure. So research well and good luck!

‍

Thanks for sharing your story with us, Fraser! You can follow his work on Twitter or on his website.