James' Audiolog: Indie.am

App Store review times are getting longer, probably because a lot of people have Claude Code subscriptions and they're pushing Swift apps to the App Store in record numbers. Apple used to have a very small ecosystem of individuals who'd learned their programming languages and frameworks well enough to pass app review and submit apps. But now that number has likely grown 100x in a matter of months.

I think Claude Opus 4.6 was the first model I used that actually seemed to produce decent Swift code output — it could handle SwiftUI with a little bit of guidance. That was February. We're about six months past that date.

The last published report said Apple had 500 App Store reviewers, and before the introduction of AI-generated code, they were servicing about 100,000 submissions a month. Can you imagine how those numbers have probably changed in the last six months?

But I wouldn't worry about this at all. These are exactly the kind of scaling problems Apple solves on a regular basis in the real world. Their whole business — their bread and butter — is dealing with supply chain issues, bottlenecks, and scaling challenges like this. So eventually they'll figure something out.

But for now, it seems like we're all just going to have to wait a little bit longer for our apps to get reviewed.

Just a small realization: Claude can write Swift, Claude can reason about SwiftUI. Claude can write some passable Kotlin, and if you yell at it enough, it can produce a fairly usable interface for an Android app. Maybe it's not perfect today, but Codex and Claude are basically on the same level. A couple years from now, open source models will probably be able to take a stab at it as well.

Just thinking about it — someone can sign up for a free Cloudflare account, connect their domain, and Claude helps them set it up. They can publish static sites and workers, they get all the primitives, databases, things like that. They can publish and share what they make without signing up for a service like Lovable or something like that.

But for native apps, I'm just thinking about how in the not-too-distant future we're probably going to need to create something analogous to internal enterprise apps — something you can sign, publish, and share with friends, family, colleagues. Something a little bit better than signing up for a $100-a-year developer account and only publishing things to TestFlight manually, adding and inviting your friends and family one by one.

That workflow is complicated — maybe too complicated for people who are just asking Claude how to write an app. Not saying they're stupid, just saying it's not designed for, you know, maybe I want to build a photo-sharing app and share it with three friends and some family members. I guess TestFlight works for that, but the entire process — signing up for a developer account, Xcode, all of it — nothing's really tailored to amateur app developers who just want to share an app with a few close friends.

You still need app review to do a public TestFlight, and that probably wouldn't go away. But still, it's an interesting thought experiment: if I had a couple friends on Android and iOS devices and wanted to share an app with them, I have a developer account, so it's pretty easy — TestFlight, Google Play. But in the near future, not so distant, I could see a definite need for a personal app store, or developer account, of some kind.

A Waitlist SaaS is a web application designed to simplify the process for founders to add a waitlist sign-up to their product launch strategy. It sounds appealing, but is it really a good idea?

The concept of using a waitlist as a launch strategy was popularized by companies like Robinhood and Clubhouse. These companies created hype around their products by making sign-ups initially impossible, allowing only a waitlist. Users could invite friends or share on social media to move up the list. This strategy became popular for SaaS launches following these examples.

However, the success of Robinhood and Clubhouse wasn't solely due to their waitlists. Their real strategy was leveraging FOMO (Fear of Missing Out) and hype. They over-promised on their products, creating a buzz that compelled users to share the product to move up the waitlist. The waitlist added friction to the sign-up process, which could actually hinder conversion rates.

Consider this: 100% of visitors willing to sign up for a waitlist would likely have signed up for the product immediately if it were available. The waitlist conversion rates—whether a week, a month, or two months later—cannot exceed 100%. Would removing the waitlist have slowed down the hype and FOMO driving the marketing campaign? Possibly.

In conclusion, launching a Waitlist SaaS in 2026 may not be a wise idea, especially for solo founders or small teams. While hype and FOMO can be effective launch strategies, they require a level of execution typically found in more experienced teams. A SaaS that facilitates adding a waitlist sign-up process is not likely to be a mass-market strategy that inexperienced or small teams can successfully implement. These elements are probably the least challenging parts of a more complex marketing strategy that a skilled marketing team might employ.

All right, it took me a while to figure this out, but I finally put my finger on it. What bothers me about the Blue Sky app? It's really trivial, yet it's an anxiety-producing bother. It's not something I expect to be widespread, but it's the resemblance of feeds to tabs in a browser.

