What is Slopes? Think Nike+, Runkeeper, Strava, MapMyRun, etc for skiers and snowboarders.

Monday was a pretty big day - Slopes is now employing 12 people full-time (not that 12 is a particular number of interest, but we just crossed the 10 people threshold mid-May, so I figured I'd wait until now to write about it 😅). Hard to believe that just 3 years ago I was writing about hiring my second employee and my concerns with too much growth going forward:

It's an easy trap to fall into, to keep chasing growth. You start to feed that cycle innocently enough because you need more people to keep up with work, and then you have to chase bigger and bigger things to keep that growth % up next year to support costs, and then you need more people to keep up, yada yada. Suddenly you look around and realize you have a team of 100 on payroll that you're responsible for.

This caution has been a driving force for me behind every hiring decision I've made: growth begets growth, work will find a way to fill all voids you provide it with increased staff. Growth can be the path of least resistance, and you need to actively and intentionally manage that.

I am still determined not to fall into that trap.

I think around 12 people is that Goldilocks business I've been aiming for (I'm capping head-count at ~15; I'm sure we'll still need at least 1 additional support person and that leaves room for 2 more unknown hires above that). We finally have 1 engineer per platform (web, iOS, Android) full-time. That second employee I wrote about has transitioned to a "Chief of Staff" role (a mix of operations and EA-type-stuff), freeing me up to focus more on product and less on ... payroll and taxes and process.

These two changes take a lot of pressure off of me; now something can move along even when I'm not actively working it. I don't have to bring Project A to a halt to ensure Bug Fix B sees progress. After being the bottle-neck for everything for 12 years, lemmi tell you how freeing that is. I get to spend my time designing and building things I'm best-suited for, focusing on making sure Slopes stays special.

Not only is the lack of "I'm the bottle-neck" pressure nice, but I've finally able to support a ton of the ambitious projects I had in mind for Slopes back in 2013.

And some new ones.

A fun problem our GIS team trying to solve? Trees! Yes, trees. A lot of the data out there for trees is ... lacking, at best. For example, Killington Ski Resort used to have a big square (like 1/3 the size of the resort) removed from the middle of their trees. Outside the bounds of most Colorado ski resort the trees just ... disappear. In places where tree data does exists, it can be pretty low resolution and over-simplified.

This is why Apple Maps did their own thing a few years ago to run satellite photos through ML to detect stuff, like trees & over vegetation, golf cources, baseball fields, even little side-buildings in someone's yard.

We prototyped this project at a smaller scale last season for our first partner resort in Japan (I really need to write about that) and it looks amazing. But a great A vs B example is Breckenridge, Colorado. The left uses the default tree layer that's out there (trees are in green), and the right is output (trees in yellow) of ML analyzing  imagry for tree clusters where the trees are >1 meter in height.

We're gonna have to simplify the polygons a bit on our output, otherwise RIP our hosting bill, but this makes the resort maps look so much better. And outside of resorts, like in the backcountry, it will help a ton for visual wayfinding and planning.

Now the goal for next season is to roll this out as close to world-wide as we can. First step is buying the $8,000 (!!) computer to churn through all this data at a larger scale this week, else we'd probably set fire to Lydia's laptop.

Sorry, I'm done nerding out on mapping. 😅

One other aspect that keeps my hiring in check is our revenue cycle. From April-Nov the revenue flat-lines, meaning we don't have a ton of leading indicators through the spring/summer/fall for how the next season might go. I've gotta make sure what's in the bank account in May will last us until Feb of the following year (when Apple finally pays out for December, our first big month).

We keep growing at a consistent 40%+ (overdue revenue update: 2025 so far has made $3.6mil gross, will probably cross $5mil), but I never plan on future growth for any future spending. I always allocate funds, be it for hiring or marketing spend or anything, based on what we earned last season. If last season can't cover it, we don't do it.

Sure, I'd probably be a little bit ahead of where I am today if I was more aggressive with spending the money I have and planning around assumed growth (a fun what-if I play in my head sometimes), but especially now that our payroll is over $1mil USD/yr (!!) there is no way I'm taking the risk of people's livelihood based on just a guess at growth numbers.

(By the way, I recently switched over to Fathom for my revenue predictions / runway estimates to help me manage spending especially during that April - Nov timeframe. Working out pretty well so far and it integrates with Xero (my book-keeping software) to automatically keep things up to date. Much better than my old spreadsheets approach. Give it a look if that sounds useful to you.)

So yeah, fun times. We're a company with an org chart and team directory now 🤮. But we're trying our best to preserve the indie-small-app-small-team culture and not lose what we love about doing this.

'Cause that's the nightmare situation: turning Slopes into something we (I) hate and don't look forward to showing up for.

I'll be honest, had I not hired these engineers and gotten a Chief of Staff, I might have personally been on that trajectory (ok, "I was" is the proper phrasing, but I'm in denial ok!). I've been feeling the weight of having so many customers, a business that's growing to this size, managing a bank account with such seasonality, and so many responsibilities. I've been feeling burnout creeping in.

If you're considering hiring, they always say the first hire is the most intimidating, and it is. But looking back I feel like things really shift after 3-5 people, that's when it starts to feel like a lot.

But I will say, I'm glad I stretched myself thin and hired engineers last (besides the part-time Android engineer who has built that version of Slopes since 2020. Which by the way, he's gone full-time!). It's kept the product relativly lean and made us focus on the infrastructure (customer support, resort data management, GIS, etc) needed to support an app like Slopes. It's made us pick the most impactful features to focus on as we went, vs building everything and the kitchen sink.

But hopefully now, we can really get moving.

What is Slopes? Think Nike+, Runkeeper, Strava, MapMyRun, etc for skiers and snowboarders.

Oh boy, it's been a spicy few months in the Apple ecosystem 🍿.

Ever since the EU alternative payments ruling a while ago, and especially now with the injunction in the US opening the web payment floodgates, I've had people asking me about what I intend to do with Slopes and Apple IAPs vs web-based purchase flows? To answer that, I need to take a step back and explain why I've long-held the opinion that IAPs weren't just a "3% credit card fees, so they're charging us 27% for hosting and bandwidth!" situation.

There are two things Apple provides as part of the IAP system that has always been undervalued, and in my opinion they are well worth that theoretical 27% (or 12% on subscription renewals).

Banking, Taxes and Compliance

I don't think most developers realize how much of a PITA it is to sell internationally.

Slopes is a global app, with only 60% of its business coming from the US. If I wanted to sell with Stripe today I'd need to register in many of the countries/states we have a presence in. Each country has a threshold of sales where you don't need to register/report; sometimes that's a volume of transactions and sometimes it's sales volume. But if your app has any international traction you'll hit those thresholds quickly.

Once you do, you have to worry about keeping on top of each countries' various reporting requirement about sales, and then submitting tax payments to them. You'd have to keep adjusting IAP prices as tax rates adjust in each country and make sure you're collecting taxes on every sale. Sometimes all of this may have a cost associated with all this (lawyers, etc), but it's guaranteed to have a cost on your time.

Thankfully Stripe just announced they're going to be offering a service to become your merchant of record in many EU countries (hopefully expanding to Asia over time?). They'll handle tax compliance, fraud, bank disputes, and all the other "selling products directly to customers" BS that Apple shields us from.

We don't have any pricing on that service yet (it's in private preview at the moment, so those details are pending), but a similar service like Paddle charges 5% + $0.50 per transaction. On Slopes's yearly plan that equates to 6% of each sale. If you're a $9.99/yr kinda app, that's 10% per sale. If you charge monthly ... that $0.50 will add up quick.

We also don't know how Stripe will deal with chargebacks on our behalf, but Paddle has a $15 fee (+ the original transaction value) for every chargeback dispute lost. And you need to keep your chargeback rate at <0.65% of your sales volume per month or else Paddle may "make you make changes."

Transitive Properties

The biggest benefit I've always seen to relying on Apple for IAPs is that Apple's hard-earned trust gets extended into our products. I've long-argued that if we could measure the conversion rate difference between IAP checkouts and web checkouts, IAP would beat web by more than enough to make the 30% fee worth it (not to mention the long-tail of subscription renewals on those checkouts, at 15%, or if you're making < $1,000,000 USD/yr and in the small business program also at 15%).

Today, numbers are starting to come out from people who initially jumped on the alternative-payment checkout options strategy showing just that: a 25% - 45% drop in conversion rate between IAPs and web-based.

