As a solo developer, I decided to offer phone support, and this is what happened

This year, around February, I started offering telephone support for Taxnote, which I hadn’t done up until then, because the idea made me anxious.

I intended to quit if, at any time, I thought it was tough for me to do; but, so far, I have continued with it for over half a year, so I’ll update you on the things I’ve learned from doing it.

I wrote my phone number in the help section of the Japanese version only, since I live in Japan and it is a JP number. I might try it in English too in the future, if I can make it work with an international calling facility like Skype.

How often do I get calls?

For the time being, my telephone number is written on the help section of the Taxnote accounting application, and the recently released text-to-speech application named Voicepaper.

For example, when it comes to Taxnote, when you tap on the “Help” section on the settings screen, it shows “Inquiry by phone call” right at the top; in other words, it’s made so that people who go to the help section realize straight away that they can contact us by phone.

By the way, the application doesn’t have a high number of downloads, so it’s a question of whether I’ll receive even 1 phone call per day. Once in a while, I get 2 phone calls in one day, but even that isn’t a large amount, so it’s on a level at which I don’t feel the burden very much. If they were to call me all the time, perhaps it would be more intense.

Still, when you’ve been doing it for over half a year, all sorts of people call you, and I’ve really learned a lot by talking with users directly on the phone.

Most users are polite

This may be a virtue of the Japanese, but, basically, everyone who calls is civil and polite. It often goes something like: “I’m terribly sorry to bother you, but there’s something I would like to ask…” and I respond with something like “No, of course, of course…”.

I think it’s probably like this because the application I work with is operated by a solo-developer, just me, and the approach is emotionally different from calling the support service of a large company. The people who call are probably being attentive.

However, there is the disadvantage of people thinking along the lines of: “Is everything okay with this app? It looks like its development is going to be abandoned, so I’m anxious about continuing to use it,” as when compared to a company. I don’t really know which is better when it comes to things like this.

I got sidetracked.

Ah, yes, everyone is really kind, and older men and women in particular, who are unfamiliar with IT in general, let alone Taxnote, express their gratitude immensely. I thought that something like being thanked for providing a support service was just to motivate the lonely app developer when I looked at the reviews, but when someone directly says this to me on the phone, I get ten times happier.

One time, an older lady passionately said, “I am a physical therapist, and compiling tax returns has been quite difficult up until now, but, thanks to this app, it has become much, much easier. I think it’s a superb app. Thank you so much.” Honestly, I teared up. I really cried.

You can detect critical parts of your product

Of course, there are times when a large problem occurs and I have to respond to angry phone calls. At those moments I earnestly apologize, but, when you have experiences like that, it really increases your determination to fix the problem.

As a matter of fact, when it comes to large problems, offering phone support enables you to understand that inconveniences that occur when the app’s behaviors and messages are hard to understand are more frequent than bugs in the programming (when bugs crash the application, it’s easy to identify them through the log, and no reports are made with a phone call).

At those times, what might have been: “Well, this bit right here, it might be hard to understand,” changes its priority to: “Nope, we really need to provide a clearer explanation with the message, and improve it so that something isn’t misunderstood and handled wrongly…”.

In my last post, I wrote about how it’s easier to understand the problem or debug when you’re doing telephone support as opposed to messaging, since you can hear the circumstances from the client in more detail, but it’s also largely through emotions that the acuteness of the problem is expressed.

For example, when you always have an endless list of things to do, like improve the app or fix bugs, it’s always important to prioritize what to start working on first. At such moments, the numbers you see from the app data (like, for example, numbers from a crash) serve as a reference, but so do inquiries from support messages.

You make a decision by taking into consideration both the quantitative criteria, which you know from the numbers, and the qualitative criteria, which you know from the conversations. But, when you add telephone support, the qualitative criteria system rises up. As you might expect, purposely making a phone call takes some energy, and talking to a user helps you understand the critical points, such as, “This worries me,” or, “I don’t understand this.”

You can improve your listening skills

Listening to opinion of the users is something really hard to do skillfully, unless you’re a UX professional.

First, you have carefully listen to what the user is telling you, and then you have to pick the right wording to respond with, all while analyzing in your head during the conversation to what degree the user is versed in IT or app operation.

When you explain something at your own pace to a person not really acquainted with IT, you get questions like:

“What is iOS?” or, “What is iTunes?”

The user thinks you’re a computer fanatic wielding unintelligible terminology, so it’s not unlikely they, stressed out, might say,

“Ah, I see… I understand…” (even though I didn’t understand that much…)

and end the phone call.

By the way, regarding the phrasing I use, I usually first ask them,

“I would like to begin explaining while operating the application; can you talk over the phone with the application open as well?”

If I explain the iPhone speaker function, it makes it easier for the user, as we can chat while going through the application together.

However, when doing telephone support, it’s mostly people who aren’t really familiar with IT, so, despite conscientiously trying to work through their particular problem, there are times when I fail.

“Oh, no, it’s fine if you don’t talk about it in such detail; can you just give me a rough explanation?”

To which I might respond with,

“Ah, I apologize… Well, you see…”

which is how I would do it in haste.

So, you first have to grasp how familiar the user is with IT and applications, and how much of it they want to have explained to them. However, since it’s impolite to ask how much a user knows about using applications, then excluding the times when they tell you voluntarily, the only option is to make an assumption.

And, I tend to do it unconsciously, so I forget about it if I don’t pay attention constantly, but I can fall into the trap of talking on and on without end.

For example, once, when a conversation like:

“I don’t understand this part here…”

began, I arbitrarily decided in my head,

“Ah, right, this is a pattern I often see,”

and I, all of a sudden, continued with:

“First, this is like this, and, after that, you click this, and do this, so it becomes like that. And, when you do this, that becomes like this, etc., etc.,”

