Monster Math for Android

Almost 2 years back, we started working on a math game that would make it incredibly fun for kids to practice Math. As a result of that, we first launched Monster Math way back in November 2014.

We got a ton of interest and feedback from both Parents and kids, as well as a lot of happy customers. With everything we learnt from that experience, we built a new Monster Math – with 4 worlds instead of 2, plenty of new characters, a platformer style game play, hilarious animations and loads of tiny refinements that made math even more engaging for kids.

Over this time, a grand total of 1.4 million users have downloaded Monster Math apps on the App Store. This is truly a phenomenal experience for us, which proves that there is always a market for products built with love and care.

Meanwhile, a lot of people who were not using iOS devices, asked us when we’d be bringing our apps to the Play Store. And we kept telling them – “soon”.

This week, we’re bringing the Monster Math experience to the Play Store – it took us nearly 3 months to port the entire game to a cross-platform SDK, and we’ll now work to bring it on more platforms soon.

So sit back, download Monster Math, and enjoy Math like never before!

Engaging With Your User Community – Twitter

I’m an introvert by nature. I prefer spending a lot of time with a few close friends and associates, rather than spreading that time over too many people but without doing enough justice to any of them.

However if you start a company that aims to serve a particular community, there is no way you will be successful if you don’t engage with people from this community. You need to understand them, you need to build relationships with them and you need to get feedback on your service or product. And you need to keep working on this cycle till they love your product and are willing to spread the word about it.

All this means getting to know new people.

At makkajai, we build Educational technology. More specifically, our first iPad app, Monster Math, is an Arithmetic app that combines tons of fun with really smart feedback loop. While we built the Math Game with kids as the center of our universe, and did a pretty good job with that, we had very little access to teachers who used iPads in their classrooms, especially from markets where iPad had deep penetration. This was especially important because educators would be the key influencers for us.

Sure, I personally knew tons of teachers in India, but they very few had access to iPads or other tablets in their classrooms.

Around this time, one of our advisors and close friends recommended we started focussing on Community Engagement.

We wanted early-adopter schools and teachers to try out Monster Math so we thought this was a good way to combine both the things. However, some questions bothered us.

How do we do find people?

Enter Twitter. Most tech-early adopters already are active on Twitter, so it seemed like a no-brainer to us that this is the place we should be looking. We did experiment with other social networks and even forums like Reddit, but Twitter seemed natural right from start.

Will people talk to us?

Again – Twitter!

Unlike Facebook or Whatsapp, which are about keeping in touch with your existing friends, or LinkedIn, which is about your professional network, Twitter is built around interests and engaging with people of similar interests. This is especially useful, because people expect to make new friends on Twitter purely based on mutual shared interests.

I already had an active twitter account for few years now, so it seemed logical for me to continue using that account.

Will we seem salesy?

While I’ve used twitter before, it was only on a personal level to engage with people I found interesting – with absolutely no other agenda. Doing this, with more effort, especially to try and push a product seemed very unnatural.

We did not want to spam people – no one likes a person whose first message to you is “try out my product”. On the other hand, faking interest in people and trying to engage with people just to ask them to try out our product just seemed wrong.

Trying to disguise a sales pitch as genuine personal interest seemed shallow at so many levels.

And so we promised never to do that. Instead, although I started spending more time on Twitter, I used it like I would as an individual and not as a business.

Instead of sales, we decided to treat this as a customer development exercise, with following goals –

  • To become a part of thriving EdTech community already existing on Twitter.
  • Engage with the community in general; speak to them about the things that are important to them, understand what makes them tick, learn their pain-points.
  • Add value in general – help whenever possible, without expecting anything back. Share interesting things which may be totally unrelated to what we do, but are interesting to our community.
  • Avoid a sales pitch at any cost. The most we would do to bring attention to what we do is use our bio.
  • Don’t look to sell. Even when people were interested in trying out our Product, instead of trying to be sneaky and extract extra dollars, we gave away promo codes. After all they were helping us out by giving us valuable feedback, it just felt wrong to ask them to pay for it too.

Any trials or downloads we get out of this would be secondary in nature; the primary goal would be to learn more about the people we want to serve and engage with them on a personal level.

