Many of us have ideas for apps we want to build. Whether it's a social network, a marketplace, productivity tool, or even an internal tool to make your company better, chances are you've had ideas about some type of app that you'd like to bring to life. As great as your idea might be, it's just that—an idea. If you know how to code, great—it's likely you can start to build. But what happens if you don't know how to code? Enter no-code.
Some refer to the movement as "no-code," and others refer to it as "visual programming." Regardless of what you call it, it's a growing phenomenon that allows anyone to build without writing code. Only 1 in 400 people know how to code. Imagine if only 1 in 400 people knew how to read and write. By leveraging no-code tools that already exist, we can create an app that functions just as well (if not better) than one we could have built if we learned how to code.
Even if you do know how to write code, building without code allows us to build apps at a fraction of the time and cost. Here's how.
Break down your idea into concepts
Let's say you wanted to connect with your employees and boost morale (without using Michael Scott methods). Since it has been a tough year for everyone, this morale-boosting service will send inspirational text messages from time to time to employees around the company. (Keep in mind that this is with the assumption that the company's policy allows for text communications and employees have opted in.)
The texts will be sent to their phone. Maybe you also want to share their responses on the company's Twitter page (since sharing is caring), as well as notify them when the response has been shared.
Here are some questions you might ask yourself as you start to think about building this communications app:
How do we get our employees to opt in?
What service can we use to send text messages?
What sort of messages are we sending? SMS? Images? Videos? GIFs?
Does the messaging service provide a turnkey interface to send messages, or do we have to create that on our own?
How do we determine what messages we send?
How frequently do these messages need to be sent?
How can we automate this so that it's scalable?
From concept to tools
Once you have your main concepts, you'll want to look for the tools you can use to accomplish those goals. We'll walk through that for each step of the hypothetical app we're building.
Capturing employee information
The first thing we'll need is a way for employees to opt in. You could ask everyone to email you if they want to opt in and participate, but that's incredibly time consuming and inefficient.
This could work if it's only for a handful of people, but the goal when building something is to lay the foundation so that it's scalable. Whether you choose to scale up or down is up to you, but laying the groundwork in a way that allows you to have that flexibility is critical from the start.
Doing this manually also allows room for error. We're human, and humans make mistakes. Lots of them. Even if you were to ask people to structure an email a specific type of way, someone might interpret it differently. Or someone might not read it altogether. As usability/UX consultant Steve Krug would say, "Don't make me think!"
For these reasons, it would be best to use an online form of some kind that allows you to collect information the way that you want, without leaving margin for interpretation or error.
We could use this form natively, or embed it on a website. For our app, we're going to embed the form on our employee wellness website, so there's no need to create something new.
Now let's think about the type of information we want to capture. We'll probably want to capture basic information, like name, email, phone number, and how many messages they'd like to receive throughout the week. In the event that you were using this service commercially, we could also set up a gateway like Stripe or Square to accept payments.
We can use something like JotForm, PaperForm, or Typeform to capture this info. Let's use Typeform for now, since it also has a payment integration with Stripe. In the event that we want to commercialize this service somehow later on, we'll be set up and good to go.
If you don't have a standard form or survey app, check out our recommendations for the best online form builder software.
Storing employee information
Capturing employee information is useful, but it doesn't do us any good if we don't have a place to store it. Since we'll only be capturing a few basic pieces of information, we could easily store this on a spreadsheet. If we were using code, this might require using a database like MySQL, PostgreSQL, Mongo DB, or MariaDB.
Without code, we can simply use a spreadsheet to store our data. Let's use Google Sheets for our example.
We can structure our database with just a few rows to capture all the necessary information, such as:
Status (to determine if messages have been sent or not)
Number of messages to send
Number of messages sent
The messaging service
This inspirational text messaging service sends texts, so we'll need to leverage a tool like Twilio to send SMS texts. This brings up a good question: Are you planning on sending media (pictures/videos/GIFs) with your texts? GIFs make everything better, so let's vote yes.
Please note that text and media is sent differently, so we'll have to make sure we enable that functionality somehow on Twilio. We'll circle back to that later.
The email service
The last major piece of the puzzle is the email service that notifies employees when their response has been shared to the company's wellness Slack channel.
Like the form, there are a few different services you could use for this. There's MailerLite, Sendinblue, GetResponse, or Mailchimp. Let's use Mailchimp for now. We'll pretty much only be using the email service for notifications, so we don't need to worry much about advanced functionalities.
Working with the tools you'll need
So far, we've determined that we're using Typeform to collect employee information (which will be embedded on a website), Google Sheets to store that information, Twilio to send the text messages, and Mailchimp as the email provider to notify employees when their replies to the inspirational texts have been shared.
The way to do this is to write some scripts that connect all of the—just kidding. We're not writing code here. That begs the question—if we're not writing code, then how can we possibly link all of this together? Through the magic of Zapier's automated workflows—called "Zaps."
New to Zapier? It's a tool that helps anyone connect apps and automate workflows—without any complicated code. Sign up for free to use this app, and many others, with Zapier.
Typeform, Twilio, Google Sheets, Slack, and Mailchimp all integrate with Zapier, so we can create triggers and actions that fully automate the app. Zapier also has tons of other integrations, so if you wanted to use Airtable instead of Google Sheets as your database, for example, you could do that too.
Piecing it together
Chronologically, here is how you might think about the steps to create a workflow with Zapier:
An employee opts in and signs up using a form online
You store the signup information on a spreadsheet
You receive a trigger/notification that the signup information was submitted
You send out out the text messages at a specified timeframe
You publish their replies to the company's wellness Slack channel
You notify them when their reply has been shared publicly
We'll break these steps down.
Zap 1: Typeform response, update subscriber, create spreadsheet row
Your employees will opt into the service by filling out the Typeform embedded on the employee wellness website. This information is stored natively within Typeform, so you're able to see it there as well. However, you'll want to send that information to Google Sheets, your database.
Since we want to notify people via email when their response is shared, we'll also have to add a step in Zapier that adds the email to Mailchimp. Here is what the first Zap will look like:
In plain English, here's what this Zap does: When there's a new entry in Typeform, add/update the subscriber to Mailchimp and Google Sheets.
Zap 2: At scheduled time, format numbers, choose quotes, send SMS
This Zap is where most of the app functionality happens. For our example, we'll say employees receive one text per week, and we have a spreadsheet containing 50 different options. Having our Zap start with Schedule by Zapier (not pictured in the below screenshot) lets us send the texts once a week, and to choose the day and time of the send.
You can configure the Formatter step to choose quotes randomly from your populated database and send the SMS using Twilio.
Zap 3: SMS response comes in, lookup spreadsheet row, send message to Slack
The final Zap exists to trigger publishing to the company's wellness Slack channel in the event the employee chooses to respond to the inspirational quote. Since replies also get sent to your database, you can pull from that database and format a Slack message from that content. Here's how your Zapier workflow might look:
In plain English, this Zap says: When a new SMS is received, look up the responder in Google Sheets. Then, find that user in our Slack workspace, and create a channel message posting their response and tagging them so they can see reactions and any discussion.
That's it! You've created a functional, fully automated communications app all without writing a single line of code.
Start creating, no code required
Keep in mind that there are several different ways to accomplish building this app. As previously mentioned, you may be using different software to accomplish the same goals. Your workflows might also not look exactly like the ones you see above. What's most important is to dive in and try to find your way around what works best for you. Once you have the concepts down and tools in mind, putting the puzzle pieces together is the magic sauce.
This sort of messaging app that we just built is only one of many different ways that you can leverage popular tools to create an app without writing a single line of code. You can build apps internally, externally, apps that are B2C, B2B, etc. The possibilities really are endless.
Of course, it's natural that you'll have hiccups. It wouldn't be an app without them. But once you learn to build with a variety of different tools, and your mind is opened up to the realization that they can all be connected without code, it's eye-opening.
A lot of the process is trial and error, regardless of skill level or where you are in the development lifecycle. With lots of trial and error, you'll start to gravitate towards different tools for various purposes. Everyone is different, so play around with a bunch of different tech stacks until you find one that works for you.
Many developers criticize the no-code/visual programming movement. They often say that it's better to simply use code. Of course, this misses the part that only 0.3% of people can use code. No-code is not about replacing developers. In fact, it's developers who write code to create these tools that don't require coding—or that require very little coding.
Learning to build apps without code is an avenue that allows anyone to work technically and creatively all at once. If you're a master programmer, then perhaps code is the way to go for you. If you know how to code, but prefer to work with little to no code, visual programming is a great way to build not just an MVP, but a full-scale app. And if you don't code at all, visual programming opens up a world of opportunities for you in ways you may have never thought possible.