Maker: Drew Thomas Best Place to Find Him: Twitter Project stack for Yesterday’s Weather can be found here. Project link for Yesterday’s Weather.

TL;DR – How Drew used a no-code stack to make Yesterday’s Weather, building an app for the web and mobile app listed in the app store…with no-code!

Can you tell us a little bit about yourself and your story?

DT: I’m Drew Thomas. I run a nocode consultancy called Work and Whistle, and I also run several other businesses, including the No Code List.
I previously co-founded a digital agency, but more recently as an independent consultant, I fell down the nocode rabbithole and shifted all of my efforts to focus on it.

What did you make?

DT: Yesterdays Weather is a native mobile app and a web app that tells you today’s weather in terms of yesterday’s. So it might say, “Today, it’s 3 degrees cooler than yesterday, but there’s less wind.”

What problems were you trying to solve, your story, your motivation to want to make it, or your why specifically for this project?

DT: For whatever reason, seeing the current temperature as a number never worked for me. The same temperature number can feel completely different based on clouds, wind, rain, and even time of year.
I wanted an opinionated explanation of the weather, not just the raw data. Since I can easily remember what it was like yesterday, it’s a perfect thing to reference when explaining what it will be like today.
Around 2014, I came across a weather data API that could give me historical weather information. Almost instantly, I made a little app to create what I’d always wanted!
That was the first version, and since then there have been several native app versions and web app versions.

What different tools did you use? Your Tech Stack.

DT: Yesterday’s Weather has a couple different parts…
- Native app – Thunkable
- Web app – Bubble
- API – custom PHP (from a previous project)
- Marketing site – Carrd

Why this stack? Can you talk specifically about why you chose those tools?

DT: In this case, I actually chose Thunkable before I chose to make this app. I wanted to try Thunkable, and I had the weather API from before. In fact, I had Yesterdays Weather in the Apple app store a few years prior, but it had been neglected and removed. I was excited to get it back, and Thunkable could do everything I needed… third-party API data, conditionals and object manipulation, etc. Most other nocode native app builders are limited to common use cases (at least for now), but Thunkable has an entire visual coding system that makes it more robust and flexible.

Drew do you have any resources or tutorials that you have come across to help explain the “visual coding system” with Thunkable?

DT: The coding system comes from MIT and is called App Inventor. I think the Thunkable founders were involved in the project, but not 100% on that. Here’s some info on that (second section is the visual blocks used for interactivity) http://appinventor.mit.edu/explore/designer-blocks
This explainer shows a little of how they work and what it looks like https://www.youtube.com/watch?v=5SMWkUf5VzQ

Did you consider Adalo?

DT: At the time I built this, Adalo was younger and had less features. I ultimately chose Thunkable because I wanted to make something that was completely custom, and I was sure I could with Thunkable. I might have been able to achieve the same goal with Adalo, but I wasn’t sure.
Today, I’d choose Adalo for anything that’s generally straightforward (forms, databases, lists), which is probably 90% of all app ideas. I’d use Thunkable for everything beyond that, though!

When building anything there is always something unexpected that occurred. Can you talk about what surprised you?

DT: Yesterdays Weather got rejected from the Apple App Store because it didn’t look enough like an app.
I did that on purpose. It was a beautiful, open screen with no clutter… just one sentence and nice typography.
I ended up adding the bottom menu bar, resubmitting, and getting accepted. It was actually a good thing in the end, because I was forced to create additional screens, so now there’s a more detailed comparison screen and a forecast!

What was the most difficult part of biggest learning curve for you that you’d like to share?

DT: In regards to Thunkable, the learning curve has to do with the way you program logic. They use a standard visual coding system where you’re essentially connecting puzzle pieces to create code logic (instead of writing the code). As a developer, I really loved the set up, but without already understanding basic coding concepts, it’s likely a pretty big barrier.

What was easy?

DT: If I look at this project as a whole… across Thunkable, Bubble, and Carrd… the whole thing was incredibly easy, relatively. I’ve built all of the pieces for Yesterdays Weather before… in code, in previous versions. The difference in time spent on each part (native app, web app, marketing site) is truly incredible.
The Thunkable app took 2-3 days to get to 95% of what it is today. Same for the web app version in Bubble. The Carrd site was completely finished in one sitting.
I’m usually careful to not brag about short build times. Any real business or worthwhile project is a marathon, not a sprint. In this case, I just wanted to illustrate the contrast with writing code, where each of those would take weeks.

Drew T. can you tell me more about your thoughts on building in Bubble – how was the design and mobile responsiveness difficulty to build into your project?

DT: Bubble’s layout is built in a way that’s different from other drag-and-drop interface builders. It’s built more like a Figma or a Sketch where the focus is the canvas view, as opposed to the published output or underlying code structure. Because of that, Bubble doesn’t have responsive design “built into” their layouts. So when you build with Bubble and then test on a different screen size, there’s often a lot of unexpected results.
The way I overcame this was keeping things simple and learning the couple quirks in how Bubble handles responsive (you can make things flexible width, etc). The other major “trick” I use is grouping things that are related to each other. They seem to reorganize and stack more intuitively when they’re grouped.

What would you do differently building it or something valuable you learned you’d like to share with other Makers? 

DT: I have no regrets building it, and in fact the whole process was really fun. That said, it might have been smarter to put a little more time/effort into the web app. It’s the “free” thing that people see so they buy the mobile app, but it’s clunkier and has less features. I should have, and still can, bring that up to speed with the native app.

Can you tell more about why launch web and a native app? The strategy to use a web app as a lead generator for downloading the app. like a free preview to reduce the risk for the user to download the app.

Can you discuss why you decided to charge money for your native app. and thinking behind it?

DT: That’s exactly the strategy… the web app is free to show off what the weather sentence looks like and what the app experience would be like. Since an app is more convenient, “power users” can buy the app which loads faster, knows their location, has more info, and can get weather anywhere in the world (the web app only works in the US, but that will be updated at some point).
The other reason I did that was to illustrate a more “real-world” situation using nocode… two separate front ends from the same data source.
I chose to charge for the app because my time is pretty limited, and while it was a really fun experiment and build, it’s not something I can continue to grow and maintain unless it’s bringing in money. I figured I’d put a price on it, and if people pay, I can improve it, but if not, no sweat.

Please provide what links to your project website, your twitter, where can people return the love?

DT:
I’m @truedrewco on Twitter
Yesterdays Weather is yesterdaysweather.com
No Code List is nocodelist.co
Work and Whistle is workandwhistle.co

Is there anything else you would like to share or some feedback/request/action that you’d like to ask the Side Project Stack Audience to do for you?

DT: I would love to get more endorsements for specific nocode software on the No Code List. On the site, if you become a member (create a free account), you can endorse nocode tools, and you can upvote other peoples’ endorsements. It’s helpful to people checking out software, and it’s an awesome way for nocode software companies to attract new signups. 

Are there any other tools for the no-code movement that you would be interested in giving insights about?

DT:
 Bildr, which is private beta at the time I’m answering this, is going to have a huge impact on the perception of what no-code is. I’ve been privy to the project and the team for a few months now, and they’re just doing it right. They’ve basically professionalized no-code. I’m very excited to see what happens when it’s public, and I think peoples’ perceptions of what no-code can do will change.