How My App Failed Even Before Making it to The AppStore
I had one goal: build a spaced repetition app I’d like myself to use.
I’ve tried Anki, and I don’t like it. It’s too slow: it takes several seconds to get to the screen where you can start revising cards.
When I’m standing in a queue waiting for a meal1, if it takes more than a second to open the damn app, I’m not going to use it. Revising cards should be easy and frictionless.
Or, that was the idea, anyway.
Blue box about Spaced Repetition
Spaced Repetition is a learning technique where you revise things based on how often you forget them. The best time to revise something is right before you forget it. There are several algorithms that try to approximate this.
In addition to the spacing effect, this works well because you’re never trying to revise everything at the same time. Imagine having 1000s of flashcards that you need to revise everyday, capturing all your knowledge. It’s impossible.
By staggering things out based on how well you remember them, you only revise about 5 cards every day, and manage to remember everything.
Phase 0: Gathering Requirements
I have an iPhone, so it had to be an iOS app. This meant learning iOS dev and Swift from scratch. This became a side goal of the side project: get to learn iOS dev.
Of course, I could’ve gone with React-native or some other framework, but I stuck to native iOS because it had to be blazing fast.
It’s funny how I can write this one line above in a few minutes, while it took me ages to make this decision.
Further, Anki is complex and it’s easy to not use it well. There’s thousands of words here about what can go wrong. I decided to get rid of Anki’s flexibility to make it hard to fall in failure modes.
Phase 1: Scope Creep
While thinking about the project, I’d get excited.
Why only me, there must be lots of other people who’d want this, too!
And while I’m learning things, why not learn other things as well? I’ve been meaning to learn Lisp as well: let’s build the server in Lisp.
Warning to future me: The smallest experiment I think I can run is rarely the smallest experiment I can run.
So, now I’m building this blazing fast app that has a server built in Lisp.
My rationalization for the server: HackerNews loves Lisp2. So, if I build something with Lisp, it will get more upvotes, which means more people coming to the landing page, and so, more sales. This is hilarious in retrospect.
Through all this, I already had a design for the app in mind. Swipe left if you don’t remember the card’s answer. Swipe right if you do. Tap to show the answer. On start up, you get this card view.
You can then go to a second screen with a list of cards, a way to add cards, and remove them.
- The quickest thing - revise, hence one-click.
- The slowest thing - thinking about new cards to add, hence two-click.
Of course, if there’s a server and sync, I’d need a login as well. Oh, and what about export? That gives people confidence that their cards won’t get lost.
And since I’m competing with Anki, a quick import from Anki.
This was daunting, given how little time I had (an hour after work every day - I didn’t want to stop other projects because of this).
Phase 2: Cutting scope
Since I was doing the server in Lisp, I didn’t know where to start. So, I began with the app.
Note to future self: You have a set amount of Complexity points. Spend them wisely.
A few days of flailing with the app, I realised building the server and login etc. etc. was dumb.
I forgot I hadn’t yet validated the idea. In my mind, since I was thinking about this every day, and my brain hadn’t rejected the hypothesis, it was a good idea. Mere exposure effect?
I caught myself, and figured I had to get the beta in front of other people to validate my hypothesis.
Logging in was an extra step that went against being fast.
So was the server sync.
So was the export. I could add it later.
In the end, what I built was an iOS app that had two features: the regular revision for cards, plus a daily reminder card section: this was for building habits of mind.3
I decided to make things as easy as possible for the user, building the best practices directly into the app. You don’t get an option to make multiple decks, you don’t get to choose when you want to revisit the card. I used a proxy for revisiting: how quickly do you answer.
This way, I recreated the SM2 algorithm without explicit user input. Just like Anki, I randomized things too.
I’m proud of what the app does right now.4
Phase 3: Managing emotions
What surprised me the most was how difficult it can get to work on a side project.
I developed an aversion to the project. I didn’t want to complete it.
However, as soon as I’d start, I’d get into flow, and a couple of hours later, feel great about the progress.
It was an unexpected emotional rollercoaster. More than anything, it surprised me. I felt fear.
Fear of not knowing how to move forward. “I don’t know how to solve this problem. I don’t know iOS development. I should first do a course on iOS where someone holds my hand through everything.” (LOL)
And once I’d solve each problem: “I’m a genius! Bring on the next one! …. Oh shit, this one’s harder.”
I’d cycle my way through more and more problems. And I’d get comfortable with this uneasiness.
I sometimes notice this uneasiness at work, too - when I don’t know how to do something - but work is different. I spend 5 set hours every day trying to attack work problems. I don’t need to first choose the time and then work on it. The time is already chosen for me.5
It’s a whole different ball game when you can choose to run away and watch Netflix without consequences.
If I go back in time, this post will seem pretty dumb to past me. Which way do I run? isn’t really a question. Of course you’re always supposed to run towards your problems and solve them.
Phase 4: Seeking Validation
QuickReps was too niche for my friends. None of them had heard about spaced repetition, and this reminded me of something I’d heard from Rory Sutherland6:
Convincing people that X is a problem and then telling them why your product solves X is MUCH harder than convincing them your product solves X, where they already believe X is a problem.
Every extra thing you need to convince people of is a barrier that multiplies.
I first had to explain spaced repetition, then talk about why regular learning is inefficient, and then help them choose QuickReps over Anki.
But these people were my friends, so I got them to at least try the app. I did the same.
In retrospect, I should’ve seeked a community already well versed with spaced repetition for feedback.
The crushing blow, with all my assumptions, was that spaced repetition wasn’t an appropriate tool of thought for me.
I didn’t want to use it. My assumption that I didn’t use Anki because it was slow and crappy was wrong.
QuickReps was blazing fast, smooth, and much more restricted than Anki.7 However, I didn’t use it.
Phase 5: Acceptance
I’d read so much about starting a side project, making something users want, etc. etc. It’s easier to follow this after tacit experience, rather than just theory.
I still have a few finishing touches remaining, and I can’t bring myself to finish QuickReps. It’s again an internal battle between rationalization and rationality.
“I’ve come this far, I should finish this!” (Sunk cost fallacy)
“The opportunity cost is high - I could finish it, but then I’m not working on something I’d really enjoy.”
“I should build the landing page at least, publish on show HN, see what people think.” External motivation might work.
It would be a lot of fun to close the loop: finish the project and try to gain some experience on the business and marketing side of things.
I don’t even know yet whether people who use Anki would switch to something like this.
I don’t know if someone who doesn’t use spaced repetition will be able to build the habit using QuickReps.
My strategy started showing a lot more holes after my first assumption: “Build it for myself” failed. To recover, I need to get external validation, and I haven’t done that. Yet.
Accepting this was hard.
Redo
If I were to do things again, what would I change?
I’d try and test a no code version of my hypothesis. In this specific case, it seems much harder to do.
Now that I know the answer, I would like to say I’d be more careful about my hypothesis, but I think that’s the wrong lesson to take from this. “More careful” isn’t helpful. What would be helpful is a smaller test for, say, a part of the hypothesis.
“I’d use it if it were faster than Twitter”. I can test this out by making Twitter and everything else on my phone slow. (Via, for example, using blockers on these apps). The result here though is that I stop using my phone.
Miswanting
I wanted a tool for thought. The best thing I knew about was spaced repetition.
Shortly after, I got introduced to Zettelkasten, and the new kid on the block, Roam, which I’ve grown to love.
I didn’t need to remember everything I was reading to make connections I needed.
Fin
I secretly hope this post mortem generates enough interest to motivate me to finish things up. However, I don’t think that’s likely. It’s one of those “young kid saving the world” dreams. Except there’s no young kid and the world is not in danger of “space repetition”.
The unlikeliness shouldn’t stop me from doing the bare minimum, though! So, if you’d like this app to exist, let me know:
-
Ha! not any more. Nowadays waiting for the microwave to finish heating. ↩
-
I do too. I learnt Lisp separately after this project. ↩
-
I reached this design over several iterations. ↩
-
Not necessarily how it looks. I read Refactoring UI, but that was one of the last things I did for this project. I haven’t implemented it yet. This is another reason it has taken me so long to write this post mortem. ↩
-
A corollary is that if I’m not feeling that uneasiness, I’m not growing - both for personal projects and work projects. ↩
-
Not sure that’s the correct attribution. I couldn’t find the quote anywhere ↩
-
and supported dark mode, too! #scopeCreep ↩
You might also like
- How to setup duration based profiling in Sentry
- How to simulate a broken database connection for testing in Django
- The "People fuck up because they're not like me" Fallacy
- How I Own Projects as a Software Engineer