I started selling software in 2001, while I was still a commerce student at St. Xavier's in Mumbai. The computer people carried in their pockets then, if they carried one at all, was a phone with number keys and a screen you could cover with a thumb. That is where my business began.
Over the years that followed I wrote twenty-seven apps for Nokia phones: Java programs, packaged as .jar files, for phones running Symbian. Some sold through online app stores, some I sold directly, and some were paid work built to order. None of them would impress anyone today. Between them they taught me most of what I still believe about building software people actually use.
What I made
The twenty-seven fell into four groups.
- An app for CA students. Multiple-choice questions to study with, and a test mode that marked your answers and told you where you stood: on course to pass the exams, or not yet.
- Everyday utilities. Small tools that did one job on the phone you already had in your hand.
- Business and accounting apps. Tools for the kind of work I was studying at the time.
- Apps made to order. Built for a particular client who needed something specific and was willing to pay for it.
The CA students' app is the one that shows the idea best. Studying for the chartered accountancy exams is long, and the hardest question for a student is not any single question in the paper. It is "am I ready?" A book cannot answer that. A phone you carry everywhere can, a few questions at a time, on a bus or between lectures, and then give you an honest verdict.
That app did not try to teach accountancy. It tried to answer one question well for one kind of person. Looking back, the apps that did that were the ones worth building.
Small memory, slow phones
The hardest technical part was the phones themselves. They had very little memory and slow processors, and an app that was careless with either simply did not run, or ran so slowly that nobody kept it.
So every feature had a price, paid in memory and in waiting. Large data could not sit in memory all at once; it had to be read in pieces. A calculation could not be repeated every time the screen changed; it had to be done once and kept. A screen could not hold everything a desktop program would show; it had to hold the one thing the user needed next.
A small budget forces you to decide what matters. A large one lets you put that decision off.
I did not see it as a lesson at the time. It was just the job. But the habit stuck: ask what the user needs on this screen, and leave the rest out. It is still the first question I ask about any interface, and modern machines have mostly made it easier to forget, not less important.
Getting paid, and getting found
The other hard part had nothing to do with code. A good app nobody hears about earns nothing, and a student writing software has no marketing budget. Being found was as much work as being good.
Getting paid was its own problem. Selling through online app stores meant standing out among many other apps. Selling directly meant handling every sale myself. Paid custom work was the clearest arrangement, because a client with a specific need knows exactly what the work is worth to them.
That last point matters more than it sounds. The apps worth building are not the cleverest. They are the ones that solve a problem someone can name: a student who needed to know if they were ready, a business that needed one task done faster. When the value is obvious to the person paying, the price is an easier conversation.
When the platform ended
Not every year paid enough to live on. In 2007 I took a job and kept the business going on the side. Then Symbian itself was discontinued. Every one of those twenty-seven apps was built for a platform that was going away.
I moved to Android. The code did not come with me in any useful way: a different platform, different tools, different screens. What came with me was everything else. I knew what students and small businesses would actually use. I knew how to keep an app small and quick. I knew that one clear job beats ten vague ones, and that the hardest part of selling software is being found.
Platforms end. The skills you learned on them do not, as long as you learned the parts that were never about the platform in the first place.
What a phone with number keys still teaches
I build AI systems and automation now, on machines thousands of times more capable than those phones. The work looks nothing alike. The questions are the same ones the CA students' app asked of me: who is this for, what one thing do they need from it, and what can I leave out so that one thing works well? Small, useful tools win, and the way to build them is to keep building, including in the years when it does not pay enough yet. Twenty-seven apps is how I learned that. You can see where the habit led on my projects page.
