Kickstart: launch retrospective

I launched Kickstart on May 14th, and the response from users has been genuinely incredible – so many happy App Store reviews, a ton of emails with feature requests, and – *cough* – just a couple of bug reports too.

The headline: the app had just shy of 3,000 downloads in the first week, reached #2 in the Mac App Store’s Developer chart, and had three updates shipped since launch. The biggest thing I got wrong is just as clear: two months after launch, I still haven’t contacted the press.

Here’s what went well, what went less well, and what’s coming next, so other indie developers can learn from me and do better – there’s a clear checklist at the end so you can avoid my mistakes! (As the famous Despair Inc™ sign says, “it could be that the purpose of your life is only to serve as a warning for others”.)

What went well

• TestFlight: The first test build went out February 2nd (two months after the initial commit), and the final TestFlight build was only a few days before release in May, so the initial release had months of fixes and improvements behind it. The end result was pretty solid – there were no serious bugs on launch. (Thank you to everyone who took the time to help improve Kickstart during those early betas!)
• Launch: Kickstart had a fantastic launch, with just shy of 3,000 downloads in its first week. Most of those were preorders, concentrating months of interest into release day and helping drive Kickstart to #2 in the Developer chart, behind only Xcode. That is exactly what preorders are for, and Apple explicitly says preorder volume can contribute to early visibility and stronger chart placement.
• Updates: Despite being in Cupertino for two weeks and Indonesia for another 11 days, I’ve managed to ship three updates adding significant new features and bug fixes.
• Reviews: I’ve had an absolute wall of five-star reviews on the App Store, and I am beyond grateful – I’m listening and replying to every one, and they just keep coming. Many other folks email me with requests, and I do my best to reply when those requests get fulfilled in app updates.

What went less well

So far this picture probably sounds quite rosy, but I’ve made a bunch of difficult decisions and mistakes along the way.

First, just to get the initial version shipped I had to withdraw a few features that I couldn’t get in shape in time, all at the last minute. For example, support for Apple Ads got withdrawn because I couldn’t get a good enough algorithm to provide meaningful advice, macOS competitor search got withdrawn because I didn’t have time to get the UI right, and screenshot editing support got withdrawn because I couldn’t get my code to match what’s in my head – and still can’t, because this feature has yet to ship.

So, although it’s great to see big updates being released in the weeks after the initial launch, most of that work was me going back and completing features that were already 90% finished.

Second, over the five months of work it took to build the initial release, about half of that time went into one feature: the video editor. I got really carried away, and almost burned myself out working long hours to make it better and better. I wanted 3D device support, I wanted App Store badges, I wanted AI narration support, I wanted subtitles, and more, and as I worked the feature list just kept ballooning.

If I were starting again today, I would have cut the video editor from v1, shipped almost three months earlier, then added it in a future update.

Third, often during development I would stop coding entirely and start writing about Kickstart – I sketched out countless blog post ideas, and turned many of them into first drafts. In retrospect this is pretty clear procrastination from me: I’ve been a writer for 20 years now and love writing, so every time I hit a hard coding problem I would fire up iA Writer and just start a new post idea – only to return to coding an hour or two later and leave the writing to sit as a draft.

This is – bluntly – catastrophically dim of me, and I need to stop wasting time here.

Fourth and most critically, I still haven’t reached out to any press about Kickstart. I keep thinking, “I’ll do it when I get feature X done…” but then feature X gets implemented and I move on to saying I’ll wait until feature Y ships. This is – bluntly – catastrophically dim of me, and I need to stop wasting time here.

On the flip side, this does at least give me a clear roadmap for the months ahead:

• Go back and finish the screenshot editing feature so it fully matches what I set out to create.
• Make sure I show people just how darn good the video editor is, so all that work actually counts for something.
• Go back through all my blog post drafts and start polishing them up for release.
• Reach out to the press after I finish the current release. That will mark the return of all the features I had to cut before the initial launch, making it the right moment to tell the wider world.

Managing the launch

Getting a great launch takes a number of steps, and I think I hit most of them:

• I submitted the first approvable build to Apple nice and early, so I could get a preorder link.
• I had a website in place very early, with logo, brief explanation, and a preorder link to the App Store – the bare minimum required to get moving.
• I’d worked hard before launch to build awareness online, mostly through social media.
• On launch day itself, I spent the whole day spreading the word.

The result was that Kickstart reached #2 in the Mac App Store’s Developer charts, behind only Xcode – a great start!

Like I said earlier, please don’t sleep on preorders. They give you a public App Store page to share before launch, and on release day the app automatically downloads for people who preordered it. In my case that turned months of prelaunch interest into a very busy first day; App Store Connect can show you the sources and territories behind yours, so you can see whether the same thing happened for you.

Fixing early bugs

Despite my best efforts (and heroic help from the many folks on TestFlight!), Kickstart inevitably shipped with some early bugs and missing things that needed to be fixed quickly. The chief ones were:

