After all the interpersonal drama, we’ll have something more light-hearted today. Späti Guide is a compass that always points its needle to the closest “Späti” still open. According to Wikipedia, a Späti is an East German convenience shop in cities like Berlin, known to operate late at night past the usual shopping hours. As such, it’s frequented by Berliners like myself in 2021 to grab a late-night snack or drink. I recommend Sterni, which offers insane value at 0.50€ for 17oz in 2021. Mileage after COVID-19 inflation may vary.
Product Learnings
I decided to build this app because Google Maps had terrible information on all the Spätis in Berlin at the time. You had to search through five different search terms to find all the stores that might fall under the term Späti, and even then, they never had any accurate opening hours. My goal was to consolidate all of this information by going through many different Google Maps searches, which already solves one of the problems of existing solutions by giving you one accessible overview of all the stores near you.
The second problem is the opening hours. I wanted to use Cunningham’s Law and decided to give every store default hours. Someone seeing them in the app and realizing they are wrong could hit edit and change the time. The edit feature did not immediately change the values in the database. They first get put into a review queue for administrators.
Every app user gets a credibility score. If an admin approves your edits, your score goes up. After a few successful edits, your edits no longer need approval. My plan was that this way, the edits would slowly but surely lead to an independent, accurate database.
Tech Learnings
The main reason I started building the Späti Guide app was an upcoming job interview. The next Monday, I had an interview scheduled for a freelance project that used Flutter, AWS CDK, and Lambda. I had never used those technologies, and on Friday morning, I decided to spend the weekend using them to build the app idea I had been thinking about.
Working with Flutter and Lambda for the first time was fun, and I quickly got the hang of it. Dynamo DB took me a while to wrap my head around, but I made it work eventually. CDK is the only technology I used during this project that I would never use again, simply because I never saw the need for it in my projects, and none of my clients ever used it. I prefer Terraform because it works outside of the AWS ecosystem. I know infrastructure as code differs from infrastructure as YAML, but I never felt the need to switch.
The Google Maps API is very expensive. I wanted to crawl all of Berlin for a few different search terms for Spätis, and I decided to use Puppeteer rather than the official Google Maps API. That turned out to be an excellent idea. A friend of mine had already used the official maps API in the past and decided to give it a go. We were crawling the same area with very similar search terms. Afterward, we joined our data sets to create the database for Späti Guide.
My puppeteer approach was free, but his SDK approach was not. Both approaches violate Google’s TOS because you’re not allowed to store Google Maps search results in your database. You’re supposed to crawl the API every time a user requests data.
We both ran our crawler overnight. After ten hours of crawling, we gathered the same data, but while my script ran for free, he woke up to a $8,000 bill from Google. That’s a big number. Luckily, Google forgave his GCP bill on a one-time exception after he explained that a coding “bug” caused the usage to spike. Fortune favors the bold.
Marketing Learnings
Silicon Valley hates marketing. Rebelling against how people do business in traditional non-tech industries, Silicon Valley startups prioritize products and have a build it, and they will come attitude. This attitude makes the sector disruptive, though the pendulum might have swung too far. Completely ignoring marketing is a mistake, and the best companies achieve a balance between product and marketing¹.
I fit that bill perfectly. In 2021, my marketing skills were a clean 0/10. I kept thinking about new products and building things but was far from developing a working go-to-market strategy. Späti Guide is an excellent example because after putting it into the App Store, I did nothing to advertise the product.
Frederik Riedel is a very close friend and was my neighbor then. His app, One Sec, had just launched when I was working on Späti Guide. He had gotten a lot of traffic from TikTok videos he made for his app, so he strongly advised me to do the same for Späti Guide. I thought, “Why not?” and gave it a shot. The two or three videos I made were the only marketing for Späti Guide, and the app’s metrics reflected that lack of effort.
TikTok is a game of consistency and time, and I didn’t play that game. So naturally, those videos were seen by 72 people, and none of those converted to downloads. The app did have a handful of users and even one or two database edits that I approved. That was all Späti Guide ever amounted to—about a dozen users throughout the app’s lifetime.
Since the TikTok videos performed so poorly, I can only imagine people found my app through the App Store search. The App Store is a sub-par marketing strategy, but it’s not nothing. I know people whose apps got millions of downloads without ever doing any marketing, solely off of App Store presence and getting featured in some of Apple’s spotlights. I think it’s deceiving to know that this tool is out there. Since there is some consistent traffic getting to your product, you can tell yourself that you don’t need to do any additional marketing.
If the app’s out there and people can find it, that’s it. Job done. Having 0 time spent on marketing and still getting some, even very little, attention is an unbeatable value proposition. This lazy auto-pilot thinking is dangerous, and I must force myself to change my approach. Just like cleaning the sink is a part of doing the dishes, doing marketing for the products you built is part of building apps. That’s a learning I’m still working on in 2024, and I’ll continue to improve over time.
Conclusion
At some point, I decided that hosting the domain späti.guide was no longer worth the cost. I had hosted the app with a serverless architecture, so I didn’t incur additional hosting fees, considering anybody was using the product.
There was one primary reason why I decided to give up on the project. I could’ve improved and fixed the lack of marketing, and the product did work. So why shut it down? I had one critical interaction with my local Späti near Hobrechtbrücke, Berlin. I was trying to add my local Spätis’ opening hours to the app, improving the data accuracy. I asked the grumpy man behind the counter, “What time are you open until today?”
And he said, “I don’t know.”
It turns out Spätis doesn’t have opening hours. They open and close whenever the owner feels like it. Creating an app that does its best at cataloging the most accurate hours of all Spätis in Berlin will still be wrong a lot of time time. It will be wrong when it really matters. If a Späti that’s half a mile east from here is usually open til 3 am, and it’s currently 2.30 am, and there’s another one 0.6 miles west with the same opening hours, the app will let you down a lot of the time. There’s a very high chance that one of the two locations decided to close early that day, and the app will lead you astray. That’s a fundamental flaw in the app’s core functionality and can’t be fixed. So, I decided to give up on this side project and move on to the next.
¹: I first read that opinion from Peter Theil or Andreessen Horowitz. Maybe it’s a YC post. If you know who wrote about this sentiment first, please let me know so I can link it here.