while not understanding the user’s circumstances very much.

So by the time I ended my chatter, I realized that they were in search of something else, and that is how I made a “now I’ve done it” blunder.

For that reason, you have to be careful not to talk too much right at the beginning of the conversation, or it can become pretty difficult.

If there’s a case where, even once I’ve asked, I still don’t understand what is troubling the user or what question they really want to ask, I try to check it one more time:

“You want to do this like this and this, but you don’t understand that part well. Is my understanding correct?”

If you do it like that, you can change your viewpoint and explain it more carefully and in more detail in case the user can’t convey their issue well, so I use this strategy a lot. This is something I learned when doing support by chat messaging, but I think that it’s effective when doing telephone support as well.

Well, when it comes to telephone support, unlike support by messaging, where you can reply whenever it’s convenient for you, the burden of being called unexpectedly is the biggest one. Therefore, I can’t recommend it wholeheartedly, but I would like this to be a reference for people who may be interested.

I think the biggest benefit is of an emotional kind.

App development is something that you inevitably do while clattering away on your keyboard in front of the computer screen every day, and something which you can’t see the results of in any other way but numbers. So, when you get in touch with a user directly, it can make you feel something like: “Ah, I may be doing something for the world. It’s good to live.”

*I make an Text to Speech app, one-tap timer and more. About Me.

A Better Text to Speech App for Pocket & Evernote Users

Pocket for iOS has own text to speech function, but it’s not useful enough because of the following reasons.

Pocket App Problem

1.You can’t make Playlist to keep listening.
2.You can’t play from selected words easily.
3.It doesn’t have Sleep Timer and Repeats functions.

Overall, you cannot use it like Podcast apps since it was not built for listening to contents from the start.

So I made a simple and easy to use app, Voicepaper 2 for people who want to listen to contents while commuting or exercising.

Voicepaper 2 offers

1.Make Playlist and reorder it easily.
2.Play contents in the background with remote control.
3.Play from selected words and Highlight speaking texts.
4.Sleep Timer and Repeat text functions.
5.Downloads contents from Pocket, Evernote and Dropbox.
6.Supports over 25 languages and switch them automatically.

Make Playlist and Reorder it easily

You can reorder your contents while playing and listen to them in the background. You can also control it with iOS remote headphones.

Play from Selected Words

Double tap words to play from a place you choose. You can change speaking rate easily and use Sleep Timer and Repeat Text functions.

Listen to Contents via Pocket

Use Pull to Refresh to refresh Pocket contents and listen to them on the go. You can also archive or delete articles on Pocket with swiping left.

Listen to Contents via Evernote

You can also fetch Evernote notes or web clips. Evernote web clipper is useful since it can fetch articles which Pocket cannot read.

Listen to Texts via Dropbox

If you want to listen to text files, use Dropbox to import it into Voicepaper.

Any Feedback is Welcome

Download Voicepaper 2 for iPhone・iPad

I would like to hear your feedback to make it better. You can contact me in the help chat of the app, @umekun123, or umekun123(@)

You can upvote it on ProductHunt if you like it.

PS: I made a text to speech app called Lisgo a few years ago, and a lot of Pocket users liked it, so I thought it is time to make a new one from a scratch.

*Related Links
Consuming content like a boss
Nir Eyal | Hooked on Technology (Episode 431)

*I make an Text to Speech app, one-tap timer and more. About Me.

The Top 10 Most Useful Tools for iPhone/iPad Business & Development

I’ve been developing iPhone/iPad apps for over 5 years as an indie iOS developer who makes a living from them.

Nowadays, there are many useful tools for app development and business which didn’t exist before and I strongly recommend using them to boost your productivity.

These are the Top 10 tools that I am still using after trying a lot of alternatives. These tools are mainly for general app business such as analytics, managing apps, and user support, so I believe they are also useful for people who don’t code.

I use them for iOS apps, but most of them can be used for Android apps too.

10. Iconfinder (Free + Paid)

Handling visual design in mobile apps is relatively easy compared to using web services, since the screen size is smaller and you can use many default preset icons.

When I want to use custom icons for my apps, I look for suitable ones from icon collections like first. If I can’t find what I want from the collection, I use Iconfinder.

For example, when you want to find a flat designed reload icon, you can search for “reload thing” on the site.

9. Token (Paid)

Token is a Mac app which makes distributing promo codes very easy.

Once your app has been approved in the AppStore, you can give promo codes to users so that they can use your apps for free or try the latest versions of your apps before you release them.

Recently, Apple has even allowed the distribution of promo codes for in-app purchases and subscriptions.

Even though users usually need to copy and paste promo codes on the AppStore, with Token you can send one easy link so that all they have to do is to just tap the link to paste promo codes on the AppStore.

You can even distribute a bulk of promo codes to random people. The only limitation is that you cannot use Token with two-factor authentication.

I mainly use promo codes to test my apps on the AppStore before I release new versions of my apps. You can test the released version of your apps on the AppStore against the sandbox version before you hit the release button.

8. Gengo (Paid)

This service is not made for mobile app development, but I constantly use Gengo to localize my apps into different languages. This service is very easy to use and the translation speed is usually very quick.

I tried a few localization services made for mobile app development before I settled on Gengo, but I found that Gengo is the simplest and easiest one to use.

When you use it, you need to use [[[ ]]] to explain each sentence to make it easy for translators to understand. I also believe that it’s possible to pick translators who understand tech when you choose App/Web localization in the purpose section.

7. AppBot (Free + Paid)

AppBot delivers the latest user reviews on the AppStore to your mailbox. AppBot also has several other features, but I only use the user review delivery function for free.

What I like about AppBot is that it delivers reviews from different countries to you, so you can be aware of users outside of your home country.