(Keep in mind that's without adjusting for the additional 3-6% you'd pay in fees for web checkouts. That's the conversion rate, not your effect on earnings %.)

(Also keep in mind, as the video of the checkout process on that page shows, this is likely as smooth as the flow can get. This does not have the scary screen Apple added in the EU about "leaving to an untrusted external payment platform.")

And it makes sense: customers don't know us. Why would they want to trust some random app with their credit card number (not to mention entering that information is work)? They have no idea if Slopes is going to make you call a 1-800 number and sit on hold for 20 minutes to cancel your subscription, or if Slopes is actually going to take all the steps needed to secure the credit card information and prevent leaks. In a world of increasing scams and PII leaks, people will pause to consider things like this.

Remember, your goal when trying to convert a sale is to try to cause as little friction as possible. Make the user think as little as possible. "Enter your credit card information for this random app to start your free trial" is hardly frictionless compared to IAPs.

Services like AirBnB / Uber / Netflix have no problem grabbing credit card information because the customers already want or even need those apps. A lot of us don't have that advantage, we aren't big brands with high intent-to-convert users where you can force that on them. Hopefully we have good word-of-mouth, and those new customers will likely convert at the recommendation of their friend. But for everyone else who is just stumbling on your app, they'll think twice, or abandon checkout due to sheer laziness. And that's what the numbers are showing.

(Aside: I'm a little worried to see that the answer to this problem is "offer a discount!" Sure, it works to bridge that conversion gap, but devaluing your product is not a long-term sustainable solution here.)

Earning Trust

All that said I don't think the answer is to give up on web payments; we just need to look at them through a different lens.

Today, we offer free trials to give our products a week to prove our value to the customer. We don't just say "we're worth it, trust us!" like we used to with paid-up-front apps, we take a week to show them. And it works! It's a lot easier to convert this way than it ever was with paid-up-front apps and a splashy marketing page.

We need to treat the movement to web payments the same way: you need to first earn their trust, then you have a chance of moving them to a payment provider you choose.

The way I'm looking at all this is that IAPs are the best way to gather your first payment from a customer, especially if you have a free trial. They'll provide the least friction and highest conversion rate. From there, after you earn a customer's trust over time, you can try to move them over to the web, likely from other flows like emails. Maybe you have a black friday sale with a one-time discount to move them over. Maybe a year after they first subscribe, you offer a one-time 15% renewal discount if they move to web. Maybe you leverge the web to try to win back people who have churned out, or people who abandoned checkout.

There's a lot to experiment with here, and a lot to learn, as an industry. Just like you needed to experiment with things like the best time to show your paywall, you'll have to experiment with when's the best time to try to move them to the web.

Here's the spicy takeaway for me, though. This might just let us answer the big question we've long been unable to answer with anything but speculation: it looks like Apple's IAP service is worth their 30% cut (and without a doubt worth the 15% on renewals & 15% small business program devs). And I don't see Apple lowering their cut due to "competitive pressure" in that situation, the numbers are working in their favor.

I am very curious how the next few months/years will play out.

What is Slopes? Think Nike+, Runkeeper, Strava, MapMyRun, etc for skiers and snowboarders.

After working nights and weekends since April, Slopes 1.0 launched on September 24 2013.

The launch ... didn't go exactly as planned.

A last-minute bug I found + the old app review snail-pace meant I missed the iOS 7 launch-day by almost a week. That delay compounded my launch-fun: I had a cruise (meh) in Alaska (awesome) planned for the week after my (original) release date to celebrate. This left me hitting "go" out in the Pacific Ocean on spotty metered satellite internet, disconnecting and reconnecting every ~30min to save bandwidth but still check if I got any traction. I had been working towards a big unveiling since that kind of launch was the life-blood of a paid up front app and frankly how all the cool apps did it.

My refresh-monkey'ing on the Pacific Ocean would leave me disappointed. It'd take me ~9 months to get my first press coverage, largely out of "wait, no one has written about this app yet?? This looks like a great app even if I don't ski!" pity (thanks Brett Terpstra). 😅

To say I wouldn't have expected Slopes to be where it is today, 10 years later, is a clichéd understatement.

What is Slopes? Think Nike+, Runkeeper, Strava, MapMyRun, etc for skiers and snowboarders.

I've been thinking a lot about a problem we all face time and time again: one of our favorite apps dies. Too often though it isn't a true case of blinking out of existance, it'll be a "death of what we knew and loved" – either through a pivot or an acquisition / acqui-hire everything starts to change and we no longer recognize the original qualities that made us love the product.

Specifically the recent update to 1Password has me reflecting on how I can best avoid this for Slopes.

For context, 1PW started 10 years ago an example of delightful native software on iOS + macOS, and is now instead a bland Electron cross-platform app that is chasing that addictive enterprise-market money, a pivot which has left many of their original core users feeling abandoned. This post, though, is not an internet-rage on them.

See, here's the sitch - 1PW has Apple, who thanks to their auth team has been doing a great job making authentication suck a lot less on iOS / macOS, so much so that I'd argue 1PW for the average consumer on iOS is almost unnecessary. With a team of 500+ today [1] at 1PW (~100 the year they took their first round of funding [2]) that threat from Apple feels pretty risky to ignore. That's a lot of employees to support and Apple's system-level tools are gonna eat into 1PW's consumer growth more and more every year. So their choice to raise some money and get into enterprise software to hopefully become entrenched as a passwords / secrets management service seems like smart business to me.

I genuinely don't think they did the "wrong" thing, even though they are losing me as a customer. Sure it meant building enterprise software (🤮), but it's better than laying off employees because Apple is chipping away at their customer base from one side and LastPass (who also raised a ton of money) is eating the base from the other.

But just 'cause they didn't do anything wrong doesn't mean this outcome was inevitable. I personally think there is room, even in today's market, for a smaller password management app. A business that could support 1-4 full-time people. Said app doesn't have the audience of today's 1PW, but that scale of app did exist in the beginning. The team just chose to grow beyond it.

Managing team size is a challenge, though, because so much of what is around us as founders pushes us away from smaller businesses: "unicorns", "exits", needing constant growth year over year, big ideas that have to "change the world" (was talking with a friend a few weeks ago who was lamenting that a coworker was told to change their pitch deck to be more change-the-world-big in order to raise funding 🙄). As a founder you have internal pressure too because more growth means more employees, which means you can do more. "But if we can just hire 1 more developer, we can finally do X."

It's an easy trap to fall into, to keep chasing growth. You start to feed that cycle innocently enough because you need more people to keep up with work, and then you have to chase bigger and bigger things to keep that growth % up next year to support costs, and then you need more people to keep up, yada yada. Suddenly you look around and realize you have a team of 100 on payroll that you're responsible for.

Left unchecked you may stop worrying about building the best product, and you instead focus on building the best business. It is a subtle subconscious switch, but it'll have massive impact on the product your customers use.

To counter this, one thing I've realized with Slopes is that time is one of my greatest resources.

I might be the solo developer building the iOS app + watchOS app + and PHP backend, but over the years I've built a product that rivals those from many teams. Just like we all tend to over-estimate what is needed for an MVP, we're even more likely to overestimate how much we have to ship every year to keep customers happy. If you aren't in what I'd call a "unicorns-only market" niche, and you're decent at being nimble / focusing your efforts in the right places, odds are you can ship more than enough with a small team or even just yourself.

It's easy to get caught up in the priorities of the month / quarter / year, the sense of immediate urgency, and lose sight of the fact that we do have time as a resource on our side. In those cases I try to take a step back and play my choices out over the long game – 2, 5, 10 years out. You don't have to have a roadmap that far out, geez no I fly by the seat of my nonexistent pants, but I always try to consider how I'm impacting my future-self. What burdens or risks are you putting on my future-self? Does this fire I'm putting out actually matter in the long-term? What pieces do I really need to put in place today to help myself next year?

9 years in and I'd argue being small and nimble with a focus on future-self has been a huge strategic advantage for Slopes. Sure it took me this long to get to 1.25mil ARR and I could probably be at 2mil+ by now had I taken more risks and over-extended with confidence (hiring sooner / etc, I play it very conservative), but I'm sure I wouldn't be shipping the same product. That "Slopes" would be serving the business needs, not the business existing to serve the product.

Don't get me wrong I certainly watch my growth metrics, write and tweet to share them, but behind the scenes I've been trying to temper any focus on immediate metrics with a purpose of building Slopes for a decade+ more.

These recent events have helped me solidify the idea that I want to keep Slopes small(-ish). Not solo-dev, but small-team.

What does that look like in my head? Keep it just me on iOS + watchOS. Maybe get a web developer one day once I just can't manage to do Apple platforms + web alone, but a part-time contractor might even do. Keep my part-time contractor on Android (he's awesome). Basically one full-time dev per platform, if that, max. From there build whatever team is needed to support the product we devs can create and maintain.

But I think, I hope, that size will keep me from over-extending the product. Keep me from setting myself up to have to compromise the product too much in order to suit the needs of the business. But at the same time the team will be big enough to build a product that supports the needs of market and my vision.

Slopes: Just Right Edition.

(It's fun to think of the multi-verse of Slopes ... PWWDR (VC Edition).)

All that is to say that one year after Slopes hired its first full-time employee (Ela), I'm bringing on our second employee (Emma) today. Emma's been running point on customer support part-time for 2 years, plus leading the mapping project team (5 part-timers) last winter. Titles are hard at a small business, but "Comms and Ops" seems about right.

What is Slopes? Think Nike+, Runkeeper, Strava, MapMyRun, etc for skiers and snowboarders.

There’s always a lot of talk about optimizing your paywall - hell, I usually redesign and test new version of mine at least once a season 😅. It makes sense that you'd focus so much on the paywall – it is a single screen that every purchase goes through, so the potential for impact is high.

Then once you are confident our paywall is performing OK you start to focus on where you show it. You'll start to make sure the UI has enough premium features visible in free mode that the user will likely tap something to launch the paywall. On and don't forget the common wisdom: show it during onboarding, get a ton of trials! And then randomly pop it up on launch sometimes, maybe with a special offer.

All roads lead to paywall.

But tunnel vision like this is dangerous in any situation. Fixating on the paywall as your main tool to convert people to subscriptions so much can leave you blind to other potential opportunities.

This is the first season the Slopes paywall went untouched, and yet we dramatically improved our year-over-year growth by focusing on everything but the paywall. In fact, for many users this season who purchased a subscription, they never saw a paywall at all ...

The “Trial Quickstart”

The idea for this came last summer: Ela had noticed Apple doing something interesting with Apple Arcade in the App Store, specifically how they presented the free trial:

It isn’t a paywall at all! No “unlock now” or “see plans” or “learn more”, no popup with a feature list and other junk to add friction and cognitive load. Just a nice simple CTA with an appealing graphic. The phrasing here is interesting, too, and that was what made her take notice at first; it isn’t “here is a year subscription, oh and it has a free trial to lower risk” but rather “hey, it is your free trial, it is sitting here waiting to be used, why don’t you use it?”

Edit for clarification: This redeem button starts the IAP flow right there. No popup beyond the system one.

And thankfully, thanks to the changes Apple made a year+ ago where we don’t have to include a ton of boilerplate text along side IAPs, what Apple did is within the App Store guidelines for third party apps, too (minus their small font size choice for the pricing).

Eager to see how it’d perform we hooked up something similar in a few of the key upsell locations within Slopes, and let it run for the first 2 months of the winter 2021/22 season.

With this new “trial quickstart” we saw a 25% improvement in trial starts over the course of the A/B test, which mostly converted from trial -> paid at the same rate as before (so we weren’t just stuffing a funnel with bad candidates). We've gotten tons of comments that people didn't know how awesome Slopes Premium was until they tried it, so in retrospect putting walls between the user and Slopes Premium instead of ramps was just plain silly.

See, this works well because Slopes is now focusing on a CTA that is appropriate for where the user is in their own journey: they're curious but probably not ready to buy. With a standard paywall I'm focusing on what I eventually want them to do (convert to subscription). With this, I'm focusing on what I want them to actually do in the moment (try premium).

Aside: As a bonus, this approach solved another issue I’d had for a while: because Slopes offers one day + one week passes along side the subscription things always felt complicated. In the moment of purchase the user would have to do the mental math of which purchase made the most sense for them. We had also noticed that, since introducing the free trial over a year ago, even people who would eventually buy the day or week passes would usually redeem the free trial first anyway (back to the “why don’t you use it?” mentality). This new quickstart approach allowed us to focus on a single path on the journey and worry about the branching into different pass types after they tried it out to see if Slopes Premium was something they wanted.

Better UX = Better Sales? Who Knew. /s

While the quickstart trial was running, the next batch of changes in the sales process came from the redesign of the recording screen for Find-my-Friends (“Slopes: The Next Generation” as I called it), which I wrote about last time. For the first time in Slopes’s history there was a compelling reason to start Premium when you start recording at a resort - the premium maps w/ trail info. This is pretty big deal, but more on that in a second.

The UX gave us some better opportunities to highlight an existing Slopes Premium feature: run-by-run breakdowns while you record.

Before you’d have to notice this (left) was a pager and swipe over twice to get to a tiny little upsell CTA crammed in the little white box. Not very discoverable. But the new screen (right 3) really encouraged more exploration (the bottom card opens up automatically when they pause, like at lunch, for people who might not think to hit the expand button anyway).

So where the old version hardly got any trials from the recording screen, the new version has 10% of all trial starts in the app coming form the run-by-run breakdowns. Which is great because that also means people are actually finding this feature now.

Asking for the Sale

The third, and last, major change to how Slopes approached Premium this season might be the most revolutionary - actually asking for the sale.

Ela did a new-user journey walkthrough and noticed that the new recording UX, despite its improvements, didn’t mention Slopes Premium unless you happened to explore and find that run-by-run breakdown or if you hit the map layers icon to try to swap map types. While the new run-by-run visibility was great, the most valuable offering Premium has to offer while recording are those new maps, especially when you’re skiing with friends.

With the quickstart experiment going well by this point we decided to try something new - a quickstart popup when they start recording, but only if they are at one of the resorts we’ve built enhanced trail maps for.

I had always avoided any kind of do-you-want-premium popup here for two reasons: A) before this year there wasn’t anything of real, and more importantly easy-to-explain, value to offer and B) asking for a sale here was terrible timing as they’re likely rushing to get their gloves on and get on the lift. But the trial quickstart? That’s a very low risk choice that can be impulse decided. And the new maps? Super easy to visualize and “explain.”

This rolled out to users at the ~30 resorts we initially had enhanced maps for, and then another 20 resorts towards the later season as we got maps in place for them. And we did this test right away without being hidden behind an A/B experiment (just kill switch); annoyingly the season was already in full swing when we thought of this and we didn’t want to delay further improvements as the season would be almost over by the time we’d have real numbers if we did an A/B.

How'd it go? We’re already seeing 10% of trials are come from this popup … which is only shown at only 50 resorts in North America 😅 (sample bias here: these are the bigger / more popular resorts, and NA is our strongest market, so these are the best target users. But still, huge bulk of trials from a very targeted part of the market). And it appears the popup isn’t just cannibalizing trial starts that would have occurred elsewhere …

