Independent podcast apps are not growing as a category. This is not a particular secret, but perhaps you haven’t seen it stated explicitly. It’s the sort of thing that has to be inferred, but there’s plenty of available data1 if you look for it. While the podcasting sector has seen growth, this has occurred almost entirely on platforms like YouTube2, and the independent podcast app userbase has mostly just stood still.

You might have a theory that there’s a funnel and growth in podcasts *must* ultimately be good for the apps. Like YouTube and TikTok introduce people to the concept of podcasts via shorter videos, and as certain users become more enthusiastic about a particular creator or the whole concept, they migrate to specialty apps to ensure they never miss an episode. I like this theory. It’s a good story, but I see very little evidence of this happening. Instead, the apps are largely fighting to retain the same cohort of users who have been using podcast apps since ~2015 while the world moves on.

I can’t tell you this with absolute certainty. I have no concrete demographic data on my own podcast app, let alone anyone else’s. It’s a big world, so I’m sure somewhere out there a 21-year-old just downloaded Castro or Pocket Casts for the first time and thinks RSS feeds are awesome (if you are this person, please email me). But every number I can see indicates the userbase is both static and aging. Every new customer I talk to has used some combination of Apple Podcasts, Overcast, Pocket Casts, or Castro for at least the last 5 years if not the last 10. Some podcast apps are definitely doing better than others, and any given app can win users, but we’re all crabs trapped in the same bucket.

One might think that the podcast app incumbents are dinosaurs and an AI-forward podcast app aimed at riding current trends has an opportunity. In reality, no new podcast app seems to be gobbling up any substantial market share3 either. I mean why isn’t something like Snipd moving up in these app rankings? Why hasn’t any app released after 2020 gained any traction at all? That bothers me a lot more than any metric on Castro.

It’s a nice idea that all the “major” players are doing something wrong and there’s a cohort of users waiting to be unlocked. I sincerely hope someone does it, but it hasn’t happened yet. Waves of new podcast listeners may exist, but they aren’t downloading episodes via RSS, no matter how many podcast apps are being vibe-coded.

This is not a happy story I’m telling you, not for anyone who loves podcast apps like I do. Perhaps there are healthy businesses that get very few new users but instead gracefully age with the ones they have. Ferrari maybe? Buddy, smartphone apps are not one of those businesses.

That doesn’t necessarily mean the open podcasting ecosystem is doomed4, but the apps aren’t doing well and there’s no reason to think that’s going to change. I’m also not going to write a 2000 word diatribe on how it’s not a podcast unless there’s an RSS feed. That’s not my point. The world changes. I’m just stating the facts plainly so you have context on how I’m making decisions at Castro.

So I wanted to share some thoughts about podcast apps and what they should be building. This applies to Castro, but it’s not really specific to Castro. It’s certainly not any kind of roadmap or promise. I would rather work on flashy features to capture new users, but, reality being what it is, I have to think about things in terms of both the health of the ecosystem and what will actually help retain existing podcast app users. They’re the only ones I’m going to get.

Subscribe now

On Creator Intent

To a creator, the only real thing a podcast app can be said to have over a platform like Spotify or YouTube is disintermediated access to some of their best listeners. By and large podcast apps are just showing exactly what the creator drops in the RSS, and there are vanishingly few places you can get that.

Now most creators aren’t thinking about this in these terms, but some certainly are. Some listeners are as well, and it’s sort of the backbone of the whole medium. Podcast apps basically rely on the trust of the creators to exist.

I think this whole integrity-of-the-feed stuff should be taken really seriously. Not because I personally care about the sanctity of the RSS feed in my soul, but more that it’s the only thing we have. Also, as independent apps slowly become relevant to only a small number of hobbyists, those hobbyists are really going to care about the integrity of the feed. I mean trust me, I know those guys.

This is why I’m uncomfortable with certain changes others are making. Generating chapters and transcripts is explicitly messing with podcast content in a way we normally don’t do, and I worry it runs the risk of compromising the whole enterprise. Creators can provide transcripts and chapters if they wish, but I don’t see how it’s appropriate to do it for them.

In much the same way, I really, really don’t think we want podcast apps removing ads. If we’re just going to put our own generated stuff or remove the ads on your podcast, and we’re 1% of your listeners, which we also won’t give you any visibility into, I mean what are we doing here exactly? Why would a content creator sign up for that deal? I don’t think it’s that hard to imagine major shows not bothering with any of this and only posting directly to YouTube if we aren’t careful.