I was astonished to see the results!

  • I started forming so many real friends on Twitter. I met several teachers that have done such interesting things in their classrooms that their passion for teaching is infectious.

Every interesting story we come across, every motivational video, even a thought provoking quote, just keeps igniting our passion for Education further, pushing us to continue doing our best in this domain.

  • I met so many interesting people with similar interests even outside EdTech and ended up having varied and interesting conversations. I found other Game Designers and Haskell Developers for example. I had conversations with them on topics from intricacies of functional development, to philosophy of time and it’s essence.


  • We learnt about new things. For instance, I learnt new resources, such as TeachersPayTeachers which we could use to cut time creating supplementary material for our app.

  • It was easy. Because connecting with someone is the most human thing you can do. And Twitter makes it easy to do so.

  • People wanted to help us. Whether you call it good karma or just law of averages, on one hand we strived to help without expecting anything, but we also got help from totally unexpected quarters.

We did manage to get early trials and feedback. In fact some of our new friends even helped us promote Monster Math!

And we got these with no sales pitches. Teachers who tried out Monster Math were genuinely interested in what we do. They were also extreme early-adopters – teachers who’ve done 1:1 iPad classrooms before the mainstream, for example. Or teachers who do podcasts. And those are the best people to user our product early on, because their feedback will help us build a really valuable offering.

In short – Twitter is an amazing place to find people with the particular set of interests. You can really get to know the community your business wants to serve. Treat people with respect, add value and you will be amazed at how much you can get out of this community, not only on a professional but also on a personal front. Just make sure you don’t add to the spam.

Hire a Developer to Build Apps

Ok, so you are an entrepreneur, and you have an app idea. But you are not a Developer, and you have no idea how to go about hiring one – how to you go about it?

First of all, the basic assumption here is that you have a very good idea what you want to build. Make sure you have created a spec – something like this.

Also, you might need a designer to make the mockups before you hire a developer; or even an artist if you are building a game. The process to find a good designer will be somewhat similar to that of finding a developer, except that you will look at their existing portfolio and ask for rough design sketches instead of solutions (for the last round of filtering).

This is the workflow I recommend –

1. Source good leads first – through your contacts/friends, advisors or even places like this group. Contact those leads and see who are interested. Then get samples of their work. 

2. Filter out those who are a bad fit. (for e.g. have no iOS experience) – speak to all of the rest, do a video call so you get a better sense (somehow helps more than just a voice chat, IMHO)

3. Further filtering – share a bit of your idea in your interview, ask them how they might go about with it, and what kind of estimate can they share. Some of them might say they can only give a ballpark or need more details to do an estimate (which might be a fair thing) – basically try to get a sense of who might be confortable doing this task. 

If someone has done a very similar task, short list them. But also shortlist developers who have good experience in general and are able to think through at least some aspects of how the solution might work. 

4. See how many you have shortlisted – 3-4 is a good number. Ask them to do an estimate, share more details. 

(might want to get them to sign an NDA at this stage). 

Cover the cost of estimation for all of them (I think that’s fair) – let them work out a detailed solution doc and a corresponding estimate if they were to implement that solution fully. You are paying them for this work (say 1-2 days, maybe a bit more if it’s complex), but it’s a lot lesser than the entire dev cost, and it helps to weigh your options more clearly. 

Based on the solutions and the final estimates, take a call on whom to go with.

5. If the winning estimate is more than a month or so, try to break delivery into chunks – prioritise your features, get something delivered (deployable state or at least demoable state) every 15 calendar days. This significantly reduces risk for both parties. You can always switch to one of your other short-list candidates.

PRO-TIP: maintain good relationship with all your shortlists, especially those that you did not hire because you needed only 1 developer. Explain to them why you hired someone else (better solution from someone else, better estimates, etc) – most will like the transparency and it will help you next time you want to hire someone.

10 Questions to Ensure That You Have The Right Cofounder

CoFounding a Company is a lot like marriage; only more difficult. Usually, there are more than 2 people involved, there is a baby born on the first day (your company) and that baby will demand almost all your attention every day.

