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!
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.
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.”
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.
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.
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
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!
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!
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.
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.
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.
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.
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.
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.
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.
Learn how to build in no-code and become a freelancer, build your own startup or change your career into no-code web development.Check it out
I started Side Project Stack to help Makers reduce the time and effort to make stuff with no-code.I launched Get Stackd. A former #1 Product of the Day on Product Hunt. It helps Makers find the best no-code tools to use to make something. It's a 100% automated web app built with no-code.
What's interesting about it? Get Stackd take's the data from over dozens and dozens successfully made no-code projects to recommend the best starting point of tools to use to make your idea. I hope that you try it out. It's perfect for just starting out.Ill be adding more to the no-code space.
If you'd like to stay updated you can sign up for the newsletter and join over 3,000+ Makers getting the best insights on no-code and product management. Thanks for reading.
Once a week, valuable and actionable insights, no bs -- promised.