My mind does not handle tabs like a normal person. My OCD kicks in. Tabs aren't something you're allowed to let live for days, weeks, months, or an eternity in your browser. For me, tabs are a thing that's current and must be reckoned with immediately and closed as soon as possible. I don't have hundreds of tabs open. I have two tabs, three tabs, or no tabs. I have nothing on my desktop, and it's not normal, but it's the way I use tabs.

This is what bothers me very, very subtly about the Blue Sky feed design. There are tabs—tabs that are always open. And I can't escape from it. There's no end to it. It's a little disconcerting. It's something I've been trying to figure out about the app design, and it just dawned on me. It's the tabs.

Welcome back! Here's my latest update on what I'm working on right now.

I'm currently focusing on transitioning from the audio player format, which can be a bit challenging to read, to a text format that integrates seamlessly with an audio player. This shift aims to enhance readability and user interaction.

Initially, the idea was that people would embed audio players and not necessarily read the posts. However, I'm starting to embrace the concept that what users really want is a hybrid format. This format would offer both media elements simultaneously, allowing users to choose whether to read, skim, or listen. For instance, you might start listening and find it uninteresting, then decide to skim the rest or fast forward to a more engaging section.

This transition might require abandoning the old templates. Currently, there are four to six templates designed for audio-only blogs. I've added the ability to view transcripts, repurposing the transcript area to display markdown blog posts. However, this setup isn't the most reader-friendly as it's optimized for listening. A rework is necessary to better align with the blog post format.

As part of this transition, I plan to move to human-readable URLs soon. I'm also developing a feature to dynamically rewrite meta tags. Instead of relying solely on the title, image, and description, this feature will generate more robust social media post formats and automatically embed card tags. This improvement is progressing well and will enhance social sharing and search engine optimization.

Another focus is updating the share tags for video posts to ensure a more seamless experience. My ultimate goal is to iterate on these changes until you can effortlessly record a post, share it on social media, and view it as either a blog post or audio content. Achieving this will allow me to concentrate on the SEO component of the project.

Thank you for tuning in to this update. Stay tuned for more developments!

Hey there, welcome back. I'm James, and this is my indie maker update for Saturday.

What you're hearing is a new audio file format. Optionally, you can add a logo identity to the beginning of your personal podcast updates. This addition makes it sound a little bit more professional, a little bit more like a real podcast. However, right now, it's limited to one very generic, very inoffensive logo identity.

I handpicked and edited the logo identity to be short and very easy to add to any spoken audio track without requiring much tweaking to the way you record your audio. It works best if you start your audio in a certain way, like "Hey, welcome back" or "Hey, I'm James," instead of the more typical, boring way I usually start my audio recordings.

Hopefully, if this test goes well, this will be the track that is published and introduces the new feature. Thanks for listening.

Second Indie Maker Update of the Day

Aren't you lucky? Today, I spent about four hours fine-tuning my FFMPEG pipeline. Here's a rundown of what I worked on:

I experimented with a recurrent neural network to denoise the track. Additionally, I aimed to improve the audio quality by disabling certain audio helpers in the getUserMedia request. These helpers, such as echo suppression, noise suppression, and level normalization, are often applied by iOS or Android browsers. While they help in some cases, they can degrade the audio to something akin to telephone quality. By turning these off, I managed to elevate the quality to something closer to native recorder medium settings.

I made several tweaks to the pipeline that converts audio to MP3:

Overall, I believe I've significantly improved the audio quality compared to a few hours ago. I'm quite pleased with the results and look forward to testing how it performs on other devices tomorrow.

Hey there, thanks for tuning in. I thought I'd share a little bit about what I've been working on for the past few weeks.

For Indie.am, I've been developing a blog template that allows you to publish a nicely formatted static blog. This blog is automatically generated from your audio logs recorded in the app. You simply post as you normally do, and those posts are transformed into a well-formatted blog that you can use as your primary blog.

This project involves a few key elements:

I'm still determining whether the editing interface should be optimized for desktop or remain within the app. Since I'll be using this for my personal blog, I'll experiment to see what works best for me. Afterward, I'll share it with others to gather feedback and ensure it meets broader needs.

Stay tuned for more updates as I continue to refine this exciting feature!