Perhaps generated transcripts are just table stakes and it’ll be expected everyone will have them, but for now these are not features I’m going to work on. Creator intent is too important. That’s not to say I think we should put our head in the sand and ignore generative AI. On the contrary, there’s probably a lot we could do I haven’t thought of. I just don’t think the juice is worth the squeeze on these specific features.

Private feeds

Paid private feeds are really great for podcast apps. In my mind it’s the best example of the business really working for everyone. The creator has a direct relationship with your customer, and we’re just facilitating a better listening experience that the user has chosen directly. I think we should do more with these. The way they work is messy, and at least on Castro we haven’t put in the time to make them first-class citizens. For instance, there’s very little connection between a public version of a podcast and its private equivalent. So I end up with two The Rest is History feeds and can barely figure out what I’ve listened to unless I slog through both or somehow connect them. It’s also really frustrating that there isn’t an easy way to listen to a public feed in Castro and then just quickly buy the private version for yourself.

I have a little trouble understanding why private feed providers like Patreon, NY Times, Substack, etc. haven’t taken a more active interest in preserving the medium as an ecosystem for just this purpose. Lots of people listen to The Daily, only a fraction of those listen on the NY Times app. If your existing customer is not going to be on your app, wouldn’t you rather they consume an RSS feed you control directly rather than on YouTube? I understand the users have chosen YouTube and Spotify, so companies have chosen them as well, but a little nudging to the open Internet would go a long way. But hey, I’m sure it’ll be fine, the pivot to platform video always works out great, right?

If there’s another boom left in podcast apps, there’s a good chance it will be set off because YouTube did something really evil.

Customers

At least one other thing podcast apps have going for them: their customers are fairly high value, which matters. On the other hand, as listeners they’re mostly anonymous and don’t want to be tracked. They’re difficult to monetize, and they fucking hate seeing ads... so maybe not that high value.

I don’t have any concrete proposals here. This is not something I’ve thought about a ton, but if there are any sacred oxen to be gored in terms of tracking, we should probably find ways to gore them that users will find acceptable. Anything we could do to make the open podcasting ecosystem more legible to creators and advertisers would have to be the correct tradeoff for the health of the ecosystem. Do you want to listen in your favorite app with the knowledge that your favorite podcast has some idea of who you are and can send you relevant ads, or do you want your favorite app to cease to exist? Them’s the breaks.

Video

Video podcasts should be embraced yesterday. There’s absolutely nothing about RSS that demands it be audio-only. Podcasts have never even been audio-only. There’s at least some evidence5 that video time is replacing audio. This is only going to get worse. Video is only going to get more prevalent, and there’s only so much time in the day. If you want to keep the users who are already with you, it’s a lot better if the video watching is happening in your app.

I’m a guy who loves a dumb hill to die on, but anyone still holding out on the only-audio-is-a-podcast hill is bananas. Support video. It’s one of the vanishingly few things that can help arrest decline. Huge shout-out to everyone who has made alternate enclosure happen.

Accessibility features

Mechanically, an aging userbase is going to have increasing need for accessibility support. Things like VoiceOver and larger font support should be prioritized. A well-crafted independent app can agonize over these and incorporate them into the product from day 1. Castro has always taken this seriously and will continue to do so.

Consolidation and shared infrastructure

I mean it’s just obvious there should be fewer of them right? I’m not going to pick which ones have to go, but in a static category with a lowering barrier to entry, you can’t keep dividing the pie and keep anything meaningful. I don’t know how to effect this outcome, but apps that don’t see a long future for themselves should merge into healthier ones or at least on some level share infrastructure. Larger userbases would give apps more leverage and more development resources, which would allow them to build better products and stick around longer.

Audio

Can we do more with audio? We don’t want to compromise creator intent, but it just seems like a lot of things could be done in this space. Castro’s playback code has barely changed over the years, but I’m still often told it sounds better than many competitors. Audio playback is weirdly neglected for an audio medium. There’s no sacred cow that precludes us from making things sound better right? It really feels like we should’ve invested more here.

Be frank with the users

Look, the only way this software will continue to exist is if people work on it or they pay others to work on it. The people who care about using their super special podcast apps are mostly the same people who cared about them five years ago, and there truly aren’t that many of us. That’s why I’m talking to you here now. I appreciate everyone who uses an indie app. You are my people, and you deserve to know where things stand. We’re just deciding what to do with the time we have left, but of course that was always true.

