Using no-code as a Proof of concept

This post takes me back to the Summer of 2020. I had a problem to solve and turned to no-code to help produce a quick proof of concept.

Firstly, what’s no code?

No-code is a set of tools that allow you to create websites, apps and software all without writing a single line of code.

Max, founder of 100daysofnocode explains…

“No-code gives anyone the power to be a ‘creator,’ regardless of someone’s ability to pay for expensive and time-consuming coding education. It gives teams the ability to automate existing processes and streamline overall operations. It gives marketing teams the ability to create growth tools, designers the ability to not only design but to create working prototypes of the features they are designing to show to product managers, and organizations the ability to test and build ‘experiments’ they would not commonly take, but are now able to, as a way to rapidly iterate through their product roadmaps.”

What do I mean by proof of concept?

A proof of concept (POC) is something that is built to test an idea and to prove that it is worthy of investment. It is different to it’s sibling, the minimal viable product (MVP) in that it doesn’t have to be built on. Both share the trait that they should be created at the lowest cost (in both effort and money) possible.

Story time…

It was peak-covid 2020, I was working in a large union that I won’t name. There was concern about the safety of the spaces that our public service workers were in. The government had released it’s covid-secure guidance, and the health and safety team at the union wanted to a way to support members to check their workspaces, and most importantly in reports that they may need to write.

The problem was clear. We needed to find:

  • an easy way for public sector workers to check the safety of their workplace?
  • a way to ensure that the union could support them in any actions that may need to be taken?
  • something that would supply the data so we could see the big picture?

How did we go about solving our problem?

For many years the union had encouraged members to become health and safety representatives. These were members of the union with a specific focus of ensure the health and safety of their workplace and in representing the wider workforce. Along with significant training, the health and safety reps would work to a check lists of 5 main steps. This was our starting point.
The checklist was clear, fairly easy to use, and helped everyone understand the questions that they needed to ask. But, there were a number of things it didn’t do.

It didn’t;

  • create a way to share and collaborate where needed
  • track the progress of improvements.
  • help to create a UK wide and regional view of the situation.
  • guide new reps through the process

So, what could be done to address this? We knew that the steps were well tested and widely accepted. The focus of our work had to be on answering how we could make the progress trackable, simpler for the user and a way to gather important intelligence to help improve the situation more widely.
Time was tight and we needed to launch a test version very quickly. To do this we turned to no-code to build our proof of concept – and some of my favourite tools of the time.

What no-code tools did we use and why?

We connected a few no-code tools to help us to deliver the testable version (proof of concept) of the tool. The tools that we used for this case were, Typeform, Docupilot, Google Sheets, Google DataStudio, and Zapier.

Vintage connection through telephone operator.


Typeform is a powerful no-code form tool. It looks great straight out of the box and is easy to adjust to brand guidelines. It also responds well to different devices and changes the form size to fit their screens. For this case I decided to create five connected forms to reflect the five steps of the health and safety checklist. Each form had quite a lot of decision based logic* behind it and breaking it down to these steps helped managed it.

*Decision based logic is when you tell a computer to do something based on the answer to the previous question. For example if the answer to the previous question is no, ask for more information.

Before building in Typeform we looked at the information, or data, that we wanted to collect and how we would use it. This helped to guide how we designed the rest of the tool, and the questions we asked. In this instance we wanted the completion of the form to connect to a database and to produce a document for the rep to use in their next steps.

Google Sheets

In order to use the information gathered on the Typeform we needed to create a log, or database, of responses. For this we turned on the in built connection between Typeform and Google Sheets which automatically creates a spreadsheet of responses for you.


Is a tool to help you connect data sources, integrate, and automate actions. You can use it to automate different actions based on the rules that you give it. You don’t need to know any coding languages to use it, but you will need to understand what you are trying to do and why. We used Google Sheets as a trigger (or the starting point of the connection) and then matched each possible answer to the template in Docupilot.
Once the PDF was created we needed a way to share it with the person that had completed the form and somewhere to save it for later use. We again used Zapier to send the document via email, and to save it securely on the cloud.

I must add a quick note here about using Zapier and GDPR – in order to be sure that you are not putting personal information at risk by using this tool you should double check Zapier’s privacy policy. You won’t only use this tool for personal data and if you choose to, make sure that your users know. Zapier is a third party tool, and it’s use involves the connection of other tools. So, it should be included in your list of third party tools within your privacy policy. If you’re unsure about what this might mean for you and your organisation please seek some advise from a GDPR specialist.


The tool needed to produce a non editable document that outlined the results. To do this, we connected the Typeform results (saved in Google Sheets) to Docupilot to produce a unique PDF of the results each time all steps were completed. This was then emailed to the person using the tool as well as stored to be used at a later date by the union if more support was needed.

Google Data Studio

Google Data Studio is a pretty powerful data visualisation tool that you can use to create reports from a google sheet. In this case I used it to highlight the key insights we’d decided on, the main two being:

  • Where have the reports come from? Knowing this we could work to increase uptake in certain regions. We could drill down to see reports on a regional basis too.
  • Are protected characteristics (Race, Gender, Sexuality) being considered?
  • Is more experienced support needed?
Redacted screenshot taken from a map visualisation of use of the tool.
Redacted view from the Google Data Studio report showing where the reports were being made.

Have you used no-code tools to build a proof of concept of or a full version of a product? Share your experience in the comments 🙂