Spotlight

Do you work on your apps full-time?

I have a full-time job as an iOS SDK engineer. I'm also a security guy. I try to hack stuff.

What are you working on with Mooligan?

I've been working on Mooligan, a trading-card app, for four or five years. I was just using it myself; I hadn't really thought about putting it on the App Store.

There aren't many good trading-card apps, but they all do the same things: a scanner, binders, discovery. I felt that I could make something nicer, but could I make it more useful? If I launch it, I want something beyond the binder stuff. You already own the storage on your phone. Why am I charging you for that? The services I offer have to be more useful than what's already out there.

Recently I've been experimenting with Claude to make playtesting more competitive. Instead of a basic AI opponent, I want something you can properly test against.

How do you decide what to work on?

For me, because I have a main income, I can decide to build things that matter to me.

I only spend two or three hours on this. A lot of the teasers I share are features that took months or even years to build.

It's different if your income depends on your apps. If one or two out of fifty pay the bills, it makes sense to ship more and look for product-market fit. There are more to-do apps than people in Singapore! I'm not saying that's a bad thing. People have different tastes, and if you're good at marketing, you could make it.

My advice isn't necessarily good for indie developers. Friends tell me they can't build things they love; they have to build things other people want. If I lost my job, I might do the same.

If Mooligan did well enough to pay your bills, would that change your advice about building what you love? Or would you still say you got lucky?

If Mooligan made $10,000 a month, I would still keep my job.

I wouldn't start telling everyone to only ship what they love. But I wouldn't call it just luck, either. If you spend a lot of time on something and find people who love the same thing, you've spent that time increasing your chances of success.

Mooligan is a niche app. I think the people willing to pay are probably the competitive players. I could go to my local game store, hand out my card, and say, please download and support Mooligan. Who knows? People might like it and subscribe.

If you get no downloads on the first day, ten in the first week, and then give up after a few months, you're surrendering yourself to luck. Keep rolling out updates and sharing with the right people. If you can't find them on X, go out and meet them: hey, try this app if you have this problem.

Do you download apps for inspiration, or mostly stick to ones you use?

Most of my apps are stock Apple apps. I love Rainbow; it's one of the most beautiful apps on my phone. But I don't keep a lot of apps just for inspiration.

I'm a pretty boring guy. If I like something, I just add it to Apple Notes. Whenever someone asks me for the best note-taking app, that's my answer.

Do you think of yourself as a developer or a designer, and how does that shape your process?

I'm an app developer first, designer second.

When I start an app, I try to stay as close to the system as possible. No custom fonts or sizes: title, caption, the Apple font table. For spacing, I use the Fibonacci sequence. I don't want to think about spacing. I want everything consistent, because supporting multiple platforms becomes a headache if you come up with your own system.

The rest is a little bit of flavor. With Mooligan, I look at physical experiences I have with trading cards. When you open a deck, the box opens and the cards slide up. I want it to feel like you've brought your cards from the physical world into the digital world and kept the same experience. That doesn't mean every app has to be skeuomorphic.

On a trading app I worked on, the numbers and charts drew from old stock displays. I can't just take a pattern I see on Instagram and apply it to a stock app. I have to understand the traders' pain points first.

Come up with a skeleton before going straight into mockups. Then you can design around the functionality. I've seen beautiful charts where the information just isn't there. The fonts look nice, but can you see the four-hour, eight-hour, and daily charts? Design for functionality first. The rest can come later.

So the visual language comes from the product itself, rather than other pretty apps?

Exactly. I've seen people choose branding and fonts before understanding what the app does. That's too early. The font might not even work with the content.

I worked as a design engineer at a real estate company, and the task was to make the app like Airbnb. But our photos weren't at Airbnb's level. If you have Airbnb's layout and illustrations but bad photos, the app is still bad.

Your layout has to complement your content.

If the photos are really bad, something like Craigslist or classic Reddit might fit better.