No-code tools are supposedly fast and easy. They are, after all, what you use instead of code. “Look what I built in 30 minutes!” is a brag I’ve seen in tweets, blogs, and email subject lines.
I’ve been skeptical. No doubt these tools are fast and easy compared to learning code from scratch. And no doubt a developer can pick them up quickly.
But say you don’t know any code at all.
Say you couldn’t “spin up a landing page real quick” if your salary depended on it.
Are no-code tools still easy for those people? For the truly non-technical?
I decided to find out.
Who am I and why do I qualify as “non-technical?”
My family insists on using me as tech support. Despite the fact I’m entirely unhelpful, and haven’t used Windows in about a decade, they assume I’m tech-y because I work on a computer all day.
In reality, I’ve never built anything beyond my own website using a vanilla WordPress theme.
For my website, I used a plug-and-chug theme. I changed a color or two, but mostly I typed in information.
I’m a writer with a background in project management, restaurant management, retail, and working odd jobs.
When I worked for an agency as a project manager, I hopped through a few Codecademy courses when business was slow. Not much of it stuck—even less than the French I took in high school—and I only tried to make one HTML change on a client website. It took a developer 2 hours to fix my contribution.
Because I’ve spent my last four years around programming, I do know some of the lingo. But I couldn’t tell the difference between code languages if you put them in front of me, and I certainly couldn’t code up anything.
While I may be qualified to help my grandmother with general iPhone questions, I’m far from a “technical” person
Part 1: “Why don’t you come up with an idea for a no-code app?”
This was my boss's pitch to me.
That was Andrew’s pitch to me. I didn't expect it and, I’ll admit, I found the idea intimidating. I can stumble through the definition of an app, sure, but actually build one? That seemed ambitious.
I didn’t have a better idea though, and fear seemed like a silly reason to back down (I didn’t want to look like a coward.) I agreed to the challenge.
How to chase away every possible app idea
The first step was coming up with an idea. Turns out, the absolute worst way to come up with an idea is to try and have an idea.
I went on walks, took long showers, conversed with my dog, and spent ample time staring into space. A brilliant idea, I reasoned, would hit me any moment now. What actually happened was I spent hours chasing two entirely useless trains of thought:
- Thinking about having ideas
- Thinking about sucking at having ideas
After a few weeks of no ideas and useless rumination, I opted for a different path.
A better approach to ideas: start with niches you know
Somewhere along the way, I remembered the best way to find an idea is to look for problems. And the best place to look for problems is in a realm you already know. So I listed everything I knew something about:
- Startups
- Running
- Hiking
- Camping
- Church
- Dogs
- Soccer
- Home ownership
- Writing
- Freelancing
- Cooking
- Project Management
This brought a few ideas to mind. One was a gardening app. I didn’t go with this one, but I’d like someone to build it for me, so I’m mentioning it here. I’ve struggled to figure out what plants to put in my yard. Imagine if I could pull soil info from public surveys, weather info from a weather API, enter my gardening experience level, and receive auto-recommendations for plants. That’d be pretty great, huh? Maybe you should be the one to make it...
Yard ideas aside, I focused in on soccer. Soccer caught my eye because my husband is a B-licensed coach. It’s a sport he’s loved his whole life and something I devoted 13 years to as well. Plus, focusing on this niche allowed me to do what any level-headed lazy person does when they hit a wall: outsource the task at hand.
Once you identify a niche, look for painful problems
Over mixed drinks and a messy lawn (did I mention the gardening app?) I barraged my husband with questions about organized youth soccer.
“What are some of your biggest frustrations as a coach?”
“What drives you crazy about the system you work in?”
It was either the mixed drink or nearly 15 years of experience, but the man had answers.
One of the more interesting responses he gave was around player cards. In youth soccer, player cards identify and verify eligible players on a team—including the coach and team manager. These are printed, laminated, and kept on a key ring at the beginning of each season.
Player cards for adult rec leagues I played in. A youth card would have a few more pieces of information.
Physical, laminated cards cause several problems:
- If players keep the cards, they lose or damage them
- If managers keep the cards, they’re stressed by the responsibility
- When coaches need to pull a player onto their team for a tournament, they often make late-night drives across town to retrieve a player’s card
- Physical cards are prone to theft and falsification
We both had a thought: what if these cards were digital and everyone could access the same database from their phone?
Part 2: Figuring out how to make the prototype
I knew from reading other founders’ stories and writing for Krit that the most logical first step isn’t always an app. Depending on your idea, you might get away with a spreadsheet, mailing list, or landing page for initial validation.
For this idea, those smaller starting points didn’t make sense. There’s an existing app out there with strong testimonials from large soccer clubs. However, the product images show poor design and indicate UI is a major struggle. A smooth, beautiful app experience could be a key differentiator for an alternative product. Visual improvements were something I could show best in a prototype or mockup, so I opted to build a working (or mostly working) prototype as my first step.
For more context, the purchasing customers here are league administrators; the people running local soccer clubs and/or regional leagues. They’re busy, in constant motion, and hard to pin down for a meeting. A prototype would not only show improvements, it’d facilitate feedback in a meeting and prove I’m serious about the idea.
Besides, if I could pull together a prototype without code or spending money, why not do it?
Does the app prototype need to be mobile, web, or both?
Once I decided to make an app, the next step was figuring out what kind of app my users would need.
There are a few different types of apps out there. The kind you download from an app store to your iphone or android is called a native or mobile app. A web app is software you access from your computer or phone via a website. And there’s even a hybrid app that’s built for mobile, using web technologies.
I knew coaches, referees, and team managers would be the ones using a playercard app. They’d use it at home sometimes, but more often on the go and most frequently at the field. All of this pointed to at least a mobile site. When I remembered many field locations are remote and have poor cell service, I decided a native app would be ideal.
To sort through this for your own prototype, ask yourself:
Who are my users? My answer: Coaches, referees, team managers, and league administrators
What do they need to accomplish? My answer: They all need to view and verify team rosters. Some roles also need to edit the rosters.
What kind of information do they need to manage? My answer: Player data such as photo, name, team, and birth date.
Where will they use the app? My answer: Primarily on the field or on the go.
How often will they load the app? My answer: During season, 1x/wk minimum. Would vary by user type.
If you’re a visual person, you could also hop through this flow-chart:
What kind of app do you need?
Now that I knew what type of app I needed, I faced two more big questions:
- How can I make a phone app without coding?
- And can I do it for free?
Part 3: All the ways to build an app without code, for free
Theoretically, I knew the answer to, “Can I make a mobile app for free?” was yes. I’d seen the No-Code trend explode online, and tools like Airtable, Notion, and Zapier make creating prototypes much easier than in the past.
The trouble was, I hadn’t used many of these tools, and I wasn’t sure what else was out there. At this point, I could’ve cheated and pinged the developers I know. But I wanted to experience what it’s like starting from scratch. So I closed Slack, opened Twitter, and searched for #nocode.
Eventually, this led me to Ben Tossell’s site, MakerPad. I also dug up Create Without Code, NuCode, Nocode Hub, and NoCode, which have loads of inspiration and tool listings. Here’s some of what I found.
The best app builders that are no-code or low-code
App builders
- Bubble: web app-building
- Glide: apps from Google sheets
- Appsheet: build apps from data in sheets, SQL, or excel
- Boundless: web-apps (there are a LOT of businesses with this name, btw)
- Stacker: web apps from Salesforce
- Dropsource: technically low-code, not no-code
- Thunkable: build mobile apps with drag and drop functionality blocks
Databases and information storage
- Airtable: a spreadsheet that’s really more of a badass database
- Coda: similar to airtable, but more focused on docs than sheets
- Memberstack: create memberships and gated content
- Quickbase: collect information and create workflows
- Notion: what Andrew is using to build a Krit handbook, good for internal wikis and project management
Add-ons
- Zapier: create automations and hook resources together
- Automate.io: similar to Zapier
- Un-draw: free illustrations
- Loom: video-making
- LottieFiles: super cool, super free animations
- Checkout Page: implement Stripe payment processing without code
- Typeform: easily add beautiful surveys, checkout forms, and signups to your site
Creating websites and landing pages
- Webflow: visual website builder
- Carrd: one-page websites
- Landen: another option for a landing page
- Universe: make a website from your phone
- Table2Site: takes info from airtable and turns it into a website
- Squarespace: popular drag and drop website builder
- Leadpages: content and growth-focused landing pages
Narrowing choices: which options let me create a mobile app for free?
I had zero budget, so I checked out which of these were free. On the app-building front, that eliminated Boundless, since it’s only free for a 21-day trial. I also threw out Stacker because I had no intention to learn or use Salesforce.
This brought the app-building list down to:
Appsheet was harder to grasp and they mentioned “low code” a few times on the homepage. That made me hesitant, because I know zero code; I needed no code, not low code. It seemed like the most effort and would be most useful for someone who could do a little programming. I pushed it to the bottom of my list. Likewise for Dropsource.
- Bubble: free if you’re on a limited Hobby plan
- Glide: free if you’re cool with Glide branding
- Appsheet: free for prototype stage
- Thunkable: free if you’re cool with projects being public
When I poked around the websites for each of these, they all made a good impression. I liked that Glide automatically created an app from data in a spreadsheet. It also auto-generates a structure, and it’s easy to share a preview of the app in a browser window.
Appsheet was harder to grasp and they mentioned “low code” a few times on the homepage. That made me hesitant, because I know zero code; I needed no code, not low code. It seemed like the most effort and would be most useful for someone who could do a little programming. I pushed it to the bottom of my list. Likewise for Dropsource.
I know zero code. I needed no-code, not low-code.
With Bubble, I was drawn to their marketplace filled with themes and plugins. It reminded me of the WordPress ecosystem, which I’ve always found approachable. Unfortunately, the showcase page primarily displayed landing pages and laptop-sized screens. Bubble claimed everything was responsive, but I wasn’t sure without an example. I also couldn’t import or export CSVs on the free Hobby plan, and that could make importing data challenging.
And somehow I missed Thunkable until I tried a few others *facepalm* — more on that below.
Reviewing Glide, Bubble, and Thunkable as a mobile app builders
I started off with Glide. It looked fast and, worst case, I could use the data I entered into Google sheets for a different option.
Plus, if it did work well, Google sheets are wicked easy to update and change. To create a spreadsheet with some sample data, I asked my husband to email me actual player cards from past teams, so I could see what type of data I’d need to manage:
- Image
- Name
- DOB
- Player ID
- Season
- Club
- Team
- Team ID
- Eligibility
I created a fictitious soccer club for Tennessee and then used a mashup up of real data and fake data to fill out a team roster. For player name inspiration, I turned to Liverpool’s professional team. Klopp is my favorite premier league coach, so Liverpool is, by default, my favorite team.
This wouldn’t be a dream team without Rebecca Lowe, NBC TV host for the Premier League and queen of football.
Once I imported the spreadsheet into Glide, it looked fine, but I didn’t see a way to do much beyond view the roster*. To convince a league administrator, I’d need to show them more than that.
*It is possible to do more with Glide, as this NFL draft app demonstrates. I'd encourage you check out the platform for your prototype. It was the most friendly option I tried.
The roster looked and functioned great. That was a success, but I didn’t see a way to add more complex functionality.
A full-blown system would need to have different permission levels: club administrators and coaches could see all teams and players; team managers could enter information for their specific team; referees could view rosters. I didn’t see a way to do this with Glide, and I wanted to know if it were possible in other app builders.
I decided to try Bubble and see if it was more robust.
Holy clickable options.
From the moment I signed in, Bubble was definitely more complex. In fact, I was completely overwhelmed with all the options. It felt like opening up Adobe Indesign and trying to figure out what the hundred tiny tool icons do.
I hopped through an obligatory map tutorial then accidentally opted into a sign-in tutorial. These were both relatively helpful, but the language was jargon-y and difficult to follow.
Workflow is a powerful feature in the Bubble tool. It’s what you use to make something happen when someone clicks a button, icon, or screen. Creating workflows is not intuitive.
Bubble looked cool, but the more I clicked through example projects and templates, the more I was unsure whether it’d work for a mobile project. I’d already spent about 3 hours looking up tools, creating a spreadsheet, and testing Glide and Bubble. I was hesitant to sink several more hours into learning this tool if wasn’t going to work out.
I told Bubble I wanted to build an app. The default screen they presented was phone-sized, but the content was totally cut-off. This made me extra hesitant to use Bubble for mobile.
I was discouraged and started poking around Twitter again. That’s when I stumbled across NoCode. The very first app builder they mentioned was one I had somehow missed. Better yet, it looked particularly promising.
How did I miss this?
I created a free Thunkable account and started clicking around. There weren’t many helpful tool tips but, after a few minutes, I figured out enough out to determine it’d be a good fit. This, at least, was made for mobile apps and had a less overwhelming layout. Note: I did find a short tutorial with an overly eager beaver later.
I set up a few screens that mimicked a short onboarding sequence. Then I looked up how to connect my database in Google Sheets. Thunkable documentation asked me to use Airtable, a tool I already use and love, as the primary database for my app.
Since my database was in Google Sheets, I needed to downloaded a CSV and import it into Airtable. This was so easy, and worked so beautifully, I could’ve cried.
Documentation for connecting Airtable to Thunkable.
Once I connected Thunkable and Airtable, I created more screens and added basic functionality. For example, you could click a button and go to a different screen. Hooray! I felt like I was actually building a prototype at this point.
I had chosen a tool, imported data, and was organizing my idea into actual screens and workflows.
Part 4: What building a no-code app as a non-technical person was really like
I spent a lot of time in documentation and forums. Taking the app from “a few basic things” to “refined enough to show the Krit team” proved extremely tedious. After a few days, I started to feel like I was playing the digital equivalent of golf: How do I use [limited tool] to get [small object] to do [complicated thing]?
I spent as much time sifting through documentation as I did building the app. Tweaking visuals took hours, and trying to get something over here instead of over there was frustrating enough to elicit moderate cursing.
While I didn’t have to learn code, I still had to learn the tool and its system. That took considerable time (as in days).
I hit several walls and had to get creative
Turns out, some pieces were too complex for me to create—at least without developer help. Others were too time-consuming. For those pieces, I had to get creative. How could I make it appear like the app did something, without it actually doing so? (The “Wizard of Oz” approach.)
For example, I wanted to demonstrate adding player information. It’s one of the main app uses, and it’d help conversation to show the process. I created a screen where you can take and upload a photo, plus add some basic data. When you submit the info, you see an animated success screen.
Now, the app doesn’t actually update the roster with the information you add. But it lets someone go through the process so they can experience how easy it would be. (It is possible to make this work in Thunkable, but it would have taken me a few more hours.)
I made similar hacks in other areas too. Most notably, when you click an individual on the roster to view a player card. Glide enabled this beautifully but—for the life of me—I couldn’t replicate it in Thunkable. My “hack” was manually creating a sample player card that each name links to. It’s not ideal, but it at least shows someone what a player card looks like.
None of this duct-tape was in my original plan, but that’s okay. Prototypes aren’t supposed to be perfect.
Knowing tech vocabulary was my biggest advantage
Building a no-code app took a lot of time. I spent over 16 hours researching, testing tools, building the app, digging through help docs, and testing functionality on my phone. Doing all of this would have taken at least twice as long if I didn’t have basic familiarity with tech and programming jargon.
Check out the screenshots below. Can you imagine how frustrating Thunkable would be if you had never seen these terms?
Full disclosure, I'm still not sure what these do. ¯\_(ツ)_/¯
The jargon in Thunkable and other builders was a big surprise. These tools market to non-technical personas, but they deliver technical language and tutorials. This is a big roadblock for any founders who don’t know the lingo. There's a clear opportunity here for a robust tool that uses everyday language to guide no-code builds.
Testing something I built on my phone felt like magic
One of the coolest things about Thunkable was testing progress on my phone. An app, called “Thunkable Live,” lets you click through whatever you’ve built, on your phone. It helped me see big gaps, annoying bugs, and what I could do better. Best of all, it was easy to use.
To a non-technical person, this felt like magic. It made the whole process way more fun and real.
How my final no-code mobile app turned out
The final product is definitely more of a prototype than a full-fledged app. It’s not something coaches and referees could use as-is, but it is enough to put before potential customers for feedback.
On the one hand, I wish I could’ve made the roster-to-individual-player connection. I was disappointed I wasn’t able to create more functionality in the time I had. I invested 16+ hours in thinking up ideas, researching tools, and prototyping in Thunkable (that estimate does not include conversations with my husband or Krit, nor does it include writing this post). If I had spent an additional two hours in Thunkable, I could have added a bit more functionality. It would have taken several more days, and assistance from technical friends, to make it 100% functional.
On the flip side, I did create some basic walkthroughs that I could show potential customers. That was the original goal, and creating a tool that could spark feedback was a success.
Check it out yourself
If you want to check out the app yourself, create a free Thunkable account and then visit my public project URL. This will let you click around the design and backend. If you’d like to test the app on your phone, you’ll need to download Thunkable Live and live preview the project.
So, what no-code prototype will YOU make?
Building a no-code app isn’t as easy as some blog posts and tweets make it look. You will have to put in hours of effort to get a good result. But once you find and learn a set of tools that work for you, you can create some cool products. Even better, you can take the processes you learn the first few times around and apply them to future projects (or so prolific no-code makers tell me).
The best news of all is this: the whole no-code thing isn't a sham. It is possible for non-technical founders to build prototypes without code or coding knowledge.
As no-code tools become more robust and approachable, non-technical founders are going to have incredible opportunities to create fully functional prototypes in short timespans. Already, it’s possible to build a basic prototype, on no budget, and get it into potential customers’ hands in a matter of weeks. That’s amazing.
Laura Bosco is a writer and people person. She helps tech startups do tricky things, like explain who they are and what they're doing. She's currently working on Krit. Ping her on Twitter to say hi.