Part 2: 8 Months of Humility

Contractors, Imposter Syndrome, and the Not-So-Fun Stuff

This is part 2 of a two-part series about Wanderly's recent go-to-market pivot. Part 1 focused on Wanderly’s pivot to becoming a book publisher, and part 2 is all about the journey. 

And if you enjoy my writing, please help me out by downloading Wanderly from the App Store or Play Store and leaving a review or rating. 🙏¹

Late last year, I decided that Wanderly needed to become iOS and Android apps:

• Many parents desired the safety of mobile apps for their kids (for example, the app stores have a review process, apps can be put on a “kids” tablet with no browser access, etc.)

• Being a website made many users intuitively assume Wanderly was just for desktop computers, even though it worked well in a mobile browser. That really limited where and how people would use Wanderly!

• It was hard to get people to come back. One of the primary reasons people canceled their Premium accounts was “I forgot about it.”²

I thought porting my web app (React) to iOS and Android (ReactNative) would be relatively easy. Sarah, the engineer who helped me write the initial front end of Wanderly, had been wonderful to work with, so I reached out to Toptal again. I was quoted 6 weeks to port Wanderly into iOS and Android apps... 8 months ago. But the apps are live! And I have a whole new go-to-market strategy!

Here is how I got there:

Building a startup is a rollercoaster

Both the Toptal Engineering Director and the contract developer quoted me 6-8 weeks to port my app. Starting at the end of November, I optimistically thought I’d have Wanderly ported by mid-January.

By mid-February, the contractor I was working with (who was much less interested in collaborating and explaining his code than Sarah) explained he had a personal emergency and had to move off the project. He put me in touch with a friend who seemed to live with him, and he assured me his friend was even better than him. I felt trapped without knowledge of the codebase and thought I just needed a few more weeks to be ready to launch, so I fell for it. By April, I cut my losses after I had my contractor’s successor walk me through how to build the project on my own and create an app bundle. I hoped I only had to port a couple of new things, and I’d be ready to launch in a couple of weeks… I was so wrong. 

In graph form, this is roughly how things played out:

Some things to note from the above graphs:

• 8 months is way too long to think you’re only 2-4 weeks away from launch. It weighs on the soul. 😩 Part of this was due to optimism, but also, the estimates I got from Toptal did not include any of the work needed to actually get the apps live on the stores. 

• In retrospect, I worked with the contractors for way too long. My imposter syndrome got in my way and prevented me from taking over earlier. 

• I shouldn’t have let the contractors keep me in the dark for as long as I did. It only led to more imposter syndrome and delays. I wanted to “trust the process” and give the contractors the autonomy that I used to give my engineers at Google, but the incentives for contractors are completely different. I won't be so naive next time.  

• When people talk about the rollercoaster of startups, these kinds of graphs are what I imagine they mean. 🎢

For the book pivot, the work was much shorter and a lot less complex. It mostly required a leap of faith to print a book, new marketing content, and a little Python script to generate the book's PDF. I imagine most pivots are like this: staring you in the face and relatively easy to try. The hardest part is the mental challenge of questioning your own assumptions, admitting you were wrong before, and the optimism to try something new. 🤞

It’s never the fun stuff that takes a long time

Over the last eight months, I didn’t spend time the way I was hoping. I don’t think I spent it poorly; I was just hoping to have a lot more fun. For me, fun is designing and building new features and satisfying user requests. Instead of doing that, I spent the majority of my time working on marketing and infrastructure. 

I don’t think I could build a real company if I didn’t spend some time this way, but I underestimated how much time it takes to build a real business and app from scratch, and it was painful to have an ever-growing list of product ideas I couldn’t build yet. 

Another missing element in this pie chart is raising/managing investors. I’m still bootstrapping Wanderly, and I think most startup founders spend a significant amount of their time on fundraising. While bootstrapping is the right answer for me now, after laying out how I’m spending my time, it’s good for me to self-examine if this is the best use of my time moving forward. 