And you are legally bound to them; if you ever were to separate, there would be an issue of the custody of the baby, as long as it makes it.

Obviously, you have to get into bed with the right people!

Answer these 10 questions to know if you have the right co-founder for your company. The below are in singular (so you can judge one cofounder at a time)

Is your  Co-founder –

  1. different enough that they bring a unique perspective and a different skill set than what you already have?
  2. similar enough that you don’t have large ideological differences and ambitions about where your company should go in the long run?
  3. someone you respect and respects you back?
  4. someone you trust and trusts you back?
  5. someone who you can rely on to deliver?
  6. the best at what he/she does?
  7. a team player?
  8. sold on the problem you are trying to solve?
  9. a self-starter?
  10. willing to learn?

Even a single “no” means you should rethink.

Are there any questions you would like to add here?

What Makes A Game “Dream Team”?

So you’ve decided to take a plunge and explore the world of Game Development. And then you wonder, what kind of a team will help you get there?

At makkajai, we’ve been there, and we’ve had our fair share of lessons along the way. I’m sharing this, in the hope that others find it useful and can get up and running, building amazing games, even faster than us.

Unless you are just building a hobby Game, or have decades of Game building experience (and even then), you need a good team to supplement your skills. At minimum, you need these roles identified and amazing people to fill them.

  • Game Designer – U/x Designer on Steroids + knows Technology as well as Business + Good Leader And Manager

    It’s important someone owns this role on the founding team. This is not just UI design or U/x Design but Game design – holding the bottom-line for the game and bringing various experts to work together (story, technology, art, etc.)  Really, if you outsource or delegate this role, you are not a game maker, you are just a publisher.

    There are very few game designers worth their salt, but with effort, you could do a good job yourself – this is the best book I have read on this topic, must-have before you start even considering building your first game. Take a month just to read the whole thing and then read it again just to sink it in. Absolutely worth it.

  • One (Amazing) Developer – Polygot if possible. Building a good game is hard work, and you want a developer that can just deliver on anything that is technically feasible, without a skill gap coming in the way. Even simple games can get complex as you improve it in stages, or even have multiple moving bits (server-side processing for example), so I cannot overstate the importance of this. 

    How amazing? As much as possible, and then a bit more. Someone you would choose to build some software if your life depended on it. At such level of awesomeness, it really doesn’t matter whether the person has Objective-C/Android Experience, because they will learn it in days.

    It helps if you have another developer (maybe Game designer doubles up as developer, or someone else on the team). But one person needs to be an out-and-out technical guy/gal. And helps if he/she is a co-founder.

  • Artist – Someone to actually bring your ideas to life with pencil and colors. (figuratively of course, people use digital tools these days!) It took us weeks to find a good artist, but when we did, it was incredible. 

    Possibly on contract initially, I don’t think you’ll need a full-time artist till you start working on multiple games at once. But if one of the founders themselves is an artist, it can be a great advantage.

  • Sound Engineer – Sound is the magical, invisible ingredient that separates a great game from merely a good or mediocre one. Even if you don’t have a sound engineer, you will have to spend a lot of time working out the right sounds and music for your game. 

    Again possible on contract initially, unless one of the founders is a Sound Engineer or even a Musician themselves.

  • Business Guys – Yes, you need to start worrying about marketing, monetization, branding, fund raising, etc right from day one, so you can actually achieve your dream of building that awesome game.

If the Game Designer and the Artist both aren’t very familiar with Photoshop/Illustrator, then you might need someone with that expertise. But generally this is not the case.

Depending on your ambitions, you might need other people. Professional writers for your story, Translators for localization. But the above is what you start with.

Make sure you have an experienced or at least a very skilled team. There is no room for interns (unless they are exceptional), at least in the beginning, if you are building a game. But then I think you should never hire interns for a startup; what do I know!

Should A Founding Team Work Remotely?

This is a big question right now starting at makkajai, and here is my personal take on things.

The advantages of remote working are well-known – more options for a healthy, well-balanced lifestyle, better recruiting options, generally more productivity, freedom to travel without compromising on work, and so on. However, is this option to be limited only to employees, or can a founding team start working remotely, essentially building this into the company’s DNA?