Stacking Those Bricks

We didn’t have A/B experiments running for changes 2 (Next Generation) and 3 (Popup), so looking at the YoY trial start growth is a good way to see their effect. Change 2 doubled the trial YoY growth with the launch of the new maps screen, and then change 3 added that same volume of new trials again.

And no, don’t worry, this wasn’t a tunnel vision with a focus solely on trial starts. Conversions stayed healthy in North America, too, where the resorts with the trial quickstart popup all live. We always have a strong start to conversions trial -> paid that diminishes over the season users are less likely to ski again that season, and as we get more one-off trips in Jan/Feb for people:

The biggest potential risk of hurting conversion rates came with change 3, the trial popup, and we see that play out with a ~7% YoY drop in conversion when it went live (week 3 / 4). But considering we’re seeing 3x the trial starts … the math still works out in our favor.

It’s a balancing act of these two numbers, start of trial vs overall conversion, but I think we’re finding the right blend. It's good that we're not being as shy about trying to sell Slopes Premium "in the moment." I want to see if I can improve the conversion rate again next season, but I wouldn't be surprised if quite a good percentage of the trials that didn't convert this year will convert next year (pattern I see: try a week mid-season, end up converting next year in the beginning of the season when it is "worth" it.)

So what’s the end result here? Earlier in the season, before all the changes, trends were showing a 50-60% growth YoY. Now after all these changes we’re sitting on a 90% growth year (which would have been a 130%+ growth year had everything been in place since the beginning 😫).

But that’s great news, and all this is largely why Slopes blew past the $1mil ARR mark this season. 🥳

What is Slopes? Think Nike+, Runkeeper, Strava, MapMyRun, etc for skiers and snowboarders.

One thing I've noticed about Slopes's downloads since 2018 is that my download rate per season has been pretty consistent, fluctuating somewhere between 250k and 280k. The vast, vast, majority of these are from word of mouth / organic acquisition methods, which means this is strong and consistent growth.

The bit that has been bugging me though is that it feels impossible to move the needle on things sometimes, in this case downloads. In late 2019 Slopes added a lightweight social aspect, which was the beginning of any kind of referral loop to Slopes (friends encouraging friends to grab Slopes so they could compete / compare). Despite adding this, though, downloads have stayed in the same ballpark. I never expected downloads to rocket-ship as a result of the features, I didn't build them with growth hacks in mind (in fact, if anything, I purposely hindered their growth-hackiness), but I was expecting a bit more of an uptick.

(Of course two things are at play here: COVID hit mid-march 2020, which hurt downloads. And we don't know what downloads would have looked like without social, maybe there would have been a 20%+ drop-off in downloads?)

In the early days of a product, growth can come easy if you have decent product market fit; 3x'ing or more YoY as you gain adoption in a market, despite a lack of optimization or perfected set of features. But over time, without change, that growth slows as the easy acquisitions are in the bag. You see your growth curve start to plateau. You have to start to fight for it.

That's because you're fighting against a natural asymptote to your curve, brought on by everything that makes up your product. If your product doesn't change and your strategy doesn't change, that same asymptote is always there, a ceiling you'll never break through. Change the formula, you push that asymptote a bit higher.

(And I'm not always talking about features, even if that is the go-to for most developers. What's holding you back could be branding, it could be not having the right marketing channels.)

It's my job to recognize those patterns in the curves. I always try to look at Slopes and think "what is holding me back, how am I shooting myself in the foot?" Because make no mistake, at any moment I've made dozens of decisions that seemed like the right one but are holding Slopes back.

I do think it's important to look at the situation through the lens of "how am I holding my product back?" and not just "how can I grow more?" You don't want to chase growth, you want to chase your ideal product. Just understand how the two play off each other.

In today's case, what was holding Slopes back was fear and focusing too much on an "ideal feature" vs an MVP.

Ela and I were having a conversation in early November about making the social aspects more compelling. She really wanted to see more people using them (which, in turn, would help growth and "building the moat") and felt strongly that needed to be a priority for the season. We brainstormed many feature ideas over a long FaceTime call, but eventually something just felt off. I felt we were going about it the wrong way; trying to force a feature set to be more appealing or engaging (adding features to broaden appeal) instead of actually being useful.

I started postulating that the root problem is that as-is the Slopes social features are pretty passive and very much fall in the nice-to-have, not must-have, category for users. In fact, almost no social feature we could build around stat tracking (things like showing who you rode with, leaderboards, etc) would really fix this problem.

I started a project almost a year ago to map ski resorts. Open Street Maps has ski trail data, but it is often out of date or wrong, so I knew it'd be a competitive advantage to build and maintain the data set myself. I spent the spring and summer diving into the world of GIS tools figuring out how to manage a data set like this in-house, and then building some tools myself on top of existing platforms to help the data acquisition process.

We prototyped and validated the process and got 5 resorts mapped and in-app over the summer/fall. In mid November we moved onto scaling up, hiring 4 part-timers to get rolling on mapping resorts. As of today we have 20 resorts.

As things took shape I planned that in Jan 2022 I'd launch these new "winter trail maps" as a premium feature, an upgrade to the existing premium "winter maps." Premium users would be able to replay all their data on maps with labeled trails, launching with ~50 or so resorts supported. Playing with the prototype of the new maps in-app, it really felt like a big upgrade visually speaking and fleshed out the resorts.

This one feature wasn't the end-game of why I was building this data set, but it was a great near-term win that users would love while I worked behind the scenes on the more ambitious use of the data.

Back to that conversation with Ela.

At this point in the conversation I off-hand mentioned that the real fix to making friends within Slopes actually a must-have was to do something I'd wanted to do since I started Slopes in 2013: build a better Find My Friends, just for skiing.

Despite it being a top-requested feature all these years, I'd held off forever on building this for two reasons. The first, fear. Ski resorts don't always have the best cell reception and that'd effect any find-my kinda thing working reliably. Second, my ideal vision for the feature was to show users on the actual PDF trail map from the resort, since regular satellite maps were going to prove pretty useless for finding people at ski resort. And I hadn't figured out how to, at scale, come up with custom transformation matrices to translate from GPS -> pixel coordinates (since the PDFs aren't linear mappings, they're perspective artists' renderings, you can't just linear transform your way to a geocoded PDF).

Immediately after my off-handed comment ideas flooded together. I realized I was holding Slopes back because I was chasing perfection. With this trail data I'd been gathering the new winter maps would be great for seeing where people are on the mountain. Not just useful when reviewing their stats at the end of the day but during the day, too. I didn't need some ideal "show them on the PDF" solution. Cell reception had generally improved vs when I envisioned it in 2013 and while it wasn't perfect, it was more hit-than-miss and people knew to expect that.

Showing the new trail maps during recording, and their friends, would mean redesigning the recording screen (now the most outdated screen in Slopes, untouched for 5 years?) to really focus on said map (which had the added bonus that I could also show users their GPS track for the day while recording, something people had also been asking for). The redesign would give me the opportunity to rethink UX during recording so I could surface the official resort PDF trail maps right on the recording screen and ski patrol info, two things they'd previously have to hop back to the resort tab and look up the resort to find (terrible UX).

It'd mean, though, I'd also have to finally tackle having data from your Watch show on your phone as you recorded, as Watch users would want all this nice new mapping stuff too. But, hey, "iPhone + Watch: better together" is more compelling.

As much work as it'd be, this was the answer.

Queue a Rocky-style montage of sleepless nights and a flurry of work over a 5 week period to bring what should have been an entire off-season's worth of work to reality.

When you're looking to change your curve(s), sometimes there are small hidden gems and easy wins, but sometimes it takes something entirely new and tangental.

The problem with the old social features I built was that they expanded my reach within my existing market segment (stat tracking), they didn't expand my appeal to new segments and users. They just helped me acquire users within my existing segment a bit more virally / faster. Conversely, this new update finally makes Slopes a must-have while recording, not just after-the-fact. It makes Slopes useful to a whole new (much larger) class of people: a very large part of the market that doesn't give a damn about tracking their stats (I venture many of which will get Slopes for the find-my and will come to appreciate the stats).

But, it doesn't Frankenstein's monster Slopes in the process. I love it because this new stuff is natural and complementary to the core of Slopes. The find-my stuff is, at its core, about GPS tracking. It all fits in very well to the narrative of Slopes, and doesn't feel like some set of features that are just growth-hacking my way to a better curve (like adding an activity feed of friends' activity might). It builds on top of the existing mapping / tracking stuff, and on top of the existing private social graph already within Slopes. It is part of a coherent story, not a pivot.

So take a step back every once in a while. Challenge your old fears and assumptions; you never know how the equation of your product might have changed that'll allow for things you previously thought impractical.

Sometimes you have to take a step back to move forward.

What is Slopes? Think Nike+, Runkeeper, Strava, MapMyRun, etc for skiers and snowboarders.

This season brought a major expansion to Slopes: Android. I talked a lot about the rollercoaster of development that came with it in my previous post, and I wanted to follow up with what all that effort yielded and how the season went.

To start, last time I said it took 3 updates to really iron out the bugs from v1.0 ... and that turned out to be an optimistic lie. It took a bit longer. There was one bug that persisted, one that was very annoying to track down and we kept thinking was fixed but kept coming up. One of those fun bugs that you can never reproduce yourself (I recorded 4 days on Android in January without issue, too), isn't a crash or something with logs, and it looks like you're doing everything right. For a while it looked like it might be an issue with some manufacturers and their over-aggressive background termination (in the name of battery life), but it wasn't that (that issue is so bad they have a web site dedicated to it: https://dontkillmyapp.com).

Basically Slopes would stop recording in the background for no reason.

Not a great bug to have.

A bug like this alone isn't a surprise for me, I knew we'd hit plenty like this in the first season of Android. But where things fell apart a bit was the timing of things. See, we thought it was fixed going into mid January which is when the season really starts to pick up. And, at the same time, DeRon was having his first kid at the end of January. Seemed like a perfect timing fix kinda thing, in just under the wire to leave me in a great position for the busy part of the season.

Sadly, while the fix did help, a lot of people still were hit by the issue. It ... wasn't good. And, at this point, DeRon was on leave for 6 weeks or so. Now I'm not the kinda guy that's going to hound him to come fix the bug. As much as this wasn't a good look for Slopes, at the end of the day it's just a business and honestly I'd recover from waiting to fix it. iOS had its share of bad bugs over the last 8 years, ones that felt like major a crisis in the moment, but in the rear view mirror they're just blips now.

As the season went on though, the bug started to have public reproductions. The Android ratings started to go down, bottoming out somewhere around 3.4 stars. What really broke my heart was people leaving reviews saying things like "oh look another iOS app port where the developer doesn't care about Android."

Aside: a fun part was users yelling at us via customer support claiming they knew the issue and it was "one easy fix." Slopes uses the new location API on Android where it asks for "when in use", and we had a lot of Android well-actually users write in to say the issue was we should be asking for "always." Of course the docs say to use when in use (as long as you start location fetches from a foreground process, your background service keeps the when in use permissions) and even going further to say if you use "always" for an app like Slopes they'd be rejecting apps during review because we don't need the permission.

Once DeRon was back it took a few more weeks of flailing to fix the bug. We had built up a dedicated group of users that were experience the bug and added them to an alpha build list through the Play Store, so were able to iterate builds with extra debugging turned on with them without a huge release process. But most people only go skiing on the weekend, so we had annoyingly long turnarounds on confirmations of how any fix was working. But, DeRon figured it out. Turned out we had the background service set to a medium priority and we actually should be setting it to the highest setting so the system keeps it alive. Looks like some devices don't care if the service is doing location stuff and only goes off of this declared importance level?