• The keyword tracking functionality struggled when people tracked over 500 keywords. This was me vastly underestimating how hard folks would push this feature – I thought 20–50 would be about average, but some people were tracking several thousand. This was fixed through some careful Swift concurrency work: it’s all done in the background now, with careful queuing and improved caching, so it now happily scales into the thousands.
• Foundation Models was repeatedly struggling to generate some Build in Public posts; I was filling its context too much, so apps with long descriptions would overflow and halt. I fixed this by creating a fresh model session for each attempt, rather than letting earlier attempts fill the available context.
• I suggested that folks submit their apps to public directories, but didn’t provide direct links to those directories. The fix was of course trivial: I added the links.
• The Build Insights functionality was really, really slow. This was entirely my fault: I had brought in code from my Sitrep project to do a deep scan, but then I extended it further and further. The final version used only maybe 10% of the results, but it still did 100% of the work, so this was at least an easy fix – delete stuff!
• The video editor was being too pushy with its keyboard shortcuts, often overriding system-level stuff like copy/paste for text. This was fixed through changes to SwiftUI focus, but I think there’s still more to do here.

Obviously I wanted to ship without those problems, but developers understand that bugs happen. What matters is listening, fixing them quickly, then writing back to let folks know their feedback made a difference.

User feedback

Kickstart has received so many reviews from users, and I’ve replied to every one. Some selections:

• “I can’t stress enough how good this app is.”
• “This app is incredible! There is just so much in it which will be of such value to all developers.”
• “I’m an indie developer and this is THE app that I never knew I needed!”
• “I’ve been an app developer for a while, and I wish I would have had something like this when I started building my apps.”
• “All I had to do was open one of my projects in the app and suddenly I had 100 new ideas for everything from social media posts to keyword SEO to user reviews to… well, I’m still exploring.”
• “I cannot think of the last time I found an app that was so useful to me as an indie app developer.”
• “Incredibly feature rich toolbox and I’m in awe of the depth and breadth of tools available.”
• “I emailed Kickstart support to request a new feature, and Paul responded right away, and rolled out a new version that included my request a few days later. Color me impressed!”
• “The app is jam-packed with features and provides incredible value - even on the free tier. This is an indispensable tool for indie devs!”
• “I love how you distilled your app-making experiences into an app, it was an instant subscribe.”
• “As an indie developer, I’ve tried a lot of tools that promise to help with App Store optimization, but Kickstart is one of the few that immediately earned a place in my workflow.”

Reading reviews like these keeps pushing me to do more, because so many people are getting huge benefits already and we’re only two months in. I get regular emails from users asking for features, and I’m prioritizing those over my own roadmap – yes, I know where I want to get to, but having actual feedback from users always helps keep me focused on what matters now.

Where next?

There’s one big feature users regularly request for Kickstart, plus three more features I want to get done to match my own plan.

First, the feature users are asking for, because that is my top priority: supporting multiple App Store Connect accounts in the app. Right now it supports only one account, which is annoying for folks who spread apps across different accounts.

This work is already underway: I’ve written my first pass of the code plus some tests to prove it works as intended, so now I just need to go back through the code carefully, stress-test it, and decide how to surface it in the UI.

As for the three features from my own roadmap:

1. Finish screenshot editing. In theory this is as simple as a static version of the video editor, but in practice the implementation I want has a really high bar for correctness – I’m already about two weeks of work into this, and I suspect there’s at least another week to go just to nail this one feature.
2. Produce small, inline tutorials to accompany specific features such as the video editor – when folks see what it can do they can really see the value in a dedicated video editor for indie app developers, but right now the app doesn’t show that at all.
3. Complete integration with App Store analytics, keyword tracking, and Apple Ads, so Kickstart can present a single heads-up display of popularity, position, ROI, and more. Annoyingly this requires the new Apple Ads API to ship, which Apple says will happen “summer 2026”. Hopefully soon!

Stop reading, start doing

Like most people reading this, I’m an indie developer doing my best to make something great. I got quite a few things right, and also quite a few things wrong, and that’s just normal – launching stuff is hard. It’s tempting to think a successful launch means a perfect launch, but really it means a prepared launch followed by fast, visible follow-through.

So here’s the checklist I promised – my whole launch, good and bad, boiled down to four things you can do right now:

1. Put every launch step on the calendar today. First TestFlight build, preorder page, website, press outreach, launch day – all of it. My first build went out more than three months before launch, which gave testers plenty of time to find problems, and preorders turned months of prelaunch interest into nearly 3,000 first-week downloads. Don’t treat marketing as a reward you unlock when the code is perfect – it needs to ship with the app.
2. Split your remaining work into “must ship” and “can wait”, then try to move at least one feature into the second list. A great feature in a later update is much better than a nearly finished feature delaying your whole app – or burning you out before launch day arrives. (I should definitely have pushed the video editor back to a later release!)
3. Write down your procrastination pattern. That’s the thing you reach for when the real work gets scary – mine is drafting blog posts that never leave my laptop, and telling myself I’ll contact the press “after the next feature ships,” but maybe yours is planning a v2 roadmap. You can’t catch yourself doing it until you’ve named it.
4. Decide where feedback will arrive and how you’ll track it. Good ideas and important bugs mustn’t get lost in the noise, because people will surprise you. Remember, I planned keyword tracking around dozens of keywords, and some users brought thousands. Read every review, fix what matters, and don’t forget to tell people when their requests ship.

You won’t get everything right – I certainly didn’t. But ship something you’re proud of, listen carefully to user feedback, and keep moving, and you’ll be fine.