Remote Working is Scary – it’s a huge departure from how things are traditionally done. Some of the points that could be seen as valid concerns –

  • Productivity – will productivity remain the same? Will it get affected? Will availability (or in-availability) of other co-founders outside of strictly scheduled times affect us?
  • Interactions between the founding team – This is a big one – what about all the informal and unplanned discussions founders need to have so ideas culminate, that did not just originate from one person’s head – how can that happen if we are not all co-located?
  • Investor dilemma – Would a potential investor see this negatively? Can questions arise, such as "if the founders are not even willing to move to be co-located, how committed are they to the startup?"

Let me try and address above issues one-by-one

  • Productivity – I think this is generally a non-issue. Having worked remotely as a consultant for couple of years, especially in teams that have never had a remote-worker before, I think clear communication and discipline can ensure that you are just as much, if not more, productive when working remotely. There are several reasons for this –

    • Lesser distractions – meetings and other important discussions need to be planned up-front, which is a good idea anyways, but doesn’t normally happen when working in-person; it’s very easy to just start a discussion with "hey, tell me something.."
    • Tools such as Skype or Hangouts make video calls quite cheap, as long as you have a reliable internet connection (Abhishek, I’m looking at you!)
    • Being remote, you can now be judged solely on what you contribute, compared to how many hours you spend on the venture. Personally, I think this is very, very important – it forces us to go beyond mere "sacrifices" and focus on "contributions" which is a more fair way to judge what a founder brings to the table. If, sometimes, uncomfortable questions need to be asked, they need to be asked and will not be pushed away with thoughts such as "at least he/she is working hard".
  • Interactions between the founding team –  I agree this is important – however I think the main point to focus on is Interactions. There are ways to enable this even remotely – for e.g. we can just enable a live camera 24*7 and let people just *pop-in* virtually on any team member, if that’s what it takes to get us comfortable. Skype, Slack, basecamp, and several other tools can relatively cheaply make virtual interactions not only a lot more feasible, but also leave a trail of discussions (something that doesn’t necessarily happen in-person) – which can be quite useful for later reflection or for new-joinees.

    The key here should be focussing on enabling the right infrastructure to making this work.

  • Investor Dilemma – this is I think, simultaneously, a real issue as well as the least important one; I agree that investors will probably give us some grief over this, till we show results. However that’s the key I believe – investors will always give us grief till we show results. I wouldn’t personally want to work with an investor who just forces us to work in an office, even if we have shown results working remotely; such level of operational interference can be painful.

    In fact, in some ways, this can also help us attract the right investors. Startups need to do something different from other startups, because 90% of them fail – the more different we are, the better chances of us standing out and actually succeeding. And investors do know that, so this can be an excellent PR strategy. Plus, if we quantify the cost-savings in terms of reduced salary and other expenses, I think it will help sway investors even more.

There are several key advantages too –

  • Ability to hire great people to work remotely – this single-handedly enables us to hire the best people in the world, without worrying about location; and not just for transactional roles, but important product, development and sales roles. Putting the infrastructure in place right at the start of the company will give us the necessary experience and processes that will help in putting such a hiring plan into action
  • Better Sustainability – there is no question that there is a better work-life balance for founders working remotely; given that most startups are able to drag-on for more than a year and have increasing chances of success, the longer it can sustain, I think paying attention to softer aspects such as being close to family can be a big deal to sustainability.
  • Lesser Costs – several personal costs are reduced for different founders in different cities – and this leads to lesser cash salaries and lesser burden on the company. Even with all the additional costs of supporting infrastructure, there will be a lot of savings on rent, commuting and travel.

As a summary, I personally think remote working is not just a viable option, but the best option available to even a founding team, especially one that is experienced, good at communication, knows each other well and is mature. The key would be identifying issues and taking concrete actions to resolving those issues rather than blaming remote working for them.

There are some really good posts on how to do this effectively, tools to use, and more –

What do you think? Can a Remote Founding Team work? Or are there pitfalls that are just impossible to avoid?

Git-Svn–Working With Multiple But Selected SVN Branches