But, by the time the fix was live, we were in mid March. Like I said the ratings took a hit, and I knew many people had abandoned the app in frustration (I don't blame them).

Just before that, in early March, Ela suggested we had to do something to win people back. And she was 100% right. So during said flailing / fixing we sent out an email to all the Android users (at least ones with accounts, couldn't reach free users who never made an account) explaining the situation - it was a hard bug, we had a dedicated test group helping to test our fixes, we were dedicated to Android and we hadn't been ignoring the issue. We had to make this right and prove, not just say, we cared about Android though. So as part of that email we gave everyone who paid for Slopes Premium an extra year on their account, and we gave any free users Premium for the 2020/21 winter season retroactively.

It was a big give, but it was the right move, and people genuinely appreciated the honesty / transparency paired with the money-where-our-mouth-is. The actual bug fix shipped a few days later, so it was a nice way to end to the season. Ratings quickly turned around (sitting back at 4.6 stars now) and I think we not only got back some of the frustrated users we lost but also cultivated a lot of now-passionate users out of the situation.

One other thing that threw me off with the first Android season was that I was honestly hopeful that Slopes might get a bit of an assist from the Play Store team. I figured a well-regarded iOS app coming to Android would be something they'd want to highlight.

Getting in touch with them about this though, was a lot of dead ends.

Back in 2017 they launched the "Start on Android" program to help new apps on the platform, offering assistance and guidance during the Early Access phase and more (and, probably, a little extra exposure on the official launch). I had multiple people recommend I submit for that as I was talking publicly about making an Android port over the last two years. Sadly like many Google projects, it seems abandoned? I filled out all the forms and never heard back. Followed up via Linked In messages to the "right people" and they never got back to me. God, I even built a Crunchbase profile for Slopes because apparently they look for that.

Even without the assist of the program I made sure everything was "right" with Slopes on Android: targeting the latest API level, using Material, supporting Sign in with Google, a good store page with nice screenshots, a nice looking developer page, free trial for any subscriptions, and I even commissioned a video preview for my store page. I reached out via the other normal channels too.

Despite everything, nada.

Which is fine, I never make plans that rely on Apple or Google featuring me. But it was kinda a bummer ya know? I put a lot of work into doing right by Android, and I figured Google might want to support an app like that and help make a splash with the launch.

Props to Apple's App Store editorial team - I'm constantly seeing new apps highlighted, and not just ones from big publishers. Apple is doing a better job of highlighting small indies than Google, for sure.

OK, so what about stats? Development drama aside, how'd the Android app actually do?

Android had a little over 20,000 downloads this first season, which is <10% of the iOS downloads this season. But that isn't surprising: a lot of Slopes users don't realize there is an Android app yet (despite email marketing). It's been an iOS only app for so long that word of mouth will take a while to build. And, like I said, no in-store features so they'd only find it by searching for Slopes (because isn't like I'm going to rank at the top of competitive keywords like "ski tracker" my first season).

Revenue wise, Android was <4% of iOS's revenue at $22,000. Revenue per user on Android was ~66% of what it is on iOS this season.

I'd call this season a success for Android, despite everything. Not a glowing success, but a success.

The main box I wanted to check was getting a stable version of the core Slopes experience ported, and that's now there. We have a good foundation to build on, and we've already moved on to shipping (hopefully this week?) the first major feature past v1.0 - the timeline editor letting users do things like delete data from when they accidentally drive away in their car with Slopes still recording.

I got into this knowing Android wan't going to be a huge revenue source, so this season didn't have much of a revenue goal in place. Mostly I wanted to test the waters and see for myself. I'd always been told that for fitness apps Android would likely make up ~10% of my total revenue once it gets going, and we're at 3.3% this season, so we've got work to do. Of course Europe wasn't open for skiing this year, and Android is certainly more popular over there vs the US, so I expect the downloads to go up next year helping reach that 10% ratio. 3.3% isn't bad, in my book, given the order of magnitude difference in active user base.

So yeah, a bit of a bumpy road, but I'd say it is off to a good start. Over 1,000 paying subscribers on Android, a 4.6 star rating, and a good app I'm proud of. I'll put that in the win column.

What is Slopes? Think Nike+, Runkeeper, Strava, MapMyRun, etc for skiers and snowboarders.

So that free trial idea I was toying with back in September? It launched, and I think it has been a success for Slopes. Like many things Slopes it seems to largely be affected by when in the season the trial is happening, but I seem to be around 65% conversion from trial -> paid overall for the season (higher than that in the early season, lower in the mid-to-late season).

Android is pulling the iOS numbers down a bit (the above % is for both platforms), but iOS has a ton more premium features, so I'm not surprised.

Regardless, it seems to be working well.

Of course implementing this trial meant revisiting my upsell screen again. After all, it had only been half a year since I last did that. 😅

I had spent time in Jan of 2020 simplifying my upsell process to be a single-screen (vs a feature list modal followed by a purchase options modal) since those usually convert better (and they do!). Then in fall 2020 I worked on visually simplifying this single new screen as my old one was a bit cluttered and didn't really have the room for all the free trial explainers required.

With all those changes, this is what the screen looked like leading into the 2020/21 ski season:

And I was pretty happy with everything. Considering how stubborn I am on keeping the Day / Week passes, I think this presents the lineup pretty cleanly.

This screen above is what got me the conversion rates I was talking about in the beginning. Doing pretty well, but I'm always curious where there is room for improvement.

In mid January a post made the rounds, "How Solving Our Biggest Customer Complaint at Blinkist Led to a 23% Increase in Conversion".

(go read that now for context, but TLDR; offer the user a push notification reminder on day 5 of a 7-day trial)

In it, Jaycee talks about how she changed their free trial screen at Blinkist to inform the user that they'll get a push notification reminder on day 5 of their 7-day trial reminding them of the trial and that they'd be billed soon.

In fact, the entire upsell screen they tested is dedicated to this flow:

For Blinkist, the experiment was a huge success. The key stats from her experiment were:

• Increased trial sign up by 23%
• Reduced cancellations during the trial by 4%

I mean, these results are amazing, so of course I was going to experiment and see how it might work for Slopes. I set out to work and rolled out a version to production behind an A/B test flag one week later.

One hitch, design-wise: like I said I'm stubborn about keeping the Day and Week passes around, and I didn't want to hide them behind a "See all options" button making them second-class citizens.  I could largely mimic Blinkist's flow (mention reminder, start trial, notification permission prompt after), but I needed to adapt the idea to work within Slopes's requirements. And ideally without a massive redesign, again (😅).

So this is the adapted flow I went with:

I do think that dedicating my entire pass-picker interface to be single-purposed to converting to the trial, a la Blinkist, would have increased the screen's conversion rate, but even with just this small change I saw a 4% increase in trial starts.

Not 23%, but still positive movement. Sadly Jaycee's article doesn't show what the screens / flow originally looked like before their test, so we can't see the full picture of the changes and what else might have added up to the +23%, but I'm def willing to say I'm shooting myself in the foot at least a little bit here. (After my go at this someone else tweeted they experimented with this and saw a 3% trial start increase too, so my number might not be way off base actually?)

But anyway, so far so good.

But the big question is what effect the notification would have once day 5 rolled around? Like Blinkist, Slopes saw a great opt-in rate for notifications. Around 75% of users starting the trial asked to be reminded on day 5. And like Blinkist, I saw my day-zero cancellations drop dramatically as people were willing to give the trial a proper go until the reminder came their way.

I also went ahead and tried out different notifications on day 5 depending on what you had done. If you recorded via Watch, for example, I tailored the notification to something about the great heart rate analytics users love and have them check out that premium feature.

But Slopes did not see the same 4% increase in trial -> paid conversions that Blinkist saw. In fact, it saw a 7.8% decrease over the two weeks I ran this test for those that requested the notification.

Oof. After 2 weeks I turned off the A/B test to stop the bleeding. I waited a bit to let refunds come in just incase this was helping on the back-side there before coming to conclusions (even though my refund rate is well under 1%, so I only get 1 per day out of hundreds of sales). Sadly through all this the A/B test users showed equal refund requests.

Additionally, in the test only 1 person turned auto-renew back on day 5 after having turned it off on day 0 (aka only one sale recovered).

Since I tried this in Slopes I saw another person talk about using it in their own app, and they saw a positive outcome (much better than Blinkist's 4% jump, a 20% jump!):

So here's the thing: it is hard for me to do anything right now but scratch my head. There are multiple factors at play here, and I have my theories (beyond just "Curtis fucked up", which is always option A):

• Asking someone "are you sure you want this?" always runs the risk of them changing their mind. Not that they aren't happy, but they are re-evaluating the value a second time. The goal here is to make sure you're convincing more of those normal cancel-right-away people to stay than you are losing people who change their mind.
• So a core of this notification is making sure you can keep them engaged / show value over the whole trial, and using the notification as your last chance to get them back. You don't ask "hey do you still want this?" in the push, you prompt them to do something within your app related to the trial to show the usefulness one more time.
• Slopes is an app where people get the most out of it at a ski resort. There is minimal room for "re-engagement" outside of that – if you ski and then go home, you're not going to find the app nearly as valuable. So if I ask them to re-evaluate 5 days later when they are at home, Slopes feels less valuable. (plus maybe they just totaled up the bill from the ski trip lol)
• Maybe that means a 5-day trial is bad for Slopes + this push. Maybe a 3-day is better? That lines up better with trip lengths that they'd still be skiing, but then the push is kinda useless ("start your trial today, we'll remind you 24hrs before billing just to be safe, which is uhhhh tomorrow").

So yeah, I dunno. That's my current train of thought as to why it didn't work for Slopes. I really like the idea of building / earning user trust with this push method, but I need to go back to the drawing board and find a way that works for Slopes.

Regardless though, even though it was a bit of a flop for me, you should totally go try it in your app. I'm sure for many apps this is a great way to both increase trust and help convert more users. Just make sure when you send the push, you're sure to be in a better position to show/have shown your value than you were when they started the trial.

What is Slopes? Think Nike+, Runkeeper, Strava, MapMyRun, etc for skiers and snowboarders.

Well, it finally happened. The "1.0" for Slopes launched in the Play Store yesterday.

I've tweeted here and there about the journey over the last year+, even chatted about it on a podcast, but I haven't written much about it since I started. I thought now, with hindsight, would be a good time to talk about how it went.

Buckle up.

Going Native

Before the project had even started around Aug of 2019, I knew I wanted to avoid React as a cross-platform shortcut. Part of what makes Slopes on iOS great is, as a user put it, it's "the ski app apple would write" (high praise, I don't think Slopes is that good, but thanks!). Spit-and-polish on the UI, tight integration with the system through things like CoreLocation HealthKit and more, and feeling 100% at home with native controls.

Plus, having to run everything through a JS interpreter isn't exactly great for my 12hr battery life target 😅

(To avoid a #holywar, I do think React apps can be good, and I do think they have their place. Tragically React is often presented as a cost-savings solution, which means the polish needed for a great-feeling app is usually not a priority to begin with.)

Slopes on Android was going to have the same polish it does on iOS. I wanted to build the app Google would write. I think Android users get the short end of the stick a lot, and they deserve quality apps that aren't just shortcut-fueled copy/pastes of an iOS app. So Google's Material design framework, Kotlin language, everything you'd expect from an Android native app.

I did briefly debate porting my recording engine to C++ or some such so I could share some of that cross-platform, but ultimately didn't. Nothing stood out as great for cross-plafrom code (Kotlin native was interesting, but I'd need it to run on WatchOS and it was all still alpha level stuff) and that would add a lot of risk to the iOS app if adopted.

Android MVP

With the stack chosen, the next step was figuring out "what is the 2020 MVP of Slopes?" I wasn't naive, I didn't think I'd be able to get all of Slopes out as a 1.0 on Android. I'm a big fan of iterating and learning, so I knew I wanted to get a core version out and go from there. Plus I wanted to launch it for the 2020/21 season, so unless I had a full-time dev, that just wasn't do-able.

This meant cutting a lot. Some things were easy, there was no platform equivalent. The Photo Library integration on iOS, the heart rate / HealthKit integration, Siri integration. 3D was absolutely off the table, it was all written in Apple's SceneKit, same with AR / ARKit. And more.

But even without all that, there is still a lot to Slopes. Thankfully I'm pretty good at sniffing out what has to be in release vs what is optional. Examples of things I didn't need for v1?

• The timeline editor letting users add/remove lifts/runs, incase they leave Slopes running when they drive away. They can always fix this data later. Having this in place really helps customer support, lets users fix a lot of their own problems, but I can absorb that temporary hit to support.
• The entire social share card generator. People are more than happy to screenshot the app itself to share stats (and many iOS people do this despite my share creator lol).
• The run comparison feature I added last season. It is unique to Slopes, letting you play back two runs side-by-side on maps and watch stats.
• My entire "trip" support. Letting users group multiple days into a single trip, so they could see stats aggregated for multiple days.
• The lifetime & season screens. Similar idea of showing stats for multiple days.
• My recording reminder notifications (geofence and time-based).
• Localization. I lived for 7 years without it on iOS, Android could go a year or two.
• Not to mention a bunch of the infrastructure things in Slopes on iOS like migrations between versions, what's new highlighting, and stuff like that.

I figured I needed:

• The ability to record (and the entire Slopes recording engine)
• To view those recordings
• The sync engine to save the recordings online
• The social stuff I had built out for leaderboards (adding/removing friends)
• Account management
• And purchases / IAPs (thankfully all my purchase logic is server-side, so it was mostly just getting the order through Google Play and pushing it up to the server).

Takeoff, Then a Crash Landing

So summer of 2019 I put out a tweet talking about needing a native Android developer. The pickings were a little slim though. I think as a byproduct of Android being an afterthought for many companies, there isn't as healthy of a consulting ecosystem on Android, especially when looking at going all-native / Kotlin / etc. Had a lot of very part-time hobbyists that hadn't really shipped much, or only had a few hours a week to offer.

One resume stood out though, was a senior engineer who just left their job to start freelancing. I'd be his first client. We chatted, he seemed to have a good head on his shoulders and wasn't setting off any of my red flags. Apps he referenced working on were pretty good. So we agreed that 2019 would be partial hours to start, with more ramping up in 2020 (once the season started and Slopes earned $$ again). We got started with the first commit to the project on July 19 2019.

I ran the project like I normally lead - I have opinions, but ultimately I like to trust people to do what they are hired to do. I like to avoid dictating everything and instead defer to them to tell me how they want things to work. After all, they are the expert. So he was given a list of v1 features, but I left it to him to pick what to work on first, etc. He set his own hours of course. I stayed pretty low-touch, making myself available for any questions, and only asking for a twice-a-month call to go over progress to start.

Between August and end of December I was pretty distracted with iOS (social features, pricing experiments, etc) so I wasn't watching like a hawk, but things seemed to be moving along. Communication wasn't the best, and time was wasted down rabbit holes because he didn't want to bother me even though I told him to, but whatever. He did oversell himself a bit on his ability to help translate the iOS design to Google's Material design framework, so I took up that responsibility.

In January things started turn sour though. We switched to weekly progress reports since the contracted hours increased a lot, near full-time. I was stood up for those meeting 5 or 6 times before the end of March? Progress was feeling a behind where I'd expected it to be (which I didn't make a big deal of, he's the Android senior engineer and I was trusting him. Software always slips). But annoyingly deadlines I asked him to set himself were being missed too.

All along I was asking him to rectify all of this, but I was too soft. I don't like conflict, so I was too eager to trust him when he said things would improve for the 4th time.

Where shit hit the fan though was an opportunity with Google. Slopes got invited to a Material workshop to be hosted in late March, helping a few apps make the most of their design framework in-app. This was huge for me being able to make Slopes feel like a Google app. Since the workshop was both code and in person, we agreed we needed the major 3 screens (logbook, daily summary, timeline) mostly in place code-wise for feedback by the workshop.

Leading up to the in-person workshop, things kept slipping to get those 3 screens done. But then COVID happened, and the workshop turned virtual and was pushed back a few weeks, buying more time. The week of the new date (workshop was on Thurs) we were to have a call Monday to finalize having everything finished in time (which was still "totally doable" w/ the weekend before) and ... he stood me up. Worse, I couldn't get a rescheduled date out of him. I couldn't get any comments about the code out of him. I chased him for a day trying to reschedule the meeting for the next day and got ... nothing.

So here I was 24hrs before the Google workshop, with one screen completed, another "close to finished" but hardly working and the code wasn't even pushed to GitHub for me to see or present myself to Google. At that point I didn't even know if my developer would show up to the Google meetings, hell I had ever right to assume he wouldn't.

All this for the low-low price of $74,713.

So I did what I should had done probably some time before then - issued a stop-work the morning of the workshop. He was introducing too much additional risk to the project, and crippled me for a major Google opportunity. I had my designs to get feedback on, but half the workshop was code, and I had to completely miss out on that.

It was super embarrassing.

But that stop-work finally got him to call me 😅

I found out that his personal life was spiraling with someone he cared about suffering from new metal health issues, and not getting help. All those missed meetings were either him finally getting sleep, or him dealing with caring for them. And as he was new to consulting, he did what many first-timers do: assume if they just work extra hard "this week" they'll be able to catch up. No need to raise a flag and possibly piss off the client, just work harder and they'll never know the difference.

So I get it. It is an honest mistake many people make, myself included.

This failure was on me, though.

When I interviewed originally I was focused on finding a good engineer - one that knew how to write good code, but wouldn't over-engineer and knew how to balance product + code. And he was certainly, well mostly, that.

But my failing was assuming everyone had the same respect and communication habits I had built up when I was an iOS consultant. I respect the hell out of people's time, and if you set a meeting, I won't miss it (I'm the guy to show up 1min early to Zoom calls). If I have to miss the meeting, I let you know ASAP and don't leave you hanging on a zoom call for 20min, and I'm the one proactively offering reschedule times/dates, you don't have to chase me to reschedule. If I'm worried a feature is slipping, I raise that flag early so my lead/boss/client can factor that into their plans.

But that's me, a pretty seasoned consultant. I was stupid to not look for the red flags that'd affect project management. Especially since I knew I was going to be his first client, of course these were a risk.

I got through the workshop, learned a lot of frustrating things about designing for Android (buy me a drink sometime), and had to regroup.

I felt super deflated to be honest. We had moved to a fixed-price monthly contract in Jan 2020, and he didn't have to track hours anymore. I think with his personal life spiraling he might not have come close to the hour commitment (it is easy to over-estimate if you worked 35hrs this week without a normal schedule and your life upside-down).

Honestly, I think this whole fiasco wasted me $20,000. But hey, one major screen was done and I had a working sync engine (or so I thought).

Getting Back on Track

At this point it is May and COVID is a full-swing thing. Ski resorts shut down in mid March, months early, costing me a lot of revenue. Who knew what 2020/21's season would be like? 2019/20 was already rough due to terrible early-season conditions + COVID, for all I knew ski resorts could be shut down for all of 2020/21's season too. I had enough in the Slopes bank to keep the business running until Oct 2021, even if the upcoming season was a total bust. But that wasn't not enough to get me to Jan 2022 when I'd get my first major check from Apple for the 2021/22 season.

That impending doom actually made the decision to give Android another go a bit easier - either way, Android costs or no Android costs, Slopes was looking at an empty bank account mid-2021 if the season was a COVID bust. Android alone wasn't going to kill me. 😅

What also helped was when I put out the call for Android developers (again) I got 2 much better candidates this time. A good agency promising Android for ~$80k, and a part-time independent dev promising delivery for a little over half that. He was double the original developer's rate, but at the same time the amount of time he thought it would take to finish was surprisingly low. I was skeptical as a result, seemed classic under-estimation, but had a call anyway because he was impressive on paper.

And we hit it off, like "I want this guy to be my coworker" level.

Thankfully it turned out a friend of Paola knew him from his previous job (he works full-time on a popular meditation app now) and was able to get me references from 3 people that were all glowing including in the areas of communication, project management, and estimation. One reference was from a director-level person (when a director knows about an individual contributor, that's a good sign). That put my mind at east and over-the-top in moving forward with him.

His first commit was June 25th 2020.

Delivering

There were a few surprises as we got moving, for example that sync engine I thought I had on Android was a read-only sync engine. The whole "upload new activities, upload changes to activities, and delete activities" bit wasn't even written yet. 😅 But the foundation the first dev had built was at least good, code didn't have to be thrown out. Just a bit more had to be written than expected.

But DeRon got to work, and those 3 hero screens I wanted for the Google workshop came together fast. He was moving fast, but importantly what he was building worked great. He was as good as I had been lead to believe. He was even able to step in and take the reigns on translating the iOS design to Material (within the theme of what I had already worked out, but still, I got to stay hands of there and didn't have to spell out everything). He even care about the little things, like transition animations.

And let me tell you it felt good to have some screens working on my Pixel 3a that I could play with. It went from almost giving up to "OMG this is Slopes" inside a month.

Most of the app, sans the recording screen / engine, was done by early October. I had originally hoped to launch Slopes in Early Access (Android's public TestFlight) on the Play Store early Nov along side the big iOS update that added the resorts tab, but we ended up having to push that beta a bit. The recording engine landed in time, but we wanted a few more weeks for that "last 10%" that always takes longer than expected (which of course meant a bit more budget).

But honestly, this was playing out exactly how I'd expect a software project to play out. A little bit of under-estimation of how hard something would be, a little over-estimation of how much the original developer had completed, and sprinkle in my high standards for polish. But all within my expectations running software projects.

We launched Slopes into Early Access in the first few days of December. That gave us (finally) lots of real-world tests of the recording engine and insights into the hardware differences with Android phones and GPS. Of course it a few bugs, which took 3 updates to get all the major ones. Users were super happy to see Slopes on Android, very forgiving of the bugs, and excited to see us committed to shipping updates and fixing things quickly.

The nice surprise was that I asked DeRon how he felt about getting the Resorts tab (the thing that just launched on iOS) in as part of the "1.0" for Android in late Dec / early Jan, and he said totally lets do it.

And he did it.

It wasn't even on the original scope (it didn't exist on iOS during scoping 😅), but this additional tab really helped flesh out Slopes on Android. It really felt complete with it in place. And honestly, I think the premium offering needed it (offline trail maps for resorts if you are a subscriber). Without resorts, the premium offerings felt a little lacking.

1.0 and Beyond

Yesterday (Jan 5, 2021) Slopes for Android left beta and released its "1.0". After starting the project back in fall of 2019, and many ups and downs, we're here.

The 1.0, including the first dev fiasco and increased scope, ended up costing $150k (he still came in under the agency quote, even with more scope 🥳) over the course of a year and a half. My hope for Android all along has been getting it to the point where it can pay for itself. It won't be a big money-maker like iOS, but I felt it could probably make enough to pay for the dev working on it. Out of the gate though, this is all iOS paying for Android, and I knew the 1.0 was a sunk cost.

There's a lot of catching up with iOS to do, this won't be one of those "ship it and forget it" Android apps that my competitors have shipped. You saw the list above of how much was left on the editing floor. I wanna see Slopes on Android hit all those things, and more. 1.0 + a bugfix release in two weeks is not the end of it.

My experience working with DeRon has been really good to date, and he is clearly a senior engineer that's capable of a bit more product leadership than I think he's been given opportunity for in the past. So I proposed something...

• Slopes/iOS will guarantee a minimum amount per year to him, which pays for a (pretty large) retainer of hours for the year at a discount. That retainer is enough to move Android forward: bug fixes and maybe a feature or two. But it only covers about 1/3 the hrs per month he had been working to ship 1.0.
• Assuming he works any more hours than those, he gets the Android revenue (up to a cap we agreed on, he won't be making 1mil/yr off this 😅, eventually I get some of the revenue again). That helps soften the blow to him of Android being in its early years (since subscription businesses can take a bit to get off the ground). But gives him the room to earn more than he could consulting alone, and start to divorce the time <-> money relationship that comes with consulting.
• I can't give him the risk of Android's performance without responsibility, so he gets to figure out the roadmap. I get veto power, but he's shown to have a pretty good eye for managing this so far. And he gets the iOS roadmap as a cheat guide to accelarate the Android business.

This works out for me because iOS is now just responsible for the retainer (which is quite a chunk, but a lot more managable than $150k). And then I just don't rely on Android money going to me anytime soon. It'll take a year or two to get there, but he has the headway to make a lot more than he could consulting.

We negotiated all this over the course of December and came to an agreement we're both happy with. 🥳

So yeah, I'm pretty jazzed. Not only did I ship a 1.0, I have a plan forward for Android so those users aren't neglected. Hopefully now that Slopes it out of Early Access it'll get some more attention / downloads and things will start getting a move on over there.

Honestly didn't expect to be in such a good position after where I was in April.

But I'm glad I didn't give up, my calculated risk of continuing Android seems to have worked out. The season is going OK so far, thank goodness, so I'll likely survive 2020/21's winter and last until 2021/22 when things should be back to normal. And now I'm in a much stronger position for next season with Android in place and launched. Having Android unlocks a lot of opportunities I couldn't have touched before when it comes to working with other businesses (like for example the Red Bull partnership Slopes did).

It was a very scary, very calculated risk to take, but it worked out. 🎲

What is Slopes? Think Nike+, Runkeeper, Strava, MapMyRun, etc for skiers and snowboarders.

I've put off writing about how the 2019/20 season went for three reasons.

First, the numbers are starting to feel big. 2019/20 is ~2X+ what I'd need to live on in Philadelphia, so it is really starting to be a bit crazy talking out loud about. It is going from "cool, he's an indie finding success!" to "uh, ok, that's a lot of money ... did he buy a money bin to swim in, greedy SOB?"

I'm also seeing these bigger numbers at a time when the world, for many people, is collapsing. Walking around Old City in Philadelphia I'm seeing business after business close down due to COVID. So talking about success, and even continued growth, feels super awkward.

But lastly, for the first time since 2015, the season didn't live up to my expectations. And that sucks. Somehow that fact has escaped hitting me mentally as hard as I expected it to, but it still isn't fun to write about and admit publicly.

Don't worry though, I'm not about to stop publishing my proceeds numbers.

So how'd it not live up? Since I switched to subscriptions in 2015, I've been seeing 2.x X growth in revenue year over year. I wasn't going to take that growth for granted, so I was really working hard to ensure another 2.x+ X year:

• I was finally taking the user journey out of the app with email marketing (which, by the way, went pretty well).
• I was spending a lot of effort fighting my tendency to minimize my upselling.
• I had started the season shipping my vision for a privacy-first social aspect to Slopes. Now you have a selfish reason to get your friends on Slopes.
• I tried my first Black Friday sale (which also went well, ~1k new subscriptions).
• I was offering 2 free day passes with subscriptions, encouraging users to share them with their friends (didn't really work).
• And a lot more...

So going into the season I felt pretty good that 2.x X was very realistic. After all, I was doing all the right things and I had a trend line!

I'm always conservative with money and I don't like debt, so I didn't dig myself into any holes I couldn't abort as needed. I didn't buy a Tesla knowing I'd 2X. But I did start taking on more monthly costs. I started Android development in Aug 2019, which has been a sink of ~$10k a month. That new email marketing is around $1k a month to run, the biggest single non-human cost to Slopes. This was my first season spending real money on advertising, around $20k on App Store Search Ads (which did net a profit).

This was the year I finally let myself live a little, business wise, and upgraded my database server from a $10/mo Digital Ocean machine I administered myself to their managed PostgreSQL cluster w/ replication for a whopping ~$80/mo (big spender, I know). Little things like that happened more often. I wasn't as focused on only taking on a cost if I 100% needed it, I was worrying a bit about my quality of life and the nice-to-haves.

It felt like it was all building towards a major milestone: hitting that 2x goal would have given me the breathing room I needed to safely take Slopes from one-man-shop to the start of a team.

This season ended at 1.4 X growth.

So of course after missing that milestone, a lot of the mid-to-late season was spent with me trying to figure out "what did I screw up?" After a lot of reflection over the summer I think I've realized (well I mean I knew this, but I think I started to internalize it) that it's just hard to keep growing at that rate naturally, and this is why VCs and money come into play because you need gasoline, not natural wood, to keep accelerating at this rate.

Continuing past where I am requires a relentless focus on product-market fit, perfecting onboarding and funnels, pricing experiments, and a whole lot more. I'm getting well into the "average consumer market" at this point, and that's hard.

It wasn't just that though, I did realize as the early season was progressing that I had some things working against me:

• This was the worst winter in recent history around the world. I noticed this early on, in Nov/Dec. Vail resorts (big ski corporation that owns dozens of resorts world-wide) reported ~10% drop in attendance in their January report. That's huge when they've been seeing growth. Whistler in Canada reported the worst early season on record in 30 years. Many resorts in Europe never opened because they rely more on natural snow that snowmaking. That all leads to less people going out to record. Of course all of the resorts said were hoping to make up the difference in the mid-to-late season...
• COVID cost me ~$60k. Ski resorts shut down early-to-mid March world-wide, and my revenue hit a cliff abruptly as a result. I hit $0/day over a month earlier than normal. I probably would have ended around 1.6x or 1.7x if it weren't for that.

Running a lot of numbers, my conversion rate sill seemed healthy. My churn was OK. What was really killing me was activations - there were just less people using Slopes than expected.

So I dunno, I'm weathering the storm of not hitting my 2X goal surprisingly well. I had a lot stacked against me, and it isn't like I'm a growth expert and I already know how to make this jump.

I'll just keep shipping, and keep learning.

All that is a long-winded way of saying "boo-hoo, I only grew by 40% during a global pandemic and climate change threatening my business."

😂

This all did make for an interesting summer with lots of calculations.

I had to decide if I wanted to keep Android going (see: Release Notes podcast episode). Obviously "because, COVID" would be a reasonable excuse to hit pause for now.

My runway math showed if I halted Android shortly after COVID locksdowns started, and the 2020/21 season was like my March/April 2020 was (AKA, non-existent), Slopes would run out of money in Oct 2021 ... not quite making it until the next season where things in theory should be back to normal. If I kept Android going to be able to ship in 2020, I'd last until May 2021 or so.

(Keep in mind, I earn < 5% of my revenue during the summer w/ the southern hemisphere, so I need to make it until ~Jan 1 2021 when I get my first "real" paycheck from Apple again.)

On top of this I had to decide how much I wanted to work on the iOS version even. Because after all, it isn't like the 2020/21 season is a guarantee given everything (as I write this most of Europe is locked down with ski resorts closed in Nov 2020 until Dec 1). Skiing or snowboarding itself is a very COVID-safe activity, but everything surrounding it, not so much. People don't feel safe to fly, which will kill a ton of ski business. Travel restrictions will hurt European ski resorts even after they can re-open. But at the same time people are going stir-crazy, and many bought houses at the mountains to escape cities during this time, so it could be offset by more "locals" riding all season. But with skiing being such an unknown, it might be wise to split my time 1/3 Slopes and 2/3 something new that I could have in place before that May 2021 moment-of-truth.

In the end I decided I'd keep working on Slopes full-steam until the end of 2020 and see how the season is looking before considering another revenue stream. I did end up keeping Android going, because I was screwed either way on that one 😅. I'm playing the long game with Android, but it isn't like canceling it would get me to Jan 2022 when I'd be "safe" again, so I'll roll the dice with it while keeping its costs manageable. I'm not planning on dumping a lot into advertising this season, and I'll trim fat as needed from services Slopes relies on. I held back on my original hope of bringing on more part-time help this season, too.

I'm staying nimble, but I'm using the season to focus on the long game. The ski market will be back next year, so I'm trying to focus on A) just surviving this year so I can B) be in an even better position then. I've had 1 major competitor w/ funding drop out in late March, another very popular free one finally pull their ski apps after pivoting to soccer 3 years ago, and yet another free one pull their Android app after it seemingly flopped (nothing but 1-stars and no updates for ~2 seasons). This year is thinning the market out, and if I'm smart I can be in a really strong position come next season.

So far, things are not a disaster for the 2020/21 season. People are skiing, and revenue is coming in. I need to earn ~$120k this season to make it into next winter, and that looks like (knock on wood) it'll happen based on the early season numbers I'm seeing.

What is Slopes? Think Nike+, Runkeeper, Strava, MapMyRun, etc for skiers and snowboarders.

While exploring a lot of the possibilities with Slopes's pricing, if I were to change it, a light bulb went off.  Some pieces of the puzzle had changed over the years, but I had never taken a step back to look at how they all fit together now.

I've talked about how in the ski market, there are season pass holders, but those makes up only a small part of my target market. A much larger part of my market are the people that go for one or two trips a year, or on weekends to their local hills. Riders for whom the annual Slopes pass just doesn't make sense to them - why pay for a year's access if they only ride 4 days?

That's why shortly after I launched the annual subscription back in 2015, I added the Day and Trip(week) passes, moving me to a hybrid consumable + subscription model similar to ski resorts. This was still way in the early days of iOS subscriptions though. So early in fact, Slopes wasn't even eligible to use auto-renew when I launched; that gate wasn't opened up for another year and I had launched with a manual renewing solution. Also back then, subscriptions weren't able to offer a free trial.

But that lack of trial turned out to be OK. The Day Pass not only accommodated those that didn't ski often enough to justify an annual pass, it became a popular way for Slopes customers to try out the premium features, at just $1.99 (usually then buying annual the following season).

Fast forward to 2018, 3 years after I launched my annual pass, and Apple finally enabled free trials on subscriptions.

I didn't bat much of an eye though because I had the Day and Trip Passes, cheaper and lower barrier gateways into Slopes Premium. I didn't completely ignore the idea, but at the time I was focused on a one month free trial (how so many other services worked back then). For many people, that could be their entire ski season. I worried that people would abuse it to use Slopes Premium on their one trip a year and then cancel before the week was over, people that would otherwise pay for a few Day Passes or Trip Passes within that month.

If you've talked to me since 2018 about free trials, I'd probably have mentioned to you how I just don't think they'd be a good fit.

So I'm talking about pricing, and the other person suggests the Day Pass should go away to simplify the lineup, but we quickly breeze by that. The conversation continues for another 10 minutes until my brain comes to a screeching halt and jumps back to a world without a Day Pass.

See, I now know in 2020 that a large number of my Day Pass purchasers are customers using it for the trial aspect. Specifically I'd venture (based on a lot of SQL queries I'll spare you) around 2,500 people are using it as I originally intended with an additional 5,200 Day Pass purchasers using it as a trial. That's 10% of my 2019/2020 winter premium customer base using it as intended, vs 20% of that base using it as a trial.

And people that use the Day Pass as a trial do convert to yearly users. Sometimes that same season, sometimes the following season. But iOS's free trials convert a lot better that this setup, somewhere between 2x and 4x better.

Suddenly using my Day Pass as a trial route seems ... less than ideal. Especially since now I'm not limited to a one month, and have 3 day and 7 day trials available.

See, this goes all the way back to the third post in the series where I talk about how being paid up front, instead of freemium, makes it a lot harder to sell to my customers. With an up-front price I couldn't let them use Slopes and see why they'd love it, I had to sell them on it with pretty screenshots and text. Turns out, I've been having the same issue, only now it was in-app with Slopes Premium. I've always struggled in-app trying to show just how great Slopes Premium is, and had no way for someone to just try it. They had to pay $1.99 at a minimum to try it out.

If I moved to a free trial (probably 1 week?), it becomes so much easier. Just try it. All my upsell buttons become "try it for free" instead of "grab a pass" or "unlock now". And free is a strong seller.

Of course, I will still have plenty of tire kickers, but now they'll be using a system specifically designed for them, not hijacking a Day Pass to do the same thing. But being able to design around that trial, I think, will help lower the intimidation customers feel today in trying Premium. If I just take the people that use the Day Pass as a trial and assume they convert at the average for apps in the fitness category, I'm looking at a 10 - 15% increase in gross revenue. That is without taking into account the tons of new people that will finally give Premium a try and hopefully convert.

There is a risk though: I do need to offset that with the people that'll use the free trial in place of a Trip Pass, which is a loss of $9.99 per Trip Pass. They can only do that once, but if every customer that buys just one Trip Pass a season does that their first year ... worst case would be in 2019/2020 I would have lost 8% of my revenue. I'm not sure how many people will be willing to start a free trial vs just buy the Trip Pass and be done with it, I have to assume if they don't go more than one trip a year they'll just ignore the yearly plan anyway? Dunno. Plus, there are the people who buy the current annual pass that won't want to stick with it after using it for a few days. I have a hunch those people usually are the ones asking for a refund, but I don't know what the overall drop because of that will be.

I'm really not sure how to math this through, seems like something I might just have to brace myself for and try?

But back to the Day Pass though, even if I go with a free trial setup, I still debate what to do with this IAP. I've always wanted Slopes to be accessible to a wide audience, and the ski market has a very diverse set of travel patterns. The Day Pass helps support that. But at the same time, I've always seen that simplifying things ultimately helps conversions as customers don't have to try to figure as much out.

I could leave the Day Pass around for those 2,500 people to keep on using as they want. Or I could simplify the Slopes Premium purchase system even more and keep Day Passes around just for special deals, like buy a yearly sub get two Day Passes to give to friends. There is a large balancing act right now with pricing things right between a Day, Trip, Season, and Household Season Pass.

So I'm not sure yet, but this feels like I might be onto something. If nothing else, it's nice to have a new perspective and a new set of options.

Not sure if it was the fact ski resorts closed a month early because of COVID, and there was an unexpected snowboard-shaped hole in my life. Or if it was me winding down after pushing hard with Slopes over the winter. Or, if like many other people, being stuck inside due to 🦠 was causing me to need something I could really lose myself in.

Whatever the reason, here we are. Say hi to Sim Genie.

Sim Genie is a Mac app that is built for those of us that spend our days in Xcode. Apple has been adding a lot of hidden capabilities to the Xcode simulator, but they haven't been making those capabilities particularly easy-to-use or discoverable.

So I got to thinking: the simulator can do a lot of things now a days, and I'd save a lot of time and avoid many annoyances if those things were more easily exposed. What would an app look like that really took a serious go at making a proper product out of the simulator? One that didn't just focus on the raw capabilities of the simulator, but the workflows that could be built around it?

Sim Genie is that answer.

You should head on over to the Sim Genie web site if you want to learn more about the app itself. I wanna talk about the behind-the-scenes stuff for the rest of this post.

Green Fields

I had a half-dozen or so app ideas, from cool smaller apps I'd use daily to "full" products on the scale of Slopes. But I am very critical of my own ideas, and hesitate to actually start working on something unless I think it can be a success (see many episodes of Independence where Jelly keeps telling me I need to branch out). I shoot down my own ideas way too early in the explorative process. Some of the reasons I'd shoot things down were 100% legit: by the time I'd finish app Y, it would be the wrong time of the year to launch, for example. But there was also a lot of self-imposed pressure to live up to something.

(Fun fact: work on Slopes wasn't started for 6 months after the idea, because I was unsure that I could actually make something of it. Self-doubt is a killer.)

To push myself over the hump and actually start working on something, I decided to pick something smaller in scope, something I wouldn't be putting pressure on myself to reproduce the success of Slopes. Something I in fact couldn't achieve Slopes-levels with.

That very quickly narrowed the list down to this product. Sim Genie was something I'd been wanting to take a crack at for years; it was a space I thought I had some unique and good ideas in. Much like Slopes, it was going to be an app I'd use myself a lot. And, for-freaking-once, my online audience would actually largely line up with what I was making (let me tell you how many members of the tech press don't ski 😤).

Holding Pattern

Funny enough, though, I almost did take a crack at this app two years ago.

As I was kicking the rough idea around with friends back then, I quickly learned that my co-host Jelly had started work on a Mac app for managing and import/exporting the sandboxes for the Xcode simulator. And while his work on it had paused, he assured me that he'd get around to shipping it and it would hopefully contain many of the things I wanted to do in that space, too.

I wasn't about to start work on an app with that kinda overlap with a friend's app, so I eagerly awaited the launch of his app "Bindle."

Fast forward to present day. We're chatting about life and things one evening over FaceTime, and I mention my I-need-a-new-app itch and how it was really bugging me. Jelly reminds me of his app, the one I had expressed interest in doing something similar to, and informs me that he had been unable to commit any code to it since we last spoke those two years ago. Life happens. But, after this long, he was willing to concede that just maybe he might not be shipping it anytime soon.

And so he was happy to give me his blessing, let me grab whatever I wanted out of his codebase, and finally build the product I had been wanting to do.

So, hat-tip to you good sir. Thank you for your early work, and I hope I'm doing your vision proud.

The Finish Line

Now of course here we are, two months later, in classic Curtis fashion with a polished marketing site and featured-packed product in hand for what was supposed to be a simple side project to scratch an itch. I coulda launched a month ago (and multiple friends on the betas have been yelling at me to for many weeks) but that's apparently not how I roll, even for side projects.

The extra time afforded me a lot of polish. Simple, but powerful things like the ability to have Sim Genie automatically apply a status bar preset before taking a screenshot or video with Sim Genie. And things you've gotta roll yourself outside of the Mac App Store like crash reporting and update handling.

If I had launched earlier I probably could have avoided one last-minute snag though: having to redesign the app icon, and the preference pane icons, a week before launch (I loved what I did for those icons, too 😭). Sim Genie is a menu bar app so you don't see the icons that often, but I was still particularly fond of what I made pre-Big Sur. I'm sure the Catalina icon will look antiquated in a year once we all get used to the new design language of Big Sur icons, but I'm still adjusting to the new look.

But on the plus side, I think I get to claim "FIRST!!!!111!" for the prize of app-with-big-sur-icon?

(I've made the original icon available if you'd like to override it while you're still on Catalina. I can't not ship that original icon, in some form at least.)

Lets Talk Shop

It wouldn't be my blog without talking about the business side of things here. Astute readers will notice that Sim Genie is doing many things I'd normally caution against in this day and age:

It is a developer tool, which means it is targeting niche which historically has a strong inverse relationship between their vocal demand of features vs their willingness to spend money.

I don't have much to say about this, except I'm an idiot.

It is software prime for sherlocking.

First off, I'd be OK if Apple sherlocked me! I would love to see Xcode support a lot of these features without the need for additional tools.

That said, I think I'm safe placing good money (or, in this case, dev-hours) on the fact they won't anytime soon. Apple is building out its simctl command-line utility quite a bit, but they don't really seem interested in the simulator itself. I can easily see an exec there saying "well, they can do it today with the tools we gave them, right?".

They have bigger fish to fry, and I feel like this would have been low-hanging fruit for them that they'd have addressed in Xcode 12.

I'm charging a one-time fee for the app, there is no recurring revenue here unless I go the 2.0 upgrade-pricing route.

I'm mixed feelings here, to be honest.

This is the kind of tool a developer will use daily, and could save a ton of time during something like making marketing screenshots (assuming they still do them manually ... like many of us do). There is real value here and it does address some real pain-points, which means I should be able to charge "real money."

But I'm also well aware of just how anti-subscription developers and the dev-tool market can be. Every market is going to have people that complain about subscriptions, I run into them with Slopes, but the developer market in particular can be savage. I think Sim Genie is a prime example of why I'm always saying to experiment with app pricing and take into account your target market when playing with pricing.

You can't just add subscriptions to an app and expect success. In fact, I think if I added subscriptions I'd have a net-negative effect on Sim Genie.

What, no Mac App Store version?

Sim Genie has to use the Xcode command line tools, and some other terminal goodies, to work. And that kinda stuff ain't exactly sandbox-friendly.

That said, I think I see some ways in which I could get a slightly limited version of Sim Genie into the MAS. I'm going to see how things go with the direct-download version before investing the work into that, though.

In the mean time lemme tell you - it is nice to bypass my normal checklist of marketing assets for the App Store. But, interestingly, it made me appreciate the things Apple provides me when I distribute Slopes via their App Store:

• I had to integrate my own crash reporter, set up a server endpoint to gather them, which emails me the logs. I could have used Crashlytics, but I didn't want third-party tracking code in this app. And without the App Store I don't even get basic crash reporting via the Xcode organizer like I do for Slopes. Would have been nice to be able to rely on Apple to get some crash reports from users.
• I had to set up my own updater, both client-side and server-side. I'm using Sparkle, the go-to "there is a new version of X available, do you want to download it now?" library. But that means I've gotta maintain an XML feed of releases and the releases themselves on my server, make sure I have a CDN for them, and all that fun stuff. Wrote a nice little deploy script that rsync's it all up, so it isn't too much work, but woulda been nice not to waste that day+ on it.
• Had to integrate a third party in-app purchase library, Paddle. Of course I would have had to write IAP code if I was in the MAS, but I'm quite familiar with Store Kit, and that'd be one less third party with info on my customers.
• I haven't done much research yet, it is a post-launch problem, but I'm worried what kind of tax reporting situation I am in, both domestically and internationally. Apple handles a lot of that for us, and since it is so transparent to us we never realize how much work they're actually saving us.

Sim Genie is my first Mac app; all in all it has been a fun process. I would definitely encourage any iOS developer to take a look at making one – there are some new concepts that'll trip you up, but there's also some cool stuff in AppKit land that never made its way to iOS.

And man, I had forgotten how much of a rush it is to build and release a new product.

If you have a moment, Sim Genie is on Product Hunt today for the launch.

What is Slopes? Think Nike+, Runkeeper, Strava, MapMyRun, etc for skiers and snowboarders.

Going into the 2019/20 season I had an ambitious plan: finally ship the iPad version of Slopes I've been wanting to see for years. It isn't so much that I thought that the additional platform would be a huge boon to my business, although I think there's some effect on conversion of window shoppers by showing that Slopes is mature and exists everywhere they might want it. More-so this was about an itch I really wanted to scratch. What's the point of running your own product if you can't scratch your own itch occasionally?

Adding a proper iPad version to an app can add a lot of complexity, though, and I needed to manage that. I needed to make sure that the iPad app didn't slow down my ability to ship other features in the future. I am a solo developer, after all, so this is something I always consider.

iOS 13 brought us a lot of great new APIs to make powerful iPad apps so my decision was to drop support for iOS 12 in September 2019 and go 13-only. The perceived complexity of maintaining iOS 12 support (Appdelegate vs Scenedelegate) while also trying to adopt all the new great iPad APIs (along with the new background API, SF Symbols, etc) made me decide in June to drop iOS 12 support with my iOS 13 launch. I always drop support for 2-year old operating systems so I can stay lean, but I usually wait until January or later. This would be the first time I'd drop support so quickly.

But hey, going iOS 13 only drops support for 1 generation of phones, surely it won't be a mistake?

From a code perspective, it went very well. Focusing on iOS 13 let me rip out a lot of old iOS 11/12 code, refactor and clean up a lot of stuff. The codebase improved as a result.

But when it came to customers, two things really bit me with my choice.

First, Slopes has moved a bit more mass-market. It's no longer the niche snowboard app used by just the tech enthusiasts, ones that are always running the latest and greatest or ones that know all the nooks and crannies of iOS. My market is shifting into one where more people are on older devices, more people can't or don't upgrade OSs for one reason or another. Which isn't a bad thing, but it made the second item hurt a lot more...

The App Store did not help me the way I hoped it would. In fact, it actively hurt me.

See, a large part of my choice to go iOS 13-only rested on the fact that existing users can always re-download an older version of Slopes that supports iOS 12. Going into the version bump I felt secure knowing my existing customers would be taken care of if they stayed on iOS 12 for whatever reason. I was confident this was a great compromise.

Boy was I wrong.

No one knows the ability to redownload an app's older version exists if it bumps OS requirements or gets removed for sale. No one knows about that purchases screen.

Seriously, don't rely on this feature. Tons of customers wrote in angry that they paid for something in Slopes and now I removed the app from their phone. They were appeased once I explained how to go through the purchases section to redownload Slopes and the version I made available to support iOS 12, but that was a support reply I was having to send out way too often. And plenty of people likely didn't even write in, they just moved onto another app in frustration.

Even better, though, was what happened to potential customers still on iOS 12. Ones who had never downloaded Slopes to begin with. You know what they do when they want to download Slopes for the first time? They type "Slopes" in the App Store search bar, naturally. You know what comes up in the search results in iOS 12? Not Slopes.

Apple seemingly doesn't want to highlight just how many apps a user can't install due to OS requirements, so instead they go with an ignorance-is-bliss approach. The App Store hides third-party apps from the search results that can't be installed. No product page with a note saying "needs iOS 13, update first" note.

Just a list of my competitors.

I'm fine having people on an older OS find out they need to update their OS to install Slopes, but I'm not fine with them thinking one of my competitors is what they're looking for because I'm not listed. I had people legit think I removed my app from the store.

🤦‍♂️

In retrospect, it worked out OK enough, despite the rocky road. I was able to retrofit iOS 12 support back in, and it worked out pretty clean (actually much cleaner than if I had tried to add iOS 13 support on top of 12 – this retrofit forced me to make some compromises for 12 and not insist on keeping 12 support 100% the same). I launched the update early January and iOS 12 users were thrilled to have all the new stuff I had worked on.

In the end iOS 12 only made up ~3% of my sessions in February, but that isn't what is important. Being a mature app means supporting existing customers as best I can, doing whatever I can reasonably do to make sure they feel supported. In this case, it meant adding back iOS 12 support so users wouldn't feel abandoned (even though they weren't, it was just the App Store failing me).

What is Slopes? Think Nike+, Runkeeper, Strava, MapMyRun, etc for skiers and snowboarders.

I always have been ... one might say squeamish ... about upselling my premium IAPs within Slopes. Which is of course silly because Slopes Premium is the lifeblood of the app and the only reason I'm able to build and grow the product (vs selling user data or monetizing some other way). But after all, this upselling is basically marketing, and we all know most developers are allergic to marketing. 😅

Many of us take a lot of pride our craft and the designs we polish for our products. There is some purity that we feel we are losing when we upsell, that we're adding a dirty ad inside our otherwise beautifully created products. (see: recent iOS community opinions on Apple upselling their services within their own free apps).

When I'm working on Slopes, I often initially treat the premium features as things I hope users will naturally stumble on or just instinctively want and seek out. "Slopes is known for the 3D, so of course that is why they're downloading it, so they'll be looking for it in-app! So that one '3D' button on that single screen is enough!" It's kinda the "if you build it they will come" mentality a lot of golden-era iPhone app developers had about their own apps, but for the new freemium world. Build great features backed by an IAP and they will pay, no in-app marketing required.

Spoilers: way more often than not they don't know much about your product at all.

What's obvious to you is never to them, and there's good odds they didn't even look at all your App Store screenshots where you highlight these features. They just typed "ski tracker" and downloaded the first result that wasn't a game.

Talking to my users has backed up this: I'm hearing over and over this season from users that they had no idea how awesome the premium features in Slopes were, and if they had known they would have upgraded a lot sooner.

A great example of this is how I advertised the 3D feature compared to how I reworked it for this season. In past seasons I actually went out of my way to minimize the upsell (I mean, god, look at that low-contrast and tiny text) and provide free users with some kind of alternative feature (a 2d map):

I've realized that I can't just hide away the premium features on some "About Slopes Premium" screen on the About tab, keep the app clean by shoving all that upselling to one dirty little corner of the app. I need to make the premium features discoverable along the user's natural usage so they'll know they want them.

These kinds of mistakes aren't new for me and Slopes, of course. I've always been bad at framing the conversation around an itch they want to scratch, something they want, vs just a list of features:

That change to the unlock block has made a pretty big difference. Framing the upsell in terms of their own content, that thing that they're coming to the screen to check out: "which run did I hit my top speed on, and where on the mountain was that?" has been much more effective.

With these change in place, this season was the first in which I received complaints (2 app store reviews) that the ads for premium were too much. Some people really don't like to be reminded that they are missing out on things.

If anything though, just like pricing, if no one was complaining I probably wasn't doing enough.

And you know what? They're using my app for free, they can deal with a few ads like this (which I'd much prefer over third-party ads with nasty tracking).

All of this is certainly a balance. You can go too far and litter your app with upsell ads. You don't want to loose effectiveness by having too many ads on screen at a time (even little lock icons everywhere), as people will start to get blind to it. In my opinion it's important to try to focus one call to action per screen. Figure out the most important thing on that screen that they can unlock, and focus on marketing that. If you can unlock a lot on a screen, maybe figure out a way to condense that into one upsell, or pick the most important feature and focus just on that. Advertise the other features elsewhere.

What is Slopes? Think Nike+, Runkeeper, Strava, MapMyRun, etc for skiers and snowboarders.

Back when I was working on implementing my sync engine over the summer of 2017 the main problem I was trying to solve was helping protect customer data. I hated getting emails from users who didn't realize they needed to use iTunes / iCloud backups to move Slopes data to a new phone, incorrectly assuming that Slopes would backup things for them like many other fitness apps. Other fitness apps had made sync table stakes.

But I knew giving free users a reason to make a Slopes account would be useful from a business standpoint, too. It would allow me to improve to how and when I was able to interact with my customers. See, before sync I had no way to reach out to free users outside of the app itself, and that's problematic.

It's a situation a lot of app developers will naturally find themselves in. When you're an "app developer" it is easy to focus on the app and not the think of the app as part of a whole product. I'm certainly guilty of this from time to time. We put a lot of thought into what we can do within our apps to improve our customers' experiences (and hopefully our business' revenue), but it can seem unnatural to focus on how we can break out of that screen. After all, the app is the product, so why look elsewhere?

(Which explains app developer mistake #1: always finishing the app then working on marketing it 1 week before launch. The app will just sell itself, right?)

Relying on in-app messaging during Slopes's brief screen time was even more problematic because of the fact that Slopes isn't the kind of app that a user will open daily or even weekly throughout the year. I'm very seasonal. Targeted and timely in-app messaging could help but it is very tricky to get right with such time constraints. I've got a lot I'm trying to talk to customers about at any given time: trying to help them discover features & educate them, trying to nudge them along to moments of joy that'll help them get Slopes. Oh, and I'm also supposed to be up-selling.

The thing is, though, not all product messaging needs to be synchronous along side the user's on-screen experience. As a product owner I have to be aware of not just the messaging that's right for any given user (based on where they are with using your app + what messaging needs to take priority over others) but also how receptive the customer will be to hearing any message right then and there.

My messaging is fighting against them just trying to get something done quickly because the outside world is demanding their attention. They've just finished a day skiing and they just want to save their day and get back to taking off their ski boots. So sadly the right message at the wrong time gets ignored. My perfect messaging instead can get in the way, leaving users quick to dismiss whatever message I'm trying to give them.

Sometimes messaging works better if it is a bit asynchronous. Give them a bit of time to go about their day, get some immediate use out of your app. Queue up the messaging in a way they can async go back to it, when they have time to process things.

So I was excited: with a much better chunk of users give me their email I'd finally be able to try out another SaaS trick: lifecycle emails. Sending out an email at key points in the customer journey to guide them to the next step, ultimatly aiming to keep them coming back to Slopes year after year, and hopefully making some purchases along the way.

Lifecycle emails are tricky, though. I've seen way too many companies abuse it just to keep people "engaged" (which usually results in emails from that company quickly finding themselves automatically flagged as spam). I've seen others seemingly implement it to check the box on their roadmap, but the marketing isn't particularly thoughtful as to how it is helping customers along.

But I knew that doing nothing was a wrong answer, too, because lifecycle emails have been shown in the SaaS world to work, and sometimes have huge payoffs.

So one of this season's goal to finally start experimenting with this kind of marketing. I've gotta start working to learn what works and what doesn't for Slopes in this arena of marketing outside of the app itself. I'm trying this 2 years later than expected, but hey, such is the indie life. As usual I probably left money on the table in favor of shiny new features I wanted to work on. 😅

Originally I was going to do all of this in-house, but I was pointed to Vero by another app founder, and decided that I could offload a bunch of problems that have already been solved in this space. For example I knew I'd be wanting to try new flows / emails as I learned, and the idea of making some dynamic system to let me (or someone non-technical) edit those workflows w/o code wasn't enticing. I just wanted to focus on the aspects that were specific to my business, not implementing branch logic, job delaying, and a bunch of other crud.

One thing I underestimated was the amount of work it would be to generate all the events I needed to power all my messaging. The ski niche once again complicated my life. Slopes can't just say "do this on their second day recorded" (which first of all, I have to be able to group multiple recordings from one day into a single event where needed so I don't trigger the day 2 messaging because they recorded once after breakfast and once after lunch), it has to be "the second day of this season". Do "such and such" if they haven't bought a pass this season but they have recorded 4 times this season.

But a week later it is all done, and all my workflows are online. I've got some workflows in place now that I'm very curious to follow / tweak.

Now that Apple gives us a server-to-server notification when a customer disables auto-renew, I have an email going out 10 days before that subscription without auto-renew on expires to remind the user about it. They bought a Slopes subscription a year ago and might have turned it off at the end of the season just to be safe. Totally fair. Without this email I'd have to hope that they just happened to open the app within the two weeks before it would expire so they'd see the in-app messaging I added. Without extra outreach effort like those two, they'll likely resubscribe anyway this season, but maybe a month after the original subscription expired. Which means I'm back to that 30% cut from Apple for a "new" subscription vs the 15% cut for a renewal. This one email might save me 15% of my revenue per customer in situations like this.

I'm also using these emails to help offload some of the messaging / reminding I'd have to do in-app. For example when a user buys an Annual Pass this year, they get 2 free Day Passes to share with friends (partly inspired by Vail's Epic Pass and the 6 buddy passes you get when you buy it). I mention this on the buy-a-pass screen, but I'm venturing this bonus is secondary thought at the time of purchase. And directly after the purchase I want to prioritize getting them to use the features they just paid for and fall in love with all the cool new stuff they can do, not spam them with a reminder to send those bonus passes. Now I get the chance to remind them in their purchase confirmation email, a little bit later, that they should go give the 2 free Day Passes to a friend.

Slopes has a total of 10 lifecycle workflows like these right now (which can contain any number of email sequences / branch logic, etc). We'll see how they go throughout the season.

It is so easy to rely on Apple to do everything for me, send my customers purchase confirmations and remind them of an upcoming renewal, but these lifecycle emails  help me build a relationship with my customers outside of the App Store.

Because at the end of the day I need to be interacting with customers at these key points to take the opportunity make them my customers, not just Apple's.