As a solo indie developer, updating apps alone every day is quite a lonely work so reading encouraging reviews from users really motivates me to keep going.

6. Screenshot Builder (Free + Paid)

This is a very handy service when you want to create or update app screenshots. You can update each description, font type, font size, and background color easily, and it will create iPhone/iPad screenshots into different resolutions.

Without using this tool I couldn’t consider localizing Taxnote into 7 languages. The only thing is that you can’t reorder each screenshot after you create it.

5. Fastlane (Free)

Fastlane is an awesome terminal base tool set for every iOS developer. There are several cool tools in Fastlane, but I mainly use Deliver.

With Deliver, you can upload screenshots, keywords, release notes, app names and so on using a terminal.

When you support iPhone and iPad and even localize your apps, manually updating their data on iTunes is a nightmare, but Deliver truly saves you time in this regard.

4. Mixpanel (Free + Paid)

I’ve tried a lot of analytics tools for iOS, but Mixpanel is the best one for doing different kinds of custom analytics like funnel analysis with iOS versions, countries, and app versions.

It’s not an entirely free service so if you try to track the large volume of data in popular apps, you will easily exceed the free limit. Therefore, I use Mixpanel when I want to analyze specific segments.

I am also using Answer of Fabric for viewing broader numbers, but Mixpanel comes first when I want to do custom analysis.

Speaking of subscription data, including free trial and cancellation numbers, you can use the Analytics tool from Apple iTunes Connect. Each analytics tool has own strengths so it’s good to use several tools at the same time for different metrics.

3. AppAnnie (Free)

AppAnnie is a very popular service that enables you to see downloads and sales data on the AppStore and GooglePlay.

It’s much easier to see downloads and sales based on app versions, countries, and date using AppAnnie than it is with Apple iTunes Connect.

AppAnnie also features its App Store Optimization (ASO) tool which helps you find better keywords or titles for your app on the AppStore, and I believe this is the de facto standard tool for doing ASO nowadays.

2. Fabric(Crashlytics・Answer) (Free)

For mobile developers, Fabric is a useful analytic tool provided by Twitter.

The great thing about Fabric is nothing but design. It’s elegant and easy to see data in different formats: I’ve never seen an analytic dashboard as great looking as Fabric yet.

With Crashlytics, you can track crash data from your apps so you can easily track how your apps crash based on detailed stack trace, app versions, iOS versions, and so on.

With Answer, you can track app downloads, active users, retention, and more. The retention dashboard of Answer is especially useful compared to other analytic tools.

The only down side, and it’s a big one, is that Answer only shows the recent month’s data in the dashboard.

1. Helpshift (Free + Paid)

With Helpshift, you can implement a support box which helps you communicate with users. If you want to update your apps based on user feedback, this is an essential tool for you.

By using Helpshift SDK, your users can send questions or requests inside your apps easily, and you can reply to them directly via chat box.

You can also implement FAQ inside your apps and manage the service on the server using Helpshift SDK. It’s very efficient since you can even easily localize the FAQ.

I believe I couldn’t get enough feedback from users without Helpshift, since contacting developers via email is a pain for anyone and you end up missing important feedback because of that.

Hearing user feedback is crucial for me when I am updating my own apps, so using Helpshift is really useful.

The Easy Way To Improve User Interface Designs
How do you say No to users without annoying them?

*I make an Text to Speech app, one-tap timer and more. About Me.

The Easy Way To Improve User Interface Designs

There is one easy and secure way to make good user interfaces for mobile apps.

That easy way is simply to listen to users’ questions. More specifically, design your mobile apps so that users can ask you questions very easily, then update your interfaces little by little based on that feedback.

It doesn’t mean you add new features, but that you make everything intuitive every time you find that some users find certain interfaces difficult to understand.

However, most developers do the opposite because they don’t want to spend time on user support; we still tend to set a user support button in somewhere hard to find.

Even though I understand the cost of answering every question as an indie developer, I’ve realized that answering users’ questions is the most cost effective and easy way to improve user interfaces.

Again, I am not talking about cool and sexy UI here, just intuitive and easy to understand UI for users of your apps, not users of other apps.

Before you release your apps

If you haven’t released your app yet, you can’t get real feedback from users. Polishing designs at this stage is so difficult because everything depends on your experiences.

Basically, you need to focus on one thing instead of building something which can do many things, and try not to add too many buttons and features at first.

This is easier said than done because everyone’s situation is unique, and a lot of trade-offs will come up anyway.

The most important thing here is to figure out the priorities for your apps.

How do you find target users?

You can’t easily identify target users of your app without releasing it, since each app has different users.

For example, when your app has a refresh button which reloads data, you might think about setting a “Pull to Refresh” feature which operates in the same way as the Twitter app.

If you make “Pull to Refresh” available, you could remove the reload button and save the space to make your app look simpler.

However, when the majority of your users are not tech savvies, it might be better to keep the button. The difficult thing is that you will never know the priorities which help your UI decisions before you release your apps.

Without releasing apps and answering questions from users, you can only guess the demographic of people who will use your apps and you could easily guess wrong.

Therefore, don’t believe that you can make a perfect user interface which suits your target users before you release apps. Just release apps fast and get real data about your users to polish UI to make everything easier.

Decide your priority based on users’ questions

Let’s say you’ve released your app now.

I guess you worried about each design, with questions like: “Do I need to add more descriptions on that message?” or “Will users find that feature?” But, you released your app fast before making everything perfect anyway.

Before releasing it, prioritizing which design features you should improve is always difficult. But, once you start getting real questions from users, it gets easy all of a sudden.

You simply start improving each interface, message, and button based on the most popular questions from users. This gives you a very easy and clear indication of how you can use your time.

After making improvements to your interfaces, if you don’t receive the same questions from users any more, it can be a good sign that they understand each element now.

