Welcome to another installment of our Top App Dev Interview series!
Each interview in this series focuses on a successful mobile app or developer and the path they took to get where they are today. Today’s special guest is Alex Andrews.
Alex is a full-time indie iOS developer, Swift lover and motivated musician. He is well known for running his own company Ten Kettles, producing high quality apps for enthusiast musician’s alike.
When Alex is not running Ten Kettles, he creates various tools to help with his job and explores his own Scrum variation.
Most developers struggle to make the leap from paid project work to fully indie developer. Can you explain how you made this leap?
Before I jumped into Ten Kettles full-time in 2014, I worked as a research engineer in a few different labs around Toronto (lots of signal processing and data analysis work) while spending a lot of time making and performing music. I loved it and worked on some very cool projects with people I’m proud to know, but I felt like something was missing.
I’d started a company back when I was 18, and I had just loved the experience so much that I knew I’d return to it one day. I think I just needed to wait for the right time—a time when I had enough experience under my belt to know what it was I wanted to build specifically (i.e., apps!), and to have the skills to get started.
What pushed it over the edge for me was that I’d been working in what would have been my dream “real job” for two years, but it was just feeling less “right” as time went on. I couldn’t stop thinking about going out on my own and began learning iOS development in my spare time.
Not to say it wasn’t a struggle. It took some time to get off the ground (i.e., stable paycheques), and it was a pretty big financial and emotional challenge in the meantime. Living in Toronto isn’t cheap either! But I think I just really believed in Ten Kettles and what I was doing… so I just had to keep at it.
What benefits do you get working as an indie?
I think it just fits my personality. I love building things, learning from users’ feedback, iterating products, making big plans and chipping away at them week-by-week… there’s actually a lot in common with writing music and playing in a band.
And though it’s mostly solo work with Ten Kettles, doing the occasional consulting project or collaboration (e.g., working with our designer) has been fantastic for pushing me outside of my comfort zone and has taught me loads.
All your products at Ten Kettles revolve around music. For example, your latest product Waay helps musicians songwriting. How did that focus on music-related apps come about?
When I started Ten Kettles, I didn’t know what type of apps the company was going to build beyond the first one or two. My background at the time involved lots of signal processing/data analysis, audio/music apps, and teaching. So, I just kept picking the ideas that most inspired me, and over the first year or two that ended up being music education, which actually pulls in all that stuff.
I used to teach quite a bit of guitar and music theory, and a big part of my approach was putting together custom courses for my students based on their interests (e.g., songwriting, learning cover songs, or developing solo technique). It turned out to be pretty effective, and an app seemed a perfect way to bring that approach to anyone with an iPad or iPhone. hearEQ was similar: I was helping to train my band’s soundperson and wanted a tool that could let her practise ear-training on any track she wanted.
So, app ideas tend to pop out of personal experiences like that for the most part, and I’ll add the potentially good ones into a master text file. There are a lot of terrible ideas on that list too, but I think that’s OK. Quantity over quality when it comes to brainstorming, maybe?
A lot of indie developers have more ideas for apps than they have time to build. How do you choose which of your many ideas to build to completion?
Picking ideas from that list to actually build, and have them be successful, is tricky. I’m still getting the hang of it. But there are definitely a few solid points I’d recommend to people when deciding on an app to start building:
- Pick something you can get—and stay—excited about, even on the dull or frustrating days. The apps I’ve been most happy building were ones that I couldn’t stop thinking about until I got started.
- Pick an idea you can feel a little more qualified to work on than most other people. It helps to bring a unique perspective, skill set, or approach to an app idea—especially if the market’s a bit crowded.
- Don’t think (just) like a programmer, think like a product maker. Will people actually want to use the thing you’re making? Will they be excited about it? Can you name a few people who will definitely use it? This is where some market research can probably help.
- Think of an app like an ongoing conversation. Creating an app and then shipping it is kind of like thinking of an idea and then telling it to a friend. You’re starting a conversation. Listening to a friend’s feedback on your idea—or your users’ feedback on your app—is maybe the best way to make it better. So, the fourth point is to get your app into other people’s hands for feedback ASAP, even if it’s a little rough around the edges at first. And then listen! It’ll make your app waay better. (I learned this one the hard way.)
Alex, what does a typical day look like?
I tweak this every once in a while, but here’s a normal day:
- 5:15–8:15AM: Meditate, walk dogs, exercise or practise music (alternate), tech learning (programming katas, side projects, reading), family breakfast.
- 8:15–12:00: Work, taking short breaks every hour.
- 12:00-1:00 Lunch
- 1:00-6:00PM: Work, taking short breaks every hour.
Ideally, I’d aim for about 7 hours of sleep with about half an hour of reading and a little day-planning first. So, for most weeknights, that’s about 10:15 PM by the time we actually turn the light off.
That schedule is for a normal Monday–Friday, though on Friday I’ll usually sleep in an hour which opens up Thursday evening a little more. :]
When it comes to non-work hours, they are pretty much strictly non-work. I might play around with a framework, work through a raywenderlich.com tutorial, do a side-project, or read some tech books (just finished up Working Effectively With Legacy Code), but nothing that is too immersive or stressful. Work’s for the workday.
I split the workday into one hour chunks that include a short break, kind of like a long Pomodoro. I’ve been doing this for maybe a decade and despite trying a few variants over the years, this split works great for me. The work part (45–50 minutes) is all work: no texting, tweeting, email (unless it’s a specific work task), or anything like that. Just work. And then the break (10–15 minutes) is the opposite. No rules. Maybe I’ll hop onto Twitter, have a snack, go for a short walk, wrestle with my dogs, whatever.
Needless to say, I use my stopwatch and iPhone timer quite a lot (though inexplicably, Siri still only understands “Set a timer for 45 minutes” about half the time…) Besides keeping me focussed, this approach has been great for doing those occasional tasks I really cannot get excited about (taxes!)… because I’m only ever 45 minutes away from a break. :]
So many developers are talking about the “indiepocalypse” as there are very little indie devs out there now. What’s your take on this?
I don’t know… when playing in bands, I’d hear other musicians say lots of stuff like “there’s nowhere good to play,” “there’s just no scene here,” or “it’s so hard for musicians.” That kind of thing. And I was always that annoying guy who’d be wondering “Well, what about venue X? What have you done for promo? Why are you booking shows on Monday at 1 a.m.? Who are you booking with?”
So, yeah, there are challenges to being indie anything but I find focusing on that stuff too much can be unhealthy. There’s often a workaround if you look for it. Or maybe there’s not, and I should be paying more attention!
I mean, my business model involves doing consulting work a few months a year and maybe market forces will make that a month or two longer one year. But, to be honest, I’m still blown away that we have these tools and ecosystem that allow us to come up with an idea, put it together with these free/cheap tools, and then upload it to a store and have users emailing us with their experiences within a week or two. Plus the fantastic iOS dev community.
It’s all amazing, and I feel lucky to be making it work now, regardless of what’s to come. Who knows if I’ll be an indie dev in 10 years time, but I know that it’s pretty awesome for now.
What advice would you give to developers wanting to be an indie developer?
If you want to be an indie dev that makes your own products, I’d start by asking yourself if you want to start a business. Because at least in my experience, that’s really what you’re doing. That means marketing, design, assessing products, killing products sometimes, some days without any coding.
Did I mention lawyers and accountants? Because if your preference is a stable income and mostly coding, plus having a team to fall back on (and support), I think a standard coding job is probably a better fit!
Being an indie product developer is hard. There’s lots of pressure, you bear sole responsibility for every mistake. Plus, at least in my experience, it can take a while to get profitable.
But the flipside is pretty fantastic: you get to dream up ideas, make them into reality, share them with the world, and earn at least a good chunk of your living that way. You’re always learning new things and putting them to use. And not little things either, big stuff: new programming languages, how to market products, new design approaches, better communication skills, video editing, color theory, Canadian tax code (OK, maybe not always that exciting…).
There’s a middle ground too: if you want coding and independence, there’s always the freelancer route. It can be a much smarter earning opportunity, and you get many of the same perks.
I found the articles on raywenderlich.com on this really helpful when I started integrating some consulting into Ten Kettles (I do about 75% of my own product work and 25% client work). Asking advice from people in your community is always a great call too: before Instagram scooped up Toronto’s (and raywenderlich.com’s) Greg Heo, I took him out for a beer to pick his brain on client work, and I definitely learned a lot.
Tell me about Ten Kettles. Where did the name come from?
I’d started a band the year before and we needed a name. I came up with the idea “Ten Kettles” but it didn’t make it past the chopping block. The name stuck with me though and I thought it worked even better for a company name.
The kettle imagery itself came from a few sources. My background is British (first one born in Canada), so obviously there’s the tea element. But also the land that Toronto sits on was “purchased” (I use that term very loosely) from the Mississaugas of the New Credit a couple hundred years ago. The deal involved a couple dozen brass kettles, which stuck with me for some reason.
So, I think between the family and city history, I just liked the linkage to something bigger. It’s kind of a reminder to myself to stay aware of that bigger responsibility too. I guess the name reminds me to always try to do the right thing.
Do you have any working partnerships?
I work with a fantastic designer on most of my icons, website design, and the design of our upcoming app for drummers, BeatMirror. His name is Joel Derksen and he’s great! The icon he made for Ten Kettles actually just won a big logo design competition, so we’re super pleased.
I’d really like to build a relationship with a great Android developer, but haven’t quite decided about the Android route yet. I also talk through company decisions big and small with my wife Alicia; being able to bounce ideas around with someone so smart and thoughtful is definitely a huge asset. Very lucky!
How do you prioritize the work at Ten Kettles? For example, when do you work on hearEQ and Waay and then move on to a different product?
I like working linearly—one thing at a time—and in relatively small chunks (usually two weeks for a deliverable). In terms of which task I choose to work on, I look at a bunch of factors:
- Am I confident users will want it? Maybe I need to gather more info first (e.g., customer surveys)
- Is it urgent? (e.g., stripping out Parse before it disappeared)
- Will it make money? (e.g., I’d genuinely love to spend two weeks tweaking animations or improving test coverage, but that might not be the most profitable use of my time)
- Will it actually take two weeks? Or should I break it up into smaller parts…
- Is it newsworthy? If an update can get some good press, that’s a huge deal!
- Am I excited about it? This isn’t always that important (my dev-self doesn’t always love my CEO-self’s decisions), but it helps to break a tie.
So, I order (and endlessly reorder) potential projects based on these things, and then every two weeks I pick what’s on the top of the list to do. I generally avoid changing course until two weeks later, then it’s onto the next thing.
What tools do you use to help with the planning of product work?
At first, I was going to give a list of software tools, but to be honest I think the biggest tool is a regular biweekly schedule. Every two weeks I take a day or half-day to work through potential project ideas—like adding a feature to hearEQ or building out a new app—prioritize them like I’d mentioned before, and then plan the next leg of work.
I think taking a day away from code to do this stuff is probably the most powerful thing, and helps me to take off my dev hat for a day. But, in terms of physical or software tools, I’d say Sublime Text, Pages, OneNote, and lots and lots of post-it notes!
At Ten Kettles, you must have to deal with the admin work, planning, development, design, testing etc.. how do you manage the wearing of multiple hats?
Last year I freelanced on two projects with a fantastic studio in Toronto called Secret Location. I was working on virtual reality apps there, including rebuilding the New York Times’ VR app from scratch in Swift (I loved working with their designs! Beautiful fonts.).
But unexpectedly, I think my biggest takeaway wasn’t technical but was a new project management technique. They used Scrum, which I hadn’t really used much as a solo developer beforehand. I got really into it and read a bunch of Scrum books while I was there to learn as much as I could.
But Scrum’s really meant for 5–9 person teams, and in my product work, I’m usually just the 1. I kept thinking how I could adapt this to my work, so as soon as the project was done, I flew off to Montreal (one of my favorite cities) for a few days to shut myself off from the world and try to come up with a 1-person variant. A few days later, it started to come together and I’ve been working with my “ScrumOfOne” variant ever since.
Though I’ve been quite happy with how “ScrumOfOne” is turning out, the most important element is really the core Scrum philosophy, more so than any tweaks I’ve made to the day-to-day methods. For anyone interested in learning more about that, the book I started with and would definitely recommend is “Scrum“. There are many books out there, but I did find this one laid out the philosophy and key methods in a pretty motivating way.
So, to (eventually!) answer the question, I use scrum techniques to keep organized. That means a super-quick turnaround from idea to development to getting it out to users. I try to get everything out of the way of this goal. Admin stuff usually gets done in my first hour of the day, before I jump into code. I usually work directly with a designer, so I don’t do too much design myself anymore. And then I pull the planning out to a full or half day every second Friday. That leaves me lots of time to build products uninterrupted.
Love for tech
What do you think the future is for Swift?
I really enjoy using Swift, and compared to the other languages I’ve worked with it’s definitely my personal favorite. Especially seeing the broader Swift community in action over the past couple years, there’s no doubt there’s real momentum—and every new Swift release is better and better.
Also, listening to Chris Lattner discuss Swift’s place at Apple on a recent Accidental Tech podcast, it definitely doesn’t sound like the language is going anywhere but forward. So, I think it’ll just keep getting more refined and more popular—and that popularity is pretty well deserved.
I can see you love to play around with new technologies like building tools with Python, how do you find the time to keep learning new things alongside working on projects?
For the most part, I don’t do “work work” in the evenings or weekends, but I find that sometimes I really want to code something up in my spare time. That tension seems to create a good environment for side projects, as they feel like hobbies then and don’t burn me out too much.
I have a couple friends who are really into building their own tools too, and I find that pretty motivating. For example, a friend of mine is slowly moving his entire life into Terminal and he’ll share all his vim adventures, Terminal-based email clients and whatnot with me, and that’s really interesting and it motivates me to double-down on my own little projects (e.g., custom Sublime markdown syntax, binding framework, etc.). So, a big +1 for the community.
Also, reading this article last year got me keen to read a whole lot more books, and that’s been really rewarding. I find that the more I read, the more I want to. Thanks, Adrian Kosmaczewski, for the motivation!
Making your own tools, can you share a good example when you made a great tool and what benefits it gave you?
Yes, I’d love to! A recent one is a little Terminal app called “Workflows.”
Every time I do one of those “once in a while” tasks, say localizing an app, troubleshooting a git push error, or simulating a coordinate tap in UI Testing, I write up a quick text file describing how I did it. Maybe it’s just me, but I forget some of this stuff literally seconds after I do it… so, being able to load up these text files when needed saves me a lot of time.
Needless to say, I have one folder on my computer with many, many of these text files and finding the right one was becoming a bit of a hassle. So last summer I was looking to practise some Python and TDD, and I put together “Workflows” to search through these workflow documents and print any matches directly to the console. So, I type something like “wf -w git push error” then the matching doc pops up. It’s super simple but very handy.
Where To Go From Here?
And that concludes our Top App Dev Interview with Alex Andrews. Huge thanks to Alex for sharing his indie life, his love for Swift and finally running a successful company Ten Kettles.
We hope you enjoyed this inspiring interview and if you’re thinking of starting your own company or eager to make the leap to become freelance to take Alex’s advice to heart.
If you are an app developer with a hit app or game in the top 100 in the App store, we’d love to hear from you. Please drop us a line anytime. If you have a request for any particular developer you’d like to hear from, please post your suggestion below!