I’ve been listening to podcasts for a long time. Not as long as some I’m sure, but I discovered them in college and have been consuming them regularly since at least ~2010, starting with The Moth, This American Life, and Podcast Beyond. I suppose the first place I ever listened was iTunes on the Mac, but the first podcast app I actually used and cared about was DoggCatcher. This was years before most podcast apps we use today existed. Eventually, I graduated to PocketCasts when they were still an indie app. Then I wrote an Android app, Aurelian, and now run Castro.

So my history was scattered across a bunch of apps. I recently undertook a project to reconstruct as much of that listening history as I could in order to keep that data with me. Since podcasts are built on open frameworks, it just feels appropriate that none of this should be locked behind a proprietary app, even if I own the app.

Unfortunately, all my DoggCatcher listening is lost to history, like the app itself. For PocketCasts though, I was able to export actual listening history going back to 2018, and played episodes going back to 2015. So while I’d love to have a few more years, a decade of data feels pretty good. I started using Aurelian around 2022, and the last couple years I’ve been primarily using Castro. Using the method below, I was able to take the data from all three apps and build out one giant library over the past decade.1

Subscribe now

Doing the extraction

So the first thing we’re going to want to do is extract all our data from all the podcast apps we’ve ever used. Depending on the app this is either very easy or a little involved. A podcast is really just a URL with a flat XML file. Within that file, for the purposes of this exercise, there are only a few things we care about:

• Feed title

• Feed artwork

• Items

  • Item artwork

  • GUID

  • Title

  • Published date

  • Media URL (enclosure)

Because this is literally all a podcast is, any podcast app is going to store this information, either directly or indirectly. GUID is the most important attribute here. It’s the easiest way to keep track of episodes in the feed. Once I have the podcast URL and GUID from an episode, then it becomes trivial to map it from one app to another, and I know exactly what we’ve played, queued, etc. The first step is going to be going through all the apps you’re using and exporting each database:

Castro

Castro stores a backup file with the extension .castrobackup in your iCloud drive. This file is JSON, and lists only Castro public IDs. These look like the GUID above, but they’re actually internal UUIDs and don’t map onto the feed in the way we’d like. Luckily, Castro does expose this data, either through public REST APIs or Castro MCP. So you can access which Castro episode you’re looking at in either direction. If I have a Castro ID and I want the full episode data:

  Input (episode)
  {
    "public_id": "0d6d1c14-23b4-4cbc-96b2-106c06942635"
  }

  Output

  {
    "public_id": "0d6d1c14-23b4-4cbc-96b2-106c06942635",
    "feed_guid": "19263b9a-7ad2-11f1-aaed-3fa07ea54e9e",
    "podcast_public_id": "3878bc03-96bc-4457-b29c-1b1bdbebccf6",
    "short_id": "r7SxXj",
    "title": "The Odyssey: Hero of the Trojan Horse (Part 1)",
    "podcast_title": "The Rest Is History",
    ...
  }

That public_id is what you’re going to see in the Castro backup, and mapping in the other direction is equally straightforward. This episode is also available here.

Podcast Republic

Open the app settings and go to “Backup & Restore”. You can export the full SQLite database, which contains feed URLs and GUIDs, giving you everything you need.

AntennaPod

Likewise, this has a Database export feature under “Backup & restore” and contains this information directly.

Apple Podcasts

If your iPhone and Mac are syncing, you may be able to find the database at $HOME/Library/Group Containers/243LU875E5.groups.com.apple.podcasts/Documents/MTLibrary.sqlite. Then you may be able to use the fact that Apple generates identifiers like md5(feed_url + guid)to get something useful out of this. But if you want a more comprehensive one-time data export, it’s easier to go to privacy.apple.com, export your data, and ensure you check “Apple Media Services Information”. That’s going to give you at least feed URLs, and it’ll likely be enough to reverse engineer your playback history.

PocketCasts

Go to Profile Tab → Help & Feedback, then in the menu “Export database”. Unfortunately, PocketCasts’ database does not list feed URLs or GUIDs, only their own public IDs. Mapping these IDs back to the feed URLs and GUIDs is not too difficult, and PocketCasts is open source so I’ll leave that bridge as an exercise for the reader. One trick to know: once you have a feed URL and an enclosure, you can simply pull the XML yourself and compare enclosures as a reverse-lookup to find the GUID you are looking for (grepping by title and publish date can also work).

