Behind the scenes #4: Love & hate relationship with Google, first hire, and power of focus
In this issue:
Love & hate relationship with Google. We love making fun of Google (for good reasons, it’s totally deserved) but we also love their products that we’re 100% dependent on for our startup.
Our first hire. Yep, read on to learn more about how we thought about equity compensation!
Focus. What we learned from applying to YC and how we’re constantly simplifying.
Subscribe and read on. If you know someone who will enjoy this, please forward the email!
Behind the scenes, vol. 4
TLDR: We’re building a podcast app that will make you fall in love with podcasts even more. Our thesis is that long-form audio is first-class media and is here to stay beyond our lifetimes. We’re on a mission to build the best podcast app that has ever existed for people like us — podcast fanatics who never go on a ride, run, or do laundry without their favorite podcaster voices talking to them through headphones. Read my full LinkedIn post about our values.
We aspire to build a “calm” company and we love sharing how that goes in a “build in public” way. This newsletter and our Behind the Scenes podcast is where we share our entrepreneurial journey with anyone who’s into storytelling about entrepreneurship and product development.
So, what have we been up to since the last newsletter?
Love & hate relationship with Google
We love making fun of Google. If you read my [one, two] posts that compare Google and Amazon cultures (I worked in both places as a PM), you’ll know that I think Google’s products are great yet flimsy and sometimes untrustworthy. I’ve been burned three times by Google now — when they deprecated Google Reader, got rid of Inbox (the best email app to have ever existed!), and sold off Google Domains to SquareSpace.
This said, we have made a conscious decision to build Metacast on top of Google’s infrastructure. It was a pragmatic decision and we stand by it. If Google deprecates any of the products we depend on, skeptics will stay “you should’ve known better” and they will be right. But hopefully, by the time that happens we’ll have grown a company that can afford to move its infra elsewhere. Right now, our priority is speed and Google helps us achieve the velocity we need.
So, what Google products do we use and why?
What follows is an answer from Arnab, our CTO and only engineer. Voice and tone will differ from the rest of the newsletter.
We’re building a mobile app with a substantial backend component. Firebase makes building the app pure bliss. Using Firebase and its NoSQL database, Firestore, we get:
Automatic CRUD API.
Robust, secure and fine-grained access control using rules written in just a few lines.
Automatic and sane offline mode.
Magical, real-time, two-way data sync between the app and the database; which naturally fits into the reactive, asynchronous model that modern apps are built with.
On top of all this, we get a super simple authentication mechanism that integrates out-of-the-box with the rest of the services, object storage, analytics, crash reporting, feature-toggling, and a good set of developer tools. All of that is serverless, fairly cheap, and scales as our user base grows. The best part is that it doesn’t need hundreds of lines of configuration files, even though everything is managed as IaC (Infrastructure as Code).
Both of us have been inside AWS, and have used AWS as outsiders. AWS is highly configurable, and offers a much broader set of services and features. However, harnessing the best of AWS does require a broad understanding of it and involves a lot of upfront development work.
AWS is “highly configurable,” but it needs to be “highly configured!”
The developer (in a devops engineer role) is in charge of configuring every nitty-gritty detail, ensuring different services connect and work with each other, and in a secure manner. For example, for a similar set up as above, we would have had to set up an API Gateway with ~15 endpoints, 10+ Lambda functions, DynamoDB with streams (and Lambda functions to emulate a data-sync feature), Cognito for authentication and more… we’d need to ensure all these services work with each other, using IAM policies and CDK/CloudFormation! Oh, and even after that, we would need to custom-build some features like the offline mode, feature-toggling etc.
This is so much work that it makes it impractical to build our startup with our solo engineer.
So… dear Google, please don’t kill Firebase.
Flutter is a cross-platform app development framework that lets us build an iOS and Android app from the same codebase. You read it right — we write code once and get two apps. We had to do some configuration for Android/iOS separately but the application code is the same. It works great and we’re super happy with the productivity gains we’re getting.
We could’ve used Kotlin (for Android) and Swift (for iOS) and the app would’ve been a bit more more “native-looking” on those platforms, but that would have needed us to also reimplement and maintain all our features in two completely different frameworks, using two different dev tools. And this is all in addition to the backend and ML work we are already doing. Clearly, it’s something that we can’t commit to with the engineering resourcing we’ve got. And with Flutter, we can reuse the same application code-base for the web app and desktop apps, if we decide to go that route some day.
Flutter has an amazing open-source community around it, but it needs Google’s continued attention and support to thrive.
So… dear Google, please don’t lose interest in Flutter.
Ok, I (Ilya) am taking over back from Arnab here…
We use Google Workspace for email, scheduling, meetings, docs, spreadsheets, forms, file storage, and email groups. We could’ve used Microsoft Office 365 or some other tools but we’re so used to Gmail and Google Docs that picking Google was a no-brainer.
The added convenience of Google Workspace is that we can use single sign-on (SSO) for our infrastructure and developer tools — things like GCP, Figma, Bitrise, etc. Also, the scheduling feature in Google Calendar is free for us, so we don’t need to pay for Calendly. Google Meet allows us to not pay for Zoom.
There’s a clear savings advantage in buying a bundle vs. individual productivity products even when quality of the Swiss army knife bundle can be a little lower than that of standalone tools. The only exception is Google Chat — having used it at Google for 3 years, I don’t see us giving up on Slack.
Dear Google, please keep Google Workspace up and running, but if you want to kill it, you’re welcome. It’s not a critical dependency for us, there are other options.
Get weekly stories from the trenches of building a startup from scratch
Funding the startup (shameless plug)
We’re going to do an internal crash course in Flutter and may open a few spots for external participants. We’ll probably do it over two days, each session will be 4-5 hours. Arnab will teach how to create a new Flutter app with a backend in Firebase from scratch.
The cost will be around $400 per person and there will be a 100% money-back guarantee since it’s the first time we’re doing something like this.
If you’re interested, please ping email@example.com for more info.
Our first hire
Someone who we know very well will join our startup soon. They’ll work for equity only until we’re able to pay salary and it took us quite a bit of mental effort to figure out the framework as to how we can compensate someone who joins a non-VC-backed company at this stage. We’re at a point where we’ve been building the product for a while and it’s in closed beta though we’ve not yet shipped it to the market, we don’t know if our pricing model is going to work, and frankly, there’s still a lot of risk.
We’ll record a podcast episode to discuss our process in more detail. Today, I’d like to share a few things that helped us make the decision and establish a framework for our company.
Equity for Startups by Joel Spolsky. This is an amazing read that puts risk for everyone joining a startup into perspective depending on the stage they join at. The later you join a startup, the less equity you get; money and equity discussions must be explicit; etc. It’s a very helpful read for everyone who thinks about starting or joining an early stage company.
Buffer’s Equity Formula. Buffer has created a compensation framework that we’ve adopted as well. We modified some of the multipliers and introduced additional variables to account for the stage of the company and lack of cash compensation at the early stage. We intend to use this framework for everyone who will eventually join Metacast.
Personal network. We spoke to someone we know about how they do equity for their startup. They introduced us to both of the articles above and walked through how they do it for their employees. This was very helpful because we had a reference point and it helped us make sure we actually understand Buffer’s model. If in doubt — ask for help!
We’ll save specifics for a podcast episode. It’ll be a meaty conversation. Subscribe to our podcast wherever you listen to podcasts to get notified of the new episodes. Links to our podcast on most popular apps are here.
Earlier this year, we applied to Y Combinator’s Summer 2023 batch. Didn’t get in. Didn’t even get an interview.
However, the preparation process was very helpful. Their application form and video/demo requirements are very thoughtful — they require you to take a step back and focus on what’s important for your users, your business, and you personally. By going through the exercise, we were able to understand what stands us apart vs. what is a commodity. It also helped us perfect our pitch.
Even though we thought of ourselves as pretty focused, every now and then, we find ways to focus more and do less. Part of that is that we’re learning what’s not working and stop doing it.
Here are a few focus improvements we’ve figured out recently:
Social media is not made equal. We’ve reduced our presence on social media. We no longer spend time on Instagram, TikTok, Threads, Twitter, and YouTube Shorts. We focus exclusively on LinkedIn with the hypothesis that our target users for the app will be on the nerdy side. On LinkedIn, we are able to reach engineers, PMs, designers, etc. working in tech.
Our podcast is not a marketing channel, it’s a community channel. We’d treated the Metacast podcast as a marketing channel but it wasn’t really doing its “marketing” job (i.e. driving awareness) well. We’re now thinking of the podcast as more of a “user radio” broadcast channel where users of our app can get connected with us and the work we’re doing. The hypothesis is that people will be more likely to fall in love and support an app that has a mission and a face. It’s kind of similar to buying a “vegan” wallet from a mission-driven craftsman vs. a faceless Louis Vuitton purse.
We’re becoming even more pragmatic. We made a few pragmatic decisions like using CI/CD and building on Flutter + Firebase. Recently, we had a buy vs. build decision for a key piece of our platform and we decided to buy rather than build because it was not our secret sauce and we can save time by outsourcing non-differentiated work to a third-party solution, at least for now.
Latest podcast episode
Our latest episode is a bit schizophrenic. We started with a warmup about positioning ourselves to the world and got carried away talking about that for 20+ minutes before switching to the topic we initially wanted to talk about — the tools we use for our startup.
Coming up next
An interview with Melissa Kwan, co-founder and CEO of eWebinar, will come out in episode 36 of our podcast on Wednesday, Sep 20. It is an interesting conversation where we got to hear a perspective on building companies that’s very different from ours. I’m personally looking forward to re-listening to our conversation with Melissa and reflecting on it.
A conversation with our new hire. Once our new team member starts on October 2, we’ll record an episode and do a write up about the whole process. It’ll be fun.
[carryover from last week] The failure of our ads campaign for the book. We ran a Google Ads campaign for a week to sell The Pragmatic Podcaster book. Made exactly zero sales with $70 spent. Note for self: double-down on Amazon!
Support our journey
There are a few ways you can support our nascent business.
Subscribe to this newsletter
Forward this email or our podcast to a friend
Buy The Pragmatic Podcaster book or gift it to someone
Buy a t-shirt on our merch store