(Starting from a trunk-only checkout)

Who doesn’t like Git? And who doesn’t have to work with SVN?!

It’s a fairly common practice in a project that I’m working on, for several developers to use git-svn to avoid having to deal with Subversion pain; rest of the team is not ready to move on from SVN, so this is the next best thing we, git-lovers, can do.

Since our work is limited to a particular directory in SVN and there are lots of other things in that same SVN Repo, plus we have a branch per release policy, my repo had only the trunk checked out (+ one of the old release branches). The .git/config file looked something like this –

    repositoryformatversion = 0
    filemode = false
    bare = false
    logallrefupdates = true
    symlinks = false
    ignorecase = true
    hideDotFiles = dotGitOnly
[svn-remote "svn"]
    url = https://<svnurl>/<ourSpecificDirectory>/trunk
    fetch = :refs/remotes/git-svn
[svn-remote "rb-1013"]
    url = https://<svnurl>/<ourSpecificDirectory>/branches/RB-10.13
    fetch = :refs/remotes/rb-1013

The two remotes, actually work like two separate remotes. The “rb-1013” would download all the data from SVN all over again, without worrying about what “git-svn” already had.

Now I had to checkout another branch – and doing it this way would take hours just to download all the data again. I could use the “-r” flag and start from a specific revision, but that too will still download all the artifacts at least – and I just din’t have so much time. It also din’t make sense to me that we need to download all those revisions when the trunk already has the same revisions as the branch uptil the point of branch creation. So, after quite some research, this is what I did.

  • Backed up my git repo (:D)
  • Removed all the rb related references from .git/config (the section for rb-1013 above – just to clean up, din’t really need that branch any more).
  • Changed the git-svn reference in config file from – >

[svn-remote "svn"]
                url = https://<svnurl>/<ourSpecificDirectory>/trunk
                fetch = :refs/remotes/git-svn