Find something you couldn’t imagine before

So far I have written about how you prioritize tasks for improving user interfaces. But, the very crucial part of improving designs is to find something you couldn’t imagine before.

This comes from outside of your imagination, so you can do nothing in advance. You will find it out only after someone mentions it to you.

This is like one of those “Aha, I couldn’t imagine that people would misunderstand this message that way!” moments.

Actually, over 90% of user questions could be something you already know that you should improve, but you simply don’t have time for yet.

However, people occasionally give you insights you couldn’t forecast alone through feedback, and this moment is very important.

This kind of feedback makes you see your apps from a different angle, and sometimes you can fix them in very simple ways because you didn’t think about them in that way before.

If you already know the issue and haven’t fixed it yet, that means it will take time to do, and you’ve decided to do it later. For example, you can make some UI more intuitive using animations, but that implementation usually can be done later.

But, if you didn’t even realize the issue, it could be something you can fix right away like just changing messages.

Detect features users don’t realize

When users request features that your app already has, that means users haven’t realized they are there.

The fact that users don’t notice certain features means that the feature doesn’t exist for them even if you took a lot of time to develop it.

Sometimes it can be ok if your app has tons of features, but if you make relatively simple apps, this is a problem.

The good news is that you can detect this problem easily via the number of questions from users. If users often request features which are already implemented, you should improve certain aspects of the UI to make them detectable.

From my experience, I found that a lot of users don’t know even basic features of iOS apps like “Edit” or “Reorder” in TableView, so it’s better to suggest how to use them.

Real insights for what to do next

You probably have a lot of ideas about new cool features for your app.

You also believe you know what the most important feature is that you need to develop next, but how can you tell how accurate your knowledge is?

Again, you can easily check that accuracy from user feedback. If your users frequently request a feature you are now developing, that means your instinct was right, and you have a solid confirmation of it.

If your users often request other features which you thought were not so important, it might be time to change your plan.

Let’s say you had an idea about a feature that would be nice to have, but nobody requested it. It could be something great that users couldn’t imagine, but at least you can tell it is not urgent for now.

When users request something, you can even ask them a question like: “I am thinking about implementing a feature like this – what do you think?”

You will be unlikely to have an opportunity like this before you release your app, since it could take a lot of time to find a user who likes it and wants the same features as you.

How can you do this?

If you are a startup founder who is willing to do anything for your company, you can even write your phone number on the support page.

I am personally using Helpshift to set up a feedback box inside my apps and answer questions 1 or 2 times a day.

Even though it doesn’t take too much of my time for my small apps, the reward is huge and I can’t think of a better way to improve the design of my apps so efficiently.

*I make an Text to Speech app, one-tap timer and more. About Me.

We use tech-terms without notice in our apps

I believe the most important thing in mobile UI design is text messages used for buttons and messages.

Regarding that kind of design, you don’t want to use artistic expressions like in novels; it is better to use simple, specific, short, and easy to understand phrases.

This is easier said than done, because you always have bias in your mind about what phrases are understandable for most users, and it’s difficult to remove this bias.

Can you use icons?

First of all, you think about using icons for buttons instead of text. If you use icons, you don’t need to localize them for different languages.

However, you have to know which icons are most popular for different usages, and if users can’t tell what some icons mean, then they need to tap them first to find out.

The difficult thing is that even if you believe some icons are often used in iOS default apps and their meaning is obvious to most people, you could easily be wrong.

You are an iOS developer or designer who knows a lot about iPhone apps already, but for someone who came to iPhone recently, a lot of icons could be new things.

After I realized this, I started to use text messages for buttons as much as possible.

Short but understandable messages

When you make messages on alerts or dialogs, nobody reads them if they are too long. Users just glance them and skip them quickly without understanding them.

Having said that, if you make them too short, you end up making vague messages which are not clear. This balance is very difficult to achieve so I constantly update each pop-up and dialog message based on user feedback.

If you get questions from users about each dialog, that means they didn’t understand very well.

For example, messages about in-app purchases are very important in app design, since people get very anxious right before they decide to pay.

You need to explain how it works and write answers to questions people might have before they spend money.

Let me show the history of each message about in-app purchases for my app ListTimer, an iPhone/iPad universal app.

Example 1:
Thanks for considering the upgrade! If you purchase it, paid feature will be unlocked!

In this case, you don’t need to write the first phrase, and ‘unlock’ is too vague.

Example 2:
The upgrade version will remove ads!

This is shorter than example 1, but I got a lot of questions in this case.

The most popular question was whether it was monthly payment or one-time purchase.

Even if the upgrade looks like a one-time purchase and you know that iPhone always shows a different dialog if it is a monthly payment type, people always get worried about it before they pay.

The second most popular question was whether they needed to pay again when they changed iPhone devices. With iPhone, you can restore your purchase as long as it is one-time purchase type, but many users don’t know that.

So, I changed it to this:

Example 3:
The upgrade version will remove ads! This is a one-time purchase, and you can restore it for free when you change iPhone devices.

However, people sometimes didn’t know the meaning of ‘restore’, and they asked me if they needed to upgrade again when they used the iPad version.

Since ListTimer is a universal app, you don’t need to pay again for the iPad version when you have already paid for the iPhone version, so, I made it clear:

Example 4:
The upgrade version will remove ads! If you upgrade it in iPhone version, you can upgrade it for free in iPad version. This is a one-time purchase, and you can upgrade for free when you change iPhone devices.

This is a quite long message, but since this was a message about payment I thought it was worth doing.

Use easy words for non-tech people

Using easy and simple words is also important.

I believed that I should use the standard words used in iPhone itself, but I realized a lot of people don’t understand them.

For example, we developers know the meanings of words like flick, storage, and restore, but some people don’t understand what they mean.