Overcast

Ensure your account is syncing. Log into Overcast on the web, go to Account, and export the OPML with “All Data”.

Overcast uses numeric IDs that are formulaic, and you can derive the share page (e.g. overcast.fm/+BClHgIbP-s) from that ID. You can see the details here. Similar to PocketCasts, once you have the share link, you have an enclosure URL, so you can just do the lookup using the RSS feed to get the GUID.

Building the data

So we have a set of databases from different apps. We want to define a data model between them, and store it all in one place. One way to do this is with a local SQLite database. Your tables might look like this:

You can think about this data model2 if you’re old school, or just tell Claude Code to figure it out. The point is we can have multiple rows for each episode that represent each app, allowing us to merge the different libraries together as needed and also split them apart.

Once you’ve set up your database, you want to write a Python script for each app to map it into your new database format, along with any needed business logic to bridge the GUIDs as needed for the relevant apps above. I did something very similar a few years back and it was very painful. I spent hours on tests to ensure the data all translated cleanly, building the business logic to parse and compare the XML, etc. It’s completely wild that Codex or Claude Code can just knock this stuff out for us in a way that truly makes 2022 feel like the dark ages. Here’s a sample of how these scripts work. The linked code is definitely slop, and it will likely be easier to generate them yourself but feel free to use it as a reference or give it to an LLM to help it understand the concept.

Your beautiful library

Once you have your databases and run your ingestion, you’ll have your full podcast listening history all to yourself and free of any app. You can just stare fondly into the eyes of your SQLite tables if you want, but there are probably more interesting things we can do. We can make an HTML viewer like this:

We can also graph listening over time, build a cover flow, or create a GitHub-style daily chart. (These are seed with fake data for prettier visuals.)

Now when I want to know if I’ve listened to an episode before, I can search on my desktop instead of going through all the different apps. This is extremely useful for shows like Casefile and Criminal, where I may have dropped off a few years ago but can’t remember where. I know the longest episode I’ve ever listened to (not surprising it’s Dan Carlin), and that I’ve completed 9,931 episodes across 886 shows! Stay tuned for number 10,000!

What next?

One thing you might want to do is update your local library regularly. Castro does a daily backup to your iCloud drive, which makes setting up some kind of script to regularly ingest your listening fairly straightforward. Any podcast app that lets you do regular backups to Google Drive, etc., would allow you to keep your external library updated.

At some point, you’ll probably want to pull this library into a podcast app to actually make it useful. If you use Castro, the MCP will help build a backup file that contains all your listening history from forever. I would highly recommend that option. If you want to export your full library into another app, your best bet is going to be AntennaPod or one of the other apps that include RSS feed URLs and GUIDs within the database itself. You can presumably just use the initial database you exported from that app as a guide, and build up your new database using the same schema. Then just import right back into the app. For an app that relies on its own IDs, it’s going to be a little more involved, but it’s certainly possible. Whatever you do with it, you’ll now have a fully external backup, and you’ll know your data is safe no matter what happens to the app you’re using.

I would say the least useful comment on the internet is that you hate subscriptions. It’s like hating rules. It’s too abstract. Some are good and some are bad. I believe subscriptions for mobile apps are the best thing that has ever happened for both indie developers and iPhone users. If you like an app, you should buy a subscription.1 If you like it but really can’t pay for it, that’s okay, you don’t have to use it. But let’s be honest, if you’re reading this you can probably pay for it, and if you’re bothering to complain about the subscription then you probably want to use it. Before firing off an email or a tweet complaining about subscriptions, you should really, sincerely, consider not complaining and just paying the money instead.

I like subscriptions because, in the worst kind of corporate management speak, subscriptions align our interests. You pay for the app for the duration that you see fit. You pay for it because it gives you value. I have that money to pay for infrastructure and improving the app. I’m incentivized to do a good job so you’ll pay me again next year. If you stop using the app or I stop holding up my end of the bargain, you stop paying. It’s a fair deal on both sides. I genuinely can’t understand why this notion is abrasive to so much of the internet. I mean I understand why you might not want to pay for a subscription to your Honda garage door opener, I wouldn’t want to either. But for software on your phone that is constantly being maintained and updated, with a cloud component, how else do you want things to work exactly?

