Shipping a Product as a Student: What I Learned at 18

In 2022 I uploaded my first app to Google Play. It was called SineKazan, and it was built around users taking part and winning prizes. Technically it worked — the code I had written held up, users kept arriving, the system did its job.

After a while I took the app down myself. The reason was not a bug, and it was not a technical collapse. At that age I did not have the knowledge or the experience to manage the community that forms around an app like that. I could handle the code side; I could not handle the human side.

I am not telling this as a failure story. Quite the opposite: what I learned from that app shaped every project that came after it. This post is what I would say to someone who is still studying and trying to ship a product on the side.

Writing code is a small part of running a product

This is the easiest illusion to fall for as a student. You think the work is done when the app is done. But a whole pile of work starts the moment you go live, and none of it is code:

• Answering incoming questions — and doing it in a consistent voice
• Noticing abuse and putting measures in place
• Setting the rules, and then following those rules yourself
• Handling complaints, separating the fair ones from the unfair ones
• Staying compliant with store policies

None of this is “hard”. But all of it demands continuity, and it has to run alongside school. I could not strike that balance, and I preferred taking the app down to running it badly. I would make the same decision today; but this time I would act differently long before reaching that point.

Time really is limited — and that is a good thing

While school is going on you get a couple of hours a day. That constraint looks like an obstacle at first, but it is a good filter: you cannot afford a large scope, so you are forced to decide early.

The routine that worked for me was this: short, single-topic blocks on weekdays, one long block on the weekend. Trying to build new architecture in a short block is wasted effort — the time runs out before your head has warmed up to the problem. Instead I reserved the short blocks for small, well-defined jobs: fixing the copy on a screen, closing a bug, writing a test. I saved the work that needed real thinking for the long blocks.

One more thing: write down the next step at the end of every session. Sitting down two days later and trying to remember where to pick up was eating half of those two hours.

Finishing is worth more than perfect

Most student projects die at eighty percent. A few of mine did too. What I noticed is this: the last twenty percent is the part that looks the most boring and the least instructive — the store page, the icons, the privacy text, the error states, the empty screens. But the whole of the real experience lives right there.

A small app that shipped is more valuable in every way than a big app that did not: both in what it teaches you and in what it says on your CV. Being able to say in a job application “I built this, it is on that store, I made these decisions, I got this part wrong” sits in a completely different place from “I was working on something like this”.

The fastest way to learn is a real user

There are problems you never run into while teaching yourself, and none of them are covered in a course. A real user presses the buttons in an order you never imagined; does not close the app the moment the connection drops but leaves it open; does the thing you said “nobody would ever do” on day one.

I only saw a bug caused by Turkish characters once I had real usernames. I only understood how critical offline behavior is thanks to users opening the app on the subway. Things like this multiply how fast you learn — and the only way to get them is to put the product out in the field.

What I would do if I looked back

Four points:

• I would start smaller. For a first product I would not pick a model that requires community management.
• I would have decided to take it down sooner. After I realized I could not run it, I tried to keep it going for a while longer; that stretch of time did nobody any good.
• I would write. I no longer remember most of the technical decisions I made in that period. If I had taken notes somewhere, they would be far more useful today, both for me and for other people.
• I would count the things I finished. As a student it is hard to see progress; everything feels half done. Keeping a list of what was completed turned out to be far more effective for staying motivated than I expected.

And why I would do it again

That app did not stay live, but what it left me did: knowing how store processes work, meeting real users, having finished something end to end, and most of all, having learned what I could not do. If I know what to narrow the scope against in the apps that came after, that judgment was learned right there.

The real gain from shipping a product as a student is not the product itself. You become someone who makes fewer mistakes on the next one — and you learn that without waiting three years.

• Career
• Product
• Experience
• Mobile Development