The good news is that much of the work I’ve done is an investment in the future, and hopefully, now I can focus more on the fun stuff. Whether Wanderly works or not, I now have code samples that I can reuse for push notifications, app subscriptions, continuous integration pipelines, etc. I can carry this investment forward with Wanderly or port it to a completely different idea in the future. 

Trust your gut, do your research, and have a squad

Over the last 8 months, I also learned a lot from my mistakes. In case you ever find yourself in a similar situation, I hope these things below will save you some time and heartburn:

• Trust your gut when it comes to contractors - When I met the first mobile contractor in Nov ‘23, I didn’t get instant positive vibes. But I thought I didn’t need a partner at this stage; I just needed someone who could do something somewhat mechanical. I should have realized unexpected things always come up: you need a partner no matter what. As time went on with both contractors, the results didn’t feel great, but I second-guessed my gut again. Once I took over the code, I found countless cut corners, a lack of attention to detail, and poor implementation strategies.

• Pattern match existing solutions, and do your research - I wasted the most time trying to fix something that already existed. I was the most efficient working on tasks where I paused to think about first principles and best practices before diving into code (often collaborating with an LLM for engineering design advice³). The most salient example was that the contractors and I ended up rewriting Wanderly’s subscription payment system 3 times. First, we built a full Stripe integration before realizing that I couldn’t use Stripe for digital content subscriptions on the app stores. Second, the contractors tried pursuing a free but homegrown solution that was complex and buggy. The third time, I rewrote the entire subscription system in 4 days using RevenueCat, a tool specialized for in-app subscription management. They’ll take a cut, but it’ll be champagne problems when it actually matters.  

• Budget at least 1 month for productionization - When I was at Google, where I led 4 products from 0 → 1, I always budgeted at least 1 month for productionization (i.e., going from feature complete to end-user accessible). Why I didn’t remember to follow my own advice this time, I will never know. 

• I should have done more go-to-market testing - I’m still short on go-to-market proof. I have early signs that the book pivot will be successful, but because I only started the experiment last month (via a painted door test), I’m still not sure if it’ll work. I have found it very hard to split my time between coding and go-to-market work. But if I had spent earlier time on go-to-market experiments, I probably wouldn’t have had such an emotional rollercoaster the last few months. 

• Every founder needs founder friends. When I had my really bad day in May, I was lucky enough to have a couple of friends text me. Two of them were founders themselves, and they reassured me that as long as I was investing in solving Wanderly’s top growth blocker, I was doing the right thing. They also shared the times they’d been crying on the floor about their own now-successful startups. Because I had these folks in my network, I was able to get back off the ground quickly and get back to work. Every founder should have a roster of folks to call when things get hard. 

• Every solo founder needs a squad - To launch an app or anything really, you need to have a number of close people who are willing to test your app and a) give you the nitty gritty feedback you need to hear and 2) are willing to go above and beyond to debug issues with you. At Google, we had testing teams, or on my smaller teams, we had bug bashes where folks would hammer on a product before launch. As a solo founder, no one is financially incentivized to help me find issues in Wanderly. Thankfully, I have a few people in my network who were willing to test new builds at 10 pm at night, send me logs, write out a list of bugs with screenshots, and more. They’re heroes in my book, and I can’t imagine having launched this pivot without them. 🦸 🙏

So, from here, I have 2 new apps and a new go-to-market strategy, and I’m hoping things continue to grow from here. If nothing else, I’ve learned a lot and invested in the future. Now, it’d just be nice to have it pay off. 🤑

If you enjoyed this post, please help me out by downloading Wanderly from the App Store or Play Store and leaving a review or rating. 🙏

1. Thanks so much to those of you who have done it already! I've gone from the #5 search result in the app stores for Wanderly to #2 since my last post, but I'd' love to be #1!

2. Technically, I could have tried enabling Wanderly as a progressive web app with notifications, but it's just not the same.

3. I find that if I ask an LLM for advice on a particular problem when I already have an approach, its response will miss the forest through the trees. I have the best results when I say something like, "Here's a problem I want to solve. What are the best approaches for solving that problem?" even if I already have an inclination about the solution. I have a post-it note on my desk reminding me to start high-level first on every new task.