[svn-remote "svn"]
        url = https://<svnurl>/<ourSpecificDirectory>
        fetch = trunk:refs/remotes/git-svn
        branches = branches/{RB-10.26}:refs/remotes/branches/*

Basically this is to ensure that the branches are related to the trunk, so same commits are not downloaded again. The refs/remotes/branches/* is a wildcard that creates remotes for each branch that is present. And the high-lighted portion is a comma-separated filter will restrict the branches we download.

Note that since the overall trunk path is still same, it din’t break the existing revisions in master (which pointed to git-svn).

  • git svn fetch

That took a long while with no response – after some more research, I found the .git/svn/metadata file – opening this showed that the file was indeed getting updated, something called branches-maxRev was getting updated – it started searching from revision 0 to see where the branches were created which are not yet fetched locally.

Note that it was *not* downloading all the revisions, it was just searching svn to see when it created the branch (because we don’t have that info locally).

Not fast-enough though – CTRL-C!!

  • Found the second reference below – basically suggesting if we know the revision on which the SVN branch was created, we can speed up the process. No problem right? Well, went to https://<svnbaseurl>/viewvc and used the browser client to see that the RB-10.26 branch was created on revision 29313
  • Re-run the above command but with this revision

    git svn fetch –r 29313:HEAD

    Ok, some things start downloading! I can see RB-10.26 in the refs path in git-svn logs.

  • After everything downloads, verify using “git branch –r”
  • BOOM!

And it works. Took a few minutes to download the diff revs, but now I have a new remote: /branches/RB-10.26. Now I create a new branch in git to point to this reference

  • git checkout –b production26 remotes/branches/RB-10.26
  • and verify

git svn info

Shows the branch instead of trunk – switching to master shows trunk.

The actual git-svn download took few minutes – I’ve never been able to download an SVN branch *ever* so fast, especially when using SVN, so this is a big win for Git, even when working with SVN!



3 Laws For Software Developers

I now propose these three laws for any useful Software Developer –

  1. A Developer may not, through action or inaction, let the user do more work than necessary
  2. The developer may not, let the computer do more work than necessary, as long as it does not conflict with the First Law
  3. A developer may not do more work than necessary, as long as such it does not conflict with the First and the Second Laws.

Note: 2nd and 3rd Laws might interchange in priority depending on scale.

Bonus Law: You will make the world a better place. Break all 3 laws if you have to, to do this.

Inspired from Asimov’s 3 laws of robotics.

Religious Practices For Programmers

I was asked recently to come up with a checklist for developers to improve code quality. There are definitely a lot of things on the internet for this, but what the hell, here’s my $0.02 worth.

Apart from years of penance and discipline, here’s a few things that should definitely help. This is written targeting C# developers but a large part of it should apply to all developers.

Key things to keep doing daily –

  • Refactor – the first version of code that “works”, will more or less suck – it will be un-optimized, violate DRY principle, might have unnecessary code, won’t have enough tests, etc. It’s only refactoring that improves things. So consciously keep enough time to refactor the code once it is in working state. This is the single most important thing that people forget to do – it’s crazy even. With this one single rule, your code will improve several folds in terms of quality.
  • Remember that code needs to be read and maintained long after it is written – write code that people will find a delight to read or modify. Try to follow simple things such as –
    • Separation of concerns
    • Automated testing
    • Leveraging type system wherever possible for compile-time guarantees
    • Use better language constructs to keep code as concise as possible. A line of code that doesn’t exist is a line of code that can’t have a bug!
    • Higher and higher levels of abstractions
  • Keep on the lookout for repetitive code, or work that you are doing that did not make you think – for e.g. if you are just copy pasting from another place in the application, it means that there is a strong opportunity to refactor, such that you *don’t need* to copy paste (for e.g. a single method call, maybe with optional parameters for conditional handling).
  • Spend more time on thinking than typing – you are a developer not a typist
  • Have good typing speed though – you want whatever you think of to come on to the screen without breaking your thought process
  • Keep on the lookout for tools that will make life simpler. Resharper for instance, helps you with a lot of silly mistakes.
  • Don’t use the tools as a crutch though. For e.g. you should be able to make out good code from bad just by looking at it.
  • There will be occasional instances where you need to put in a hack – always keep this as the very very last option. And add enough comments to warn others that this is not a pattern to be followed
  • Do not sacrifice long-term maintainability for short-term gains – even if the business asks for it. Simplify things if possible – but don’t compromise quality. (for e.g. we might not make the feature extremely configurable, but still it can follow good coding practices such that it can be added later easily if needed).

Use better languages – F#, Haskell, OCaml, etc. I know you probably want me to tell you how to write better code with C#, but there is a ceiling we *will* hit with certain tools. If you use a kitchen knife to do a surgery, there is only so much you can improve via practices and skill. Just imagine how difficult it would be to do things in C++ and have same kind of quality that we have now with C# code (considering additional overhead in terms of memory management, for e.g.), spending the same effort. Some common C/C++ code bugs (such as memory leaks) just aren’t valid C# code in a lot of cases. There is a similar boost you get with F# and Haskell (where a lot of common bugs in C#, such as run-time null-reference exceptions, are just not valid code in F#/Haskell). That, along with tremendous conciseness, will make code quality better, even for the same developer.

F# Revisited

Sometime last year, I wrote an article demonstrating BDD with C# and F#. The accompanying source codes were hosted on github.

Now I’ve been doing some more functional programming recently and took an opportunity to revisit the F# code I had written then. As it turns out, I had written the first version in Object oriented style in F#. Switching to functional style has made it even more elegant and concise. The difference – 55 lines of code, versus 120 earlier (versus some 200 odd lines of code in C# for the same functionality).

Some of the differences –

  • Using Records instead of Types to encapsulate data (e.g Date)
  • Using base types directly wherever it makes sense (for e.g. int for Year instead of a separate Year type)
  • Using independent functions rather than enclosing them within types

These three go together – functions as first-class citizens means that we no longer need to define types just to house them.

  • Using simpler syntax – for instance, avoiding unnecessary braces
  • Using more powerful language features – using type inference, pattern-matching, higher-order functions a lot more aggressively
  • Some cheating Smile – smaller variable names, fitting more on one line (both, only where it doesn’t affect readability).

I find the new version a lot simpler to understand, with very little distractions such as instantiating objects or trying to access their properties.