Of course, if you like living in a world where Meta, Amazon, Apple, and Google run every single thing on your phone and ultimately your life, that’s great for you. I hope you enjoy your scrolling and your ads. I don’t love that world. I like the one where talented individuals work hard on making great software like craftsmen, and they just get paid for it. But how should they be paid? Well, in a way that will allow them to make a living building the thing I like. Something recurring probably. At regular intervals and at amounts large enough to be meaningful if a few thousand people appreciate their work. Don’t we want nice things to exist?

Subscribe now

I understand some people are against subscriptions because they want to feel a sense of ownership. Wait, no I don’t. I’m honestly not sure what that means. You can’t take Cal.ai and Flighty out of your phone and put them on your shelf. These things are only going to work as long as they’re maintained and updated. It’s not 1995 anymore.

Okay, maybe ownership isn’t possible, but I just want a one-time purchase, you might say. Maybe for budgeting purposes you don’t want to lock in future obligations. And I guess I can understand that, but I can’t help feeling like you have in mind that this one-time purchase is going to be $5 total. And I’m here to tell you that’s not happening. For anything that takes effort it’s going to be more like $200. And if you’re throwing a fit over $5/month you’re probably not going to shell out $200. Even if you’re willing to pay that, it seems like a bad deal for you. You paid $200 up front and I can disappear next month, with no incentive to keep you happy with the app. Why would you want that? Upgrade pricing also doesn’t solve this. The App Store doesn’t support it properly, but even if it did, versioned upgrades incentivize developers to chase shiny features that people might pay for rather than improving their app and building for the long haul. It makes the product worse. If you’re arguing for upgrade pricing, it’s likely because you don’t see yourself buying future versions and just hope you’ll get the bug fixes for free.

“Okay, okay, but this app doesn’t have a backend, and it’s actually already perfect and never needs to change at all. So why can’t I just pay this one time and use it forever?” Hmm, you really love this iPhone app so much, but you want it to look like iOS 15 forever? You don’t want it to support Liquid Glass? I think you do, but even if you don’t, APIs get deprecated. Crashes come up on new OS versions. Anything remotely complex is going to need some maintenance. Sure, you say, but it’s just a little maintenance. It shouldn’t take much, and it would only be once a year. So how should we handle that? Maybe paying yearly would make sense? Like a subscription? You can decide what price point is worth it to you, but you’re not going to convince me subscription is the wrong model even for an offline app.

Oh I have too many subscriptions, you say, and I get that. But do you really need Hulu, Disney Plus, Netflix, and Spotify? And are they all more important to you than your favorite apps on your phone? If the app is not important to you then by all means don’t pay for it. This is not about charity. But if you do love an app and are just objecting to the business model, stop doing that. You’re wrong. The business model is correct.

I really don’t know where people got this idea that mobile apps aren’t serious software and this software shouldn’t cost money, but it’s pervasive. Every single day, a surprising number of people sit down and type out a message either to developer support or just on their favorite social media app to remind app developers that charging a subscription is barbaric and we should be ashamed. I truly can’t believe these people are real, but I’m not ashamed. If you are someone who does this, I beg you, next time at least say it to their faces instead! Take your favorite indie developer out to coffee, look them in the eye, and tell them the $5.99 you just spent on them should be good to cover their work until they die.

However, what I found is this whole thing didn’t work as I thought it would. Sure sometimes we were able to wow customers, particularly when we responded right away with an exact fix for them. But the vast majority of our honest, thoughtful answers were deeply unsatisfactory to users, and it often annoyed them more than anything else.

Here are my unscientific categories of support requests/emails we get and why the approach is flawed.

Subscribe

Complaints about subscriptions and pricing

I have already thought about this a great deal. I am not changing anything based on your email. I can of course try to justify why we charge what we do, and I’m happy to explain why an essential app is worth your money, and why software lends itself to subscription so well. But in reality the user is not satisfied with this. I can think of exactly one customer in two years who was surprised that software costs money and we’re actually doing work every day, thus charging a subscription makes sense. 99% of the time, no matter how carefully or kindly it’s explained, the reply will be more negative than the initial email. I tried just offering an additional 30-day trial to anyone who asked, but this didn’t change the sentiment of the emails, and those trials had a substantially lower hit rate than our typical free trials. I could fill several blog posts with thoughts on subscriptions, but suffice it to say, emails about pricing are not helpful in terms of building rapport.

Bugs

