Developing JWords — A weekend project in 365 days
If you are kicking off a new side project a weekend off-site can help you focus and get far, fast. In this case, off-site just being not at home.
I did this, I took a weekend, and I planned to release my new project before I returned home. Turned out, I needed another twelve months.
This is my recap of how I built JWords, a mobile word puzzle game for Japanese. I hope to show how long it can take to build an app like this and things that can help you along the way.
This story starts Nagano, a few hours on the Shinkansen from Tokyo, and ends with this article a year later.
Getting the idea
In 2022 an app called Wordle became a viral sensation. It became so popular that it later got acquired by The New York Times. You might even have seen others share their game experience on social media like below.
The game mechanics are cleverly simple. You have five tries to guess a five-letter word, the fewer tries you use the better. You compete against yourself.
When guessing a word, each character shows if it’s correct, in the wrong place or not in the word at all by changing the characters coloured background.
I too got hooked on this game (although a different app). As I study Japanese vocabulary daily, it got me thinking, could I build something similar for Japanese?
A good challenge
With some quick research, I found a number of word puzzles for Japanese. But not with the same simple and addictive gameplay as Wordle.
I realized the reason might be that English words, with an alphabet of 26 (Latin) letters, are comparatively easy to guess given the hints the app provides.
Japanese words are far more complicated. They can be written using Kanji (a version of Chinese characters) or one of the two simplified alphabets called Hiragana and Katakana. Both of these have 46 base characters but over 70 using diacritics.
My goal was to create this for users such as myself, who are still learning Japanese. So it had to be easier than the original Wordle as well.
Challenging, indeed.
Four days that extended to one year
By removing the need to do any housework (cooking, laundry, cleaning) and other distractions for a few days, I’ve found that I can reach crazy heights of flow state.
Living with a family, however great it is, has many distractions. For this reason, when an opportunity presented itself in March 2022, I packed my bags and booked a hotel in Nagano for three nights.
During this stay, I rarely left my room. I had included breakfast and got instant coffee, bento’s and snacks from the convenience store on the first floor. This allowed me to clock almost forty hours on the project before I went back home.
For another project (like this one) that might’ve been enough, but for this app, I wanted to release it polished and working well. It turned out that would require another 80h.
The problem is, life needs to happen. When I left Nagano and returned to Tokyo my every day as a husband, father and CTO of a startup left very little time.
It would take another twelve months before I finally released the app (and wrote this article), after giving it a total of 120 hours.
This time includes everything from ideation and research, developing, testing and release preparation, and even writing this article.
In retrospect, I could probably have carved out the time to finish this earlier. But being able to take the time to pre-release, collect feedback and data and iterate, as well as “to sleep on it” (365 times), improved the end result a lot.
I have now guessed over four hundred words myself, over a span of two hundred and eighty days. Together with months of analytics and critical user feedback, I have been able to do more improvements than a focused one-month of work would have allowed for.
But still, an entire year?
Progress, like inspiration, comes in waves
I track the time I spend on any of my projects, billable or not. It helps me know where I spend it and it gives a measuring scale for future projects. The graph below shows exactly when I spent the time over the year.
After July I knew I would have less time to work on the app so I instead made sure to open a beta-release and begin gather data from users. The graph below shows how in August, I began getting users in.
The following table breaks down in detail more of what happened to the app during this year of development.
Most of the app functionality was created in a few periods of intense effort and flow state. In between these, hours were spent here and there on measuring and thinking.
My building process
From the start to finish, I applied many things I learned through building my past apps and working my full-time job leading a product team.
These concepts, even in isolation, can create focus and better outcomes.
Some seem obvious, but a few years ago, I didn’t apply most of these and if I did it wasn’t intentional
This is because they are easy to read and write about, but using them in practice was and is a learning process. I had many failures along the way, but each thing has proved its value time and time again. And the better I learn to apply them the better value I get.
There is also the actual process of developing (coding) the app. However, I will leave that for another time. Until then, please message me or comment and I’ll be happy to assist.
Below, I will cover the top nine concepts that I think can help you or your team in your projects.
1) Outline the idea
Any undertaking, small or large, even this article as an example, benefits hugely from starting with defining who you are doing it for, what the context is and what you hope to achieve.
In other words, define:
Persona → Scenario → Goal
With this in place, prioritising all the millions of things you could do becomes far easier. Without a clear direction, it is easy to slip into running in circles doing busy work.
Of course, you will likely change this as you learn more about the problem. That’s great. If you know what your goal was, it is much easier to change it and think about why you need to change it and what that change affects.
In JWords, I chose students of Japanese such as myself as the target persona. I expected them to be looking for a word puzzle, the same as I was. They would have some knowledge of Japanese input and words. This meant that I could focus my effort on helping users come up with words by making the guessing gameplay the key part of the app.
2) Keep a development journal
I believe writing is thinking. Imagine if you could remember every thought you had and be able to see it in the third person. That is what writing allows you to do.
Even as I outlined my idea for the app, I was putting this in Notion (my currently preferred documentation tool). It doesn’t matter where you write. I have used Google Docs, text files on disk and Confluence as well.
If you are a team though, sharing your writing effectively will become a necessity almost immediately.
Having the notes around, I could pick up almost immediately after each coffee break, night’s sleep or even a week away from development. Without this, I would have lost most time I had in context switching.
It is also an invaluable tool when making changes later in the project. Being able to go back and question your previous decisions is much easier if you have a record of them.
To date, I have fifty-two entries in my project directory. That is almost one page, long or short, for every two-three hours of work.
3) Move in small steps
The truth is, whenever we build something new, anything we create is just guesswork.
I built most of the functionality in smaller 2–3h sets of work. After each, I tested it myself or asked others. With the feedback, I could either leave it as it is, improve more or sometimes remove what I built.
Small teams can seem to move faster because they can move in small steps. Small improvements come one by one frequently. For users this is great and it is motivating for the product teams as well.
I know not all projects allow for this, but chances are, your project can do it and benefit.
If you have a developer on your team that is keen to do XP (Extreme Programming), this is one of the things they are hoping to do.
4) Solve the biggest problems first
Most applications I’ve worked with start with implementing users and registration. This is really curious because, this isn’t even a feature of an app, it’s just a requirement.
But whatever value the app provides, most times it can be done without login and it will require far more effort than restricting access.
Yet many projects start with the login because it feels like the first point. Let’s start with the toughest or riskiest part instead.
I knew that payment and user management might be needed for JWords later. I knew it would be complicated and take time. However, I identified the input and guessing of words as the core problems.
So that is where I started and as it turns out, even now a year later, I am still not at the point where I actually need payment or registration. What if I had started with those things, maybe I would not be writing this article.
So, solve the biggest risk first and then iterate on it until it is not only solved but solved well.
5) Make several designs
I had the privilege to be the manager (as well as product manager) for a few designers leading up to this project. Working with them, I learned that a single design rarely is the right design.
Just like writing, design requires a process of generation and then selection. As a developer, this concept is foreign. I like to write one piece of code and then refactor it until it is “correct”. Developers seldom have the opportunity to build several solutions and pick one.
But in design, we can create different levels of fidelity (quality). That way, we can generate quicker, compare and select. Then refine and repeat.
In this project, I forced myself to generate more than one solution. Often, I created the designs between other tasks, left them to sit for a while and then revisited them with rested eyes to decide which direction to go.
But as with anything, this process wasn’t always the case. The app icon, for example, has gone through several iterations and by the time you read this, it might have changed again.
However, iterating like this can cost a lot of time if the update isn’t easy to change. In the case of an icon, it is relatively easy to replace. In comparison, the statistics screen of the app requires a lot more work, including animations, layout and testing and would be far harder to iterate on.
So be sure to clarify with the developers what parts are open to updates later compared to what requires effort to change.
6) Do case studies
Very few, if any, ideas are brought into existence out of nothing. Everyone takes inspiration whether consciously or not.
Not seeking inspiration can waste time. In engineering, we call it “reinventing the wheel”. Building something yourself that someone else has already built.
It takes lots of time to research and test out solutions so for anything that is not your unique selling point I propose you shortcut that by looking at what is already out there.
Unless it is core to what you are doing, copy. Of course, within the boundaries of what is legal and moral. I would not copy-paste anyone’s landing page but, I would take their layout.
I would not completely replicate someone’s onboarding flow but, I would reuse the same steps.
And so on. Take the time you save and invest it in what makes your product special.
7) Set a north star metric
A north star metric is one single number that you can measure to see if you are moving towards your overall goal. Usually, a company has one single north star metric but I’m sure there are examples where products, teams or features have their own.
The idea is that by focusing on one top-level number, whatever you do, as long as that number is rising, you are on the road to success.
I would have been better off setting my north star metric earlier. I only decided on one late in December, a few months before releasing the app. If I had the number earlier it would have help me further focus on where to put my effort.
This connects back to setting your goal for the project. This is the one number that tells you that you are hitting this goal.
The number I chose was “Number of completed games”. This means users that have guessed a word, whether right or not. As long as I am getting more and more guesses in, I must be doing something right.
It doesn’t matter if users are successfully guessing or not if they are guessing the same words over and over again or anything else. As long as more and more users are guessing more and more, it means they are enjoying the app.
As the graph above shows, my work is by no means done at point of release. My number must be turned around to retain the users I have acquired and make new users successful.
8) Open beta release
I should have released far earlier but in August 2022, almost five months after I started the project, I opened the app for public beta access.
This means that given a link, users can download the app through AppStore TestFlight and Google Play. They can use it and leave feedback but not reviews.
This way of pre-releasing an app can save your app from harsh reviews before you have iterated on it and there is no better way to find issues and get feedback than relying on actual users.
I promoted JWords by adding a banner in my other app (JReader). This was enough to create a fairly constant flow of users downloading it. I have far more users on Android than iOS so this of course, also reflected in the number of users I was able to get in the beta test.
Over the seven months since from August to March I was able to acquire over five hundred users testing. Of these, I had five feedback submissions so around 1% of users sent me feedback. I didn’t actively ask for feedback in the app though so this could have increased the number of responses much more.
9) User testing & getting feedback
I left the most important part to the end. Feedback.
Although I think it is far more common to talk about user feedback than actually collecting it, this is the most important part of developing something new. Unless you are building for yourself, if others don’t appreciate it you need to iterate.
The only way to find out is to put it out in front of users. I know this is really hard. I feel it to and I am still struggling to do this.
I have written about how to do usability testing in the past and if you want to know more about how I find testers or what I look for in feedback, message me or let me know in the comments.
For this project, four different channels to collect feedback.
Testflight
If you cannot meet your testers and they are on iOS, Testflight is a great tool. It is also the only way to provide an app to your users without releasing it so, it will be there for you without any extra setup.
You can tell users what you want feedback on as you release an app for testing and your users can add comments to screenshots.
It requires the testers to know how to use the feedback functionality effectively and this makes it hard to use with external testers.
In-person testing
This is without doubt the best feedback you will get. Watching a user use your product there are so many more feedback points than what they say that will help you.
Where are they using it? What is going on around them? Where are they tapping? Are they context switching? Where do they pause? Are they excited or annoyed? And so on..
Surveys
Surveys are perhaps the most common feedback tool because they are honestly, easy to do. However, of my six months and five hundred users, I had four replies.
Conversion is low and likely, you will get feedback only from a few users who are either happy enough or angry enough to care. This can be really good feedback though. For example, if someone is thrilled about your app and tells you why, double down on that. If you can get all users as excited, you win.
Also, surveys can act as a funnel to fuel your in-person testing. Ask if you can connect them again in the form and send them an email thanking them for the input and if you could call them up for a one-on-one interview session.
Data
Lastly, add Google (or Firebase) Analytics to any project you have. Without it you are blind after release. Add events for the most common features, actions and conversion points you have.
This data can be really valuable, but it takes time to accumulate and interpret. If you have only a few hundred users any change you see in data can just as likely be due to the weather (literally), economy or otherwise rather than something you changed in the app.
It is a must-have for validation, but like having scale to check your weight, it is only a measure, not a guide to what you need to do.
A recap of nine concepts for development
If you stuck with me this far, good job! That was a long list and lots of things to take in. If you take anything from it, it should be about feedback.
Almost all of the above in one way or another comes back to defining what you want, getting to point where you can test a solution quickly and then getting feedback on it. Rinse and repeat.
As a refresher, here is what I shared again
- Outline your idea; Define who you are solving what for
- Keep a development journal; Track your thinking
- Move in small steps; Do little, test, repeat
- Solve the biggest problem first; Prioritise by risk, not usage flow
- Make several designs; The first solution is seldom the best
- Do case studies; Move faster in other peoples footsteps
- Set a north star metric; Measure the progress to your goal
- Open beta release; Get actual users to test early
- User testing & getting feedback; Only end-users can tell you if you are solving their need
The project technically
Since this is a mobile app and I was also developing it, it would be amiss not at least to mention what I used to build it and why. Skip ahead if the tech stuff isn’t your cup of tea.
My goal was to develop and release an app all on my own and in a very short time. To achieve this I relied on technology and tools I had prior experience with.
The only new addition to this was Riverpod which I felt I had to learn to create a project structure that wouldn’t slow me down as the project size grew.
JWords is brought to you using:
- VSCode as the IDE, using GitHub Copilot
- Code is hosted in Gitlab, with GitLab CI for linting and testing
- Flutter with Riverpod
- Firebase Analytics and Crashlytics
- Firebase hosting + VueJS (tiny editor for the playable words)
If you are interested in more details about the development part of the app, let me know and I can share directly or even write a follow-up post.
Conclusion
For anyone in product development, be it you are a designer, product manager or developer, I recommend creating and releasing an app of your own.
You can build it by yourself or with a team. What’s important is that you get involved in the full end-to-end process of creating, releasing and running the app.
What I have learned building on my own has been indispensable for my full-time jobs and career progress.
By getting hands-on experience with all the parts involved, you will find an appreciation of all the other counterparts you may have in a bigger team or, better yet, fill those positions if they are not already in place.
If you are interested in hearing more about the app, and the development process or would like additional deep-dives into some topic I didn’t cover (such as the development), send me a message and I would be happy to assist!
You can find out more about me or my other projects by following me here or at https://greycastle.se