One day, I got a message from a user asking “what is iOS?” This moment was quite a shock for me since I believed everybody could understand that term.

Now, I always try to use easy words and explain things in very specific ways when I talk to users.

When users send messages to us, and we reply with tech-terms that they don’t understand, I bet they would hate to ask us for the meaning of them again.

Some people might google it, but we know human beings are usually lazy, so they could give up and just leave.

I often forget this, but we should keep it mind and try to remember.

So, how do you do that? Well, I cannot think of any easy way, so let’s remind ourselves again and again and double-check our words in support messages and in-app messages.

Eventually, you will reduce a lot of easy questions from support and save your time in the end. That is what happened to me.

*I make an Text to Speech app, one-tap timer and more. About Me.

How to learn programming without getting stuck

I’m an indie iOS developer who sells an accounting app called Taxnote. Users of this app have been requesting the cloud sync feature for a long time.

So, I started using Parse, which until last year was the best tool for mobile developers who didn’t want to handle server side programming.

Unfortunately, Marc Zuckerberg decided to kill the service and I didn’t have a choice other than to dump my codes, which I spent 5 months doing at the beginning of 2016.

At that point, I finally decided to learn Ruby on Rails to write server side in order to make the cloud sync feature for Taxnote.

I am lazy, which meant I really wanted to learn it very efficiently. This led me to try a new way, which worked very well, so that’s what I’m going to write about.

It’s not pair programming precisely, but it is something like that.

The hardest part of learning new programming

I believe the most difficult part of learning new programming is not the very first step.

It is just after you have finished doing tutorials or learning the basics. You can find tons of good tutorial videos about programming languages or frameworks that you want to learn these days, so it’s easy to do the first step by yourself.

However, once you want to go on to the next step – for example, you want to build something out of your idea – you easily get lost. When you actually start coding, you will come up against a lot of unknowns, and in most cases you cannot find answers from tutorials.

I think this is the biggest barrier for learners since you can’t even guess how to google it when you don’t know what to do next.

In my case, I started doing several Ruby on Rails tutorials and learned the basics first. Then, since I wanted to build background api for Taxnote, I needed to know the latest practices for making api URL, how to make database structures, which gems I should choose, which server I should pick, and so on.

Google works very well when you are researching something specific in relation to your programming problem and you are already experienced with that domain, but it doesn’t work when you want to hear advice or suggestions from experts.

There were too many questions I wanted to ask people who know what to do, and I knew I would make bad decisions during development if I kept working solely with Google searches.

Find a mentor from Upwork

At the time, I thought I could use Codementor to ask experts about what to do next. But I realized it is a bit expensive to find a long-term mentor there.

If you ask for help from good programmers on Codementor, it costs 20-30USD per 15min, since the service was made for solving your questions right away.

Then I decided to use Upwork to find a Ruby on Rails mentor. What I tried my best to do there was to write the description for my needs in as much detail as I could, since the teaching programming is very broadly based on each student’s level and what they want.

I explained that I knew iOS programming and wanted to learn Rails to make an api backend. I also added that I had already done some basic tutorials and I only needed to learn the skills that were required to build my service.

My particular idea was to watch someone’s live coding via Skype, so that I wouldn’t have to write codes by myself. Based on my experience from Codementor, I realized that if I coded by myself while listening to someone’s advice, it would take a lot of time and slow my learning experience in the end.

It worked really well and meant that I could learn very efficiently by explaining what I wanted to do and just watching an expert coding. I simply uploaded everything via git, then my teacher coded and explained. After each lesson ended, I downloaded the code and reviewed it alone.

Even though it required a lot of my energy, since the way experts code is much faster than I do, it was very efficient and I liked it.

How you pick your mentor

After I posted my offer on Upwork, I got over 10 candidates within 2 days. My hourly rate range was around 10-40USD, and each candidate requested between 10-40USD.

Some candidates obviously sent their letters without reading my detailed descriptions, so I filtered them first. Then I did sessions with 3 candidates, one by one.

You can’t tell their level of experience and how well they teach from their descriptions and offer letters, so it is best to do sessions with them anyway. You can learn a lot from that.

Some mentors taught me what to do only after I explained what I wanted, but good ones suggested good practices on Rails and gave the reasons for them in detail.

I did sessions with mentors asking for 20-45USD per an hour, and I ended up choosing the most expensive mentor (45USD) in my budget because it turned out I could learn very fast from him compared to the others.

For me, it was the best decision since he taught me how to code cleanly in Rails, which is quite a difficult skill to master when trying to learn with Google.

Efficient learning

Basically, I did pair programming with my chosen mentor for 2 hours per session and reviewed it afterwards alone.

During the sessions, I tried to learn things which were difficult to learn by myself and asked him to show me the keywords or references if new topics were something I could learn alone later.

For example, if I need to know how to use some gem from the Github page I can google it and teach myself, but when it comes to writing data structures for my service I need advice.

It was the most efficient learning experience since I didn’t get stuck at all thanks to his help, even though there was a great deal I didn’t know about Ruby on Rails and backend server coding.

I learned a lot from this pair programming and I was able to keep going alone with Google after 5 sessions unless particularly difficult tasks showed up.

It might work when you hire programmers

I thought this pair programming thing might work when you want to hire programmers for your new projects.

If I want to hire an Android developer for Taxnote, for example, I am thinking about doing pair programming first. I can learn some basic Android developments and observe how well each developer codes and handles errors.

When you talk with developers, you learn something you can never find out from their resumes, so this pair programming thing was the best experiment I did this year.

The Upwork Post

I got an email from iOS developer who want to do someting like this and he requested the original post on Upwork, so I share that here.

*I make an Text to Speech app, one-tap timer and more. About Me.