These emails are genuinely useful to me, the receiver. I want to know about the bugs people are experiencing on a daily basis. In the best case, I can say we know about this and are actively working on a fix or have already fixed it. Due to the way shipping works in the App Store, it’s common for a bug to be fixed but not distributed yet. Those are great emails to answer and we can satisfy the customer.

But there’s a long tail of bugs that are not like this:

• We have heard this before, but we cannot see it or replicate it. The user gets to do work for us and/or get no resolution. Bad experience for them, bad experience for us, mostly a waste of everyone’s time. Very, very occasionally a user will send a detailed report with steps to reproduce or a meaningful factor. Still we need to get these emails to know what people are seeing.

• We have never heard this before. User can provide details for us, but if others aren’t experiencing it, it’s unlikely to be prioritized. Still, useful signal for us.

• We get no information. “It doesn’t work” is the whole email. Not much I can do without the user doing more work, which they understandably aren’t interested in doing.

• We know about this, but fixing it is a decent amount of work or low-priority because it’s not a big deal or few users see it.

None of these categories seem to build any meaningful rapport. Any honest answer I give is deeply unsatisfying to both parties, and we typically have better data from telemetry or crash logs than the emails provide. It’s certainly useful for us to receive them, but there’s not a helpful response I can give. In retrospect, this seems obvious, but before owning Castro it was not obvious to me that a human response detailing why I am unable to solve your problem today and am not even going to try is about the worst thing a user can receive!

Nuanced questions / human intervention

Sometimes we get nuanced questions about App Store processes, store issues, specific locales, hyper-specific podcast questions, etc. A user recently had a Castro subscription on two different accounts at different times and wanted to let one expire while ensuring they got the months they paid for. We were able to resolve it for them quickly. People do genuinely appreciate this kind of responsiveness. So yeah, the idea probably works here. Unfortunately, these are less than 1% of support emails.

Customers genuinely confused / something unclear

This comes closest to building the customer relationships I was hoping for, with the worst results. Customers email us with confusion about how podcasts work, how the App Store works, how their Mac works, and any number of tangential issues. What tends to happen is the same users do this over and over, and once they find out we answer, the requests get more frequent and more burdensome. I think I heard Patrick McKenzie use the term “pathological customers”. While in theory building rapport and loyalty sounds nice, what you actually end up doing is spending a lot of time on the people who ask the most of you, but their subscription dollars aren’t worth more, and they’re rarely satisfied. You end up feeling taken advantage of.

Feature requests / general thoughts

Similar to the last category. Good in theory, sometimes useful, but often the same small, unrepresentative segment with strong thoughts. Woe to the team who implements a suggestion based on an email, you are likely to get a full product roadmap soon!

Castro is an opinionated app and I’ve thought a lot about what we’re building and what we’re going to work on next. It’s unlikely I’m going to implement the request. If I did, by catering more to persnickety power users, we run the risk of alienating newer users who don’t know how things work. But our power users probably aren’t going anywhere, at least they’re a little harder to shake, and alienating new users is the death of the product.

To the user, any response aside from “Okay, we’re going to build that right now” is meh-to-negative. Various honest responses, such as “I thought about this or tried it in the past and it unfortunately didn’t work very well” are not going to knock their socks off. These just don’t do much in terms of loyalty and rapport.

Conclusion

Ultimately, for us, putting too much time into support isn’t a differentiator, and it’s often counter-productive. The person who paid our subscription but would never think about emailing us and asking for something for free deserves a great app just as much as the person who emails us every week. If we have a specific resolution or fix for their problem, great. If not, we’ve had better results by saying we appreciate the email, we read them, and we are actively working on the product to improve the issues. Avoiding explanations and specifics tends to get a neutral response and doesn’t suck anyone in or waste too much time. In other words, the best approach for us is what most companies do. Because building loyalty or rapport at the moment something isn’t working and the user is frustrated hasn’t worked. The real positive experience comes when you actually improve the product, so that’s where we’re spending our time.

Subscribe

Future topics will include:

• Lessons learned from buying apps

• Customer service / help desk

• Open ecosystem challenges and opportunities

• Why subscriptions are the right business model for apps (no, really), and how to build subscriptions worth paying for.

• Future of indie software and why it’s bright

I promise to talk about AI only when required and write all the words myself. Any resemblance to slop is purely the fault of the human author.

Thanks and talk to you soon!

- Dustin