Work for only 3 hours a day, but everyday

I am an indie iPhone developer, and I’ve been working for 3 hours everyday for almost 2 years now. It may not work for everybody, but I started this habit in early 2014, and I have continued to do it since have I found that this is the most productive way to work for me.

Taleb and DHH advices

I first got this idea when I watched the talk by DHH (Rails creator) in the startup school.

He was saying this:

“Working long hours isn’t productive at all, if you work for 8 hours, try for 5 hours, or only for 4 hours. If you only have that time to work, you don’t have time to see Twitter while working.”

Also, when I read the book Antifragile by Taleb, he mentioned that the trick to working in a productive way over a long period of time is to only work for a short amount of time every day.

Making money on the App Store is really tough, and people don’t care how many hours I spend on my apps. They only care if it is useful or not. This is a completely result oriented world, but personally, I like it.

I have always thought about how I can optimize my time to work effectively, and after I tried a lot of different ways, I found it best to limit my work time each session for the best result in the long run.

Spaces are a very important factor in UI design, and that theory holds true for working.

Why 40 hours a week didn’t work

I can choose how I spend my time since I am making my own apps, so first I’d been searching for the most effective way to divide my work time weekly and monthly.

There is no one who orders me to work, and I can rest anytime, so I made a quota first. For example, my first quota was 40 hours a week.

I calculated my work time using a stopwatch, and I checked like “Ah, I worked for hours today”, and “I went out yesterday, so I couldn’t work, so let’s work more today”.

However, even if I work for the same amount of hours, the productivity depends on the conditions for each day. When I am tired or in a bad environment, I can’t focus. The work quality was not consistent at all.

Often, even if I could focus for the first few hours, the more time would go on, the less I could focus.

Work short hours every day

Then, I made a rule to work only 3 hours every day without holidays. This is a bit extreme, but in this short hour limit, you are more motivated to work harder to make your working time meaningful.

First, the most productive time for me is after I wake up, so I need to sleep well, and start working right after I wake up. I don’t read any news or SNS because even if I only read them a little bit, it could affect my productivity because it distracts my mind.

I even disable all notifications on my iPhone before I go to bed, so I don’t see them before I start working next day.

I prepare for each day seriously like an athlete who prepares for their games in the morning. There was a huge difference of productivity between a 9 hour work day and a 3 hour day.

You really think about what to do

This was a good discovery. When you have only a short amount of time, you care about what you do more than ever.

When I develop features on my apps, I think more seriously if I should do it. Is it really worth my time for today? Is this project worth doing?

I cared about it before, but the seriousness increases when you have only a few hours to work a day.

Less stuck for coding

When you are coding, you get stuck quite often, and it can take a lot of hours to solve it sometimes. However, with my 3 hour work day, I find that this happens less since you can’t keep digging into the issue when you don’t have enough time anyway.

This way, you will be able to find the solution or come up with something the next day with a different viewpoint.

My challenge is that it is sometimes hard to go bed without solving some unknown issues, and you don’t want to stop coding in the middle of it.

Nevertheless, when you take a break from the issues, you can think like “Well, it was not worth taking so much my time anyway…” in a calm mind the next day.

What if when you are in the zone?

Another pain for this method is that you should stop working anyway even when you are in the zone.

I often feel like I want to continue working when I am in the zone for some work. But, if you extend your work time rule once, you will do it again, then the more you extend, the more your productivity will drop.

It’s a hard trade off.

If I work for only a week, working more should produce more results, but when I work for a full month, the results from shorter work days will be more productive than if I was working longer days.

If I work for a year, I can complete my jobs more efficiently with this routine. I am sure I won’t retire after several years anyway.

Keep working until I die

Previously, I thought I would rather retire early and spend my life by having a fun without working at all.

With this method, I don’t get stressed so much even if I keep working years, so I thought I could keep working with fun until I die. This is the another surprising discovery I didn’t imagine before.

To stop working when I want to work more every day was the best way to keep working over a long period of time. It might fit me to keep running like a marathon runner with a same pace instead of working hard and retire early.


I got a lot of mails after I posted this post, so I answer some popular questions here.

Q: I was wondering how work other than coding fits that profile. e.g. work with designer to prepare logo or any kind of promoting – that must be a part of your work as well, right?

Yes, I have to do everything, including UI&UX design, marketing, supporting and so on, since I’m a solo person. The coding might be around 50% of the work time.

Q: How do you monetize?

Free to use and In-App-Purchase for upgrading for Taxnote, Voicepaper, and Lisgo. ListTimer and Zeny are mostly ads based.

Q: Do you freelance, or are you available for hiring?

Not at the moment.

Q: What do you do with the remaining time?

I like reading and walking.

Q: Does it work for a freelancer?

Honestly, I don’t know, since I don’t have enough experience for that. I believe the best way to work depends on situations and preferences for each person.

I might change my habit completely in the future, if I come up with a brilliant startup idea, and want to work very hard on that every day.

I believe everyone has the right to choose how you use your time for the rest of your life. I consistently think about it too.

You can check interesting debates on HackerNews too!

*I make an Text to Speech app, one-tap timer and more. About Me.

Meeting with Parse advocate Eric in Japan

The other day, I went to Facebook Japan office to meet Parse advocate Eric Nakagawa with my friend Kato.

From left, me, Eric, Kato.

We talked about Parse generally, but also talked about how they can grow their community here, so this article might be help for people thinking about growing their developer communities in Japan.

Last month, I visited Silicon Valley for the first time with Kato, and we had a dinner with George who is Kato’s former colleague.

George kindly introduced Eric to us after he heard we both use Parse and had a casual Parse developer meeting in Japan recently.

After we came back to Tokyo, we visited Facebook Japan office located in a fancy building called Ark Hills Mori Building in Roppongi. (Facebook Bought Parse two years ago)

The Mori building is the one of the most expensive office in Tokyo, it seems Facebook has a ton of cash in their pocket.

Facebook Japan Office

Eric’s Passion

He showed their office to us, and we went outside for lunch. The one thing struck me most is his passion about Parse. I felt he is an ideal person for the job, I could see he’s been thinking about how he can support Parse community deeply.

He talked like machine-gun about Parse and developer community, we could see his energy for the product easily. If you feel passion from someone, you will become to want to support it.

During our talk, we learned he’s been using Parse as a user for a long time, even before he joins Parse. He said he still plays with it for his own small project.

He said he loves this service, and with service like this, it’s no longer a dream for a small team with only one designer and one engineer to make a scalable startup in the near future.

This is exactly the same thing I felt when I tried Parse a few years ago. I believe even one person can make a scalable product in the future.

That’s why I wrote about it on my Japanese blog several times, and I’ve been using Parse for Lisgo, and my new app too.

Anyhow, I was impressed with his passion about Parse, so during our talk, I was thinking about how they can grow their community in Japan by taking a memo with JetDo to suggest my opinions later.

How to reach to Japanese community

For Japanese developers, it feels some distance from services from other countries like Parse.

That is because we are not good at communicating in English, so people usually feel a little uneasy about using them.

Of course, many Japanese use AWS and other services, but people start using them when they can find lots of Japanese resources for that in the Blog, Tech Magazines, and programming books.

Speaking of Parse, it handles database and it’s difficult to switch after you release your app with it. With mobile apps, you also need to let users install new versions when you switch backend.

I also felt anxious about using it on my app on the App Store first, because there were not enough resources on the web from other developers actually tried it.

Therefore, it’s really important to know that developer advocates like Eric exist for the community.

During our talk, I thought, even if you don’t know him in person, acknowledging his presence in Parse and his “Ask me anything” passion makes a huge difference for Japanese wondering if they should use it or not on their products.

Then, how do you accomplish that in scalable or cost effective ways in Japan? I thought about it for Parse first, but these suggestions could apply to other developer tools.

Show up at Tech events

This might be the first thing you come up with.

Fortunately, there are a lot of developers Meetups every week in Japan, so showing up and explaining Parse tips are basic things. Also, meeting developers in person is something which makes people feel closer to your products.

You can also give some incentive to developers who write blog articles about the talk in Japanese later, since the more developers write about products, the more people tend to try it.

After I suggested this first approach, Eric said something like this.

“It’s a nice idea, but I’ve seen that many people talk about their products in tech events, then go back to their home right away. I feel that is like a marketing, so I’d like to do something which can support the community well when I do something like that.”

I thought this is an opinion from a person who has experience in developing community, and think about it well, nice.

Hire Japanese advocate?

It’s difficult to find an appropriate one, so this is not the easy way, but the most effective way obviously.

One good example is Katsumi Kishikawa who joined the mobile database startup Realm recently.

He is a well known developer in the Japanese iOS developer community thanks to his contributions to open source and community.

I believe his presence in Realm has made a huge impact for other Japanese iOS developers, and many people have started thinking about trying Realm. I feel there are lots of Meetups about Realm and see more blogs about it since his joining.

It used to be a product from a startup overseas, but now, you can contact with a person you know in Japan, this difference is huge.

However, you can’t find a person who is very good at coding, and active in developer community easily like him, so I thought about other ideas too.

Show up in tech news sites

It depends on if good sites accept interviews or not, but it’s easier than other ways I suggest here.

During our lunch with Eric, I kept thinking in my mind like this, “Oh, if someone from tech sites could write about this talk, then a lot of Japanese developers can see his passion for his work.”

Japanese developers could feel close to your product by reading interviews with advocates, and you might be able to advertise office hours to developers when advocates visit to Japan.

Translating Helps, or another thing?

Translating takes time and costs a lot, even though the effect can be obvious. The issue is the balance between the cost and the merit.

So, maybe another way.

In Japan, people often buy a Japanese technical books to learn about new programming language and services at first.

For example, you can find lots of technical books written for people who want to start Amazon Web Service and Google App Engine in Japanese if you search on

This is because, official manuals are written in English in most cases, and reading that are not easy for us. Also, it always helps to read tutorial from different perspectives.

Usually, authors write these kind of tutorial books not for money, because royalties from the book itself doesn’t cover the cost for the energy of writing.

The authors would rather expect selling their personal or company names which could connect to their next jobs by writing technical books.

I believe encouraging and supporting developers who are thinking about writing tutorial books for your service at all cost is important especially in Japan.

Add to that, I personally requested that Parse will write a detailed help for migrating to another service like Amazon Web Service.

It’s true that most services fail before they need to worry about scaling and migrating, but it’s also true that people dream and worry about scaling before start using Mobile backend.

There are not so many articles about this topic on the web, so I guess some people choose AWS or their own server from the start to avoid migrating risks.

We might not need to migrate at all anyway in the future with Parse, but understanding the method of migrating to other services well could make it easy for people to start using Parse.

Ask Parse Anything.

*I make an Text to Speech app, one-tap timer and more. About Me.

Start from the riskiest part

When I make new apps, I always try to check to see what is the riskiest part of the business.

Plus, I try to look for the fastest way to check that. I think like this for everything, including ideas for new apps, programming, and so on.

So, what is the riskiest part for me?

Motivation Risk

Motivation is the engine for everything. I believe this is the most important aspect of your work. If you lose it, it’s over. It is always reflected in your work.

Therefore, what I care about first is not losing my motivation during developments.

If I make something, I want to make something amazing. If I want to make something amazing, I need to keep going day by day. If I want to keep going, I need to pick something I can keep my passion for.

How is that measured?

My trick is to wait. I usually wait for weeks, even if I come up with something I am excited about.

When you get a new idea, you always get excited most at first, but after several days, that excitement could fade away gradually.

If you still have a passion for your new idea after a few weeks, it could be something that you wouldn’t give up on easily.

Technical Risk

Another important thing is to consider whether or not your idea is even possible to achieve with current technology.

You can’t create it if technology and ecosystem are not ready, no matter how much you want to make it.

This is also essential when I start programming something new. I always start from the hardest part, in other words, I want to start on the part of the project that I am not even sure that is possible to implement yet.

This doesn’t mean you must jump on the hardest thing at first, it means you find the most important thing and start from there.

It’s better to tackle on the most important and uncertain parts first, and skip the small things that you can predict.

It might feel good if you start from easy things you can do since you feel productive after seeing your progress. However, if you find out that the most important part of your app is technically impossible later, everything you did beforehand will be a waste of your time.

Demand Risk

This is the most difficult part to check.

The two things above are something you can see by yourself, but demand is different.

The only way to check this is to ship your product. Shipping takes time, that’s why you should start from the riskiest parts to minimize the risks.

There are tons of uncertain things in this world, including your health, environments, change of the ecosystem, and some things you never imagine.

So, skip the easy and small parts of your project, and start from riskiest things in easy and fast ways.

*I make an Text to Speech app, one-tap timer and more. About Me.

Making a simple video tutorial is one of the most cost-effective ways for your apps

It is now the era of video. You see lots of promotional videos from dozens of new startups. Twitter co-founder Jack Dorsey also said “Don’t let users read, let them watch” when creating promotional sites.

I can intuitively tell this is the right approach. Nowadays, when I research something new, I hesitate to read descriptions of new things first. I’d rather search for video explanations or tutorials to get the summary of them before I read.

Even when I learn new programming languages or frameworks, watching video tutorials on YouTube helps me understand the basics much faster than reading documents at the beginner stage. The same goes for new users on your apps.

Even if you create decent descriptions and screenshots for your apps, they cannot win against video tutorials, which clearly show where you should tap and swipe with animations. There is a huge gap in usefulness between the two.

Making a good video is not easy

Having said that, it takes time to make a decent movie, especially if you want to make a really nice and professional video.

You should care a great deal about scripts, sounds, and editing. These things can cost a lot and take up a lot your time.

That’s why I didn’t place much of a priority on making promotional and tutorial videos, especially as an indie developer who didn’t have enough of a budget.

For example, you will see many high quality movies for apps like this on the web.

Making a video like this must have been expensive, and I certainly can’t afford it.

If you are running a startup, a video has an important role when you do fund raisings. For me, it’s enough if users can understand what it is.

For new users, I wanted to create a video that shows the experience they can get from the app, instead of just explaining how to use it.

Creating a video that demonstrates the user experience

It’s hard to make a video that really demonstrates the user experience. You certainly can’t make a good one within a few hours.

I made just such a video for my app Voicepaper.

It’s not quite as nice as the path video, but I guess it’s ok, considering I recorded it with my iPad. Thinking about scripts, recording, and editing with iMovie still took a lot of time.

If making a detailed video takes up too much your time and it’s not an easy task, I would prioritize and do other important tasks first.

Regarding the Voicepaper video, I still don’t know if making it was worth my time or not. Measuring the cost-performance precisely also doesn’t seem to be worth the time.

I was very lucky, just like getting a gift from Santa Claus. My competitor made my app promo video for free, but that kind of thing doesn’t usually happen.

Recording simple app usage tips is another option

The thing is, I thought making videos was not cost-effective enough before, but I was wrong.

From a developer’s point of view, I’ve always wanted to create very good ones, which doesn’t make my apps cheap.

But from the user’s point of view, they just want to decide if an app is worth downloading by looking at a quick video explanation.

Especially if you make tool apps like I do, users know what your apps are made for from the start. Therefore, showing them some basics on how to use the app could be enough.

You can also explain the benefits of your app briefly at the beginning of the video.

I realized this when I was learning a new programming language on YouTube.

You can learn quickly from documents or blog articles once you know the basics and backgrounds, but at the beginner level, watching easy tutorials is very effective and fast.

For example, if you are interested in making iPhone apps, here it is.

This is a video with only screen and voice, but it contains very detailed information that simple text with screenshots cannot cover. You don’t need fancy sounds, actors, and the camera even has shake correction.

This is it, I thought. Why I didn’t use this format before?

It doesn’t take very much of my time, probably only a few hours, including editing with iMovie. The cost of making it is very low, but it still makes a huge difference.

When I get questions from users, I try to explain how to use my apps in details without any technical jargon, which can be difficult. If I make a tutorial video once, the support process becomes easier since I can now just show the video and give brief explanations when needed.

I made one video in less than 3 hours

I started recording the usage of my bookkeeping app Taxnote.

0:10~ Basic Entry
0:55~ Add memos
1:15~ Editting entries
1:30~ Overview for entries
3:00~ Reorder categories
3:10~ Rename categories
4:15~ Bulk delete
4:33~ Data export
5:25~ Print your data
6:20~ About upgrading

English is not my native language and I don’t speak it fluently, but I can still show where to tap, swipe, and explain basic uses with my left hand.

All I did was record my explanations one by one with iPad, and then edit them with iMovie.

Speaking of editing, I merged several clips (4-5 minutes each) and added subtitles. In the end, I increased the speed of the video to 140% for users to watch it faster.

It’s that easy. It didn’t even take me 3 hours to finish.

I put this video on the top of the Help page with the table of the contents.

I always try to think of ways to get good results with a minimum amount of time, and this video tutorial is something I should have done earlier.

*I make an Text to Speech app, one-tap timer and more. About Me.