Are You Studying With AI, or Just Getting Answers?

A few months ago, I was sitting at my sister’s place when I noticed her kids using AI to finish their homework. They were getting answers fast. Homework was getting done. Everything looked fine. Around 10–15 minutes later, I casually asked them a few questions about the same topic. They hesitated. They had just finished the homework, but they could not comfortably explain what they had actually learned. That moment stayed with me. AI has made access to answers almost effortless. But getting the answer and actually understanding the topic are still two very different things. That became the starting point for LearnSnap. I did not want to build another app whose only job was to give students faster answers. I wanted to explore what should happen after AI gives the answer. That eventually became the core loop: Ask. Learn. Practice. Revise. What I expected to be an Android app quickly turned into something much bigger. By the end of Shipaton, I had touched backend systems, subscriptions, analytics, monetization, product design, user testing, store assets, video editing, retention, growth, and marketing. And the biggest lesson was surprisingly simple: Shipping the app was only the beginning. Why I Didn’t Want to Build Another AI Homework Solver The easiest version of LearnSnap would have been simple: take a photo of a question, send it to AI, and get the answer. But that already exists in many forms, and modern AI is already very good at it. The question I kept coming back to was what happens after the answer appears. A student can read a perfect explanation and still forget most of it shortly afterwards. Seeing something can feel like learning, but being able to recall it and use it later is different. This is not just a product assumption. Research around retrieval practice and spaced learning shows that actively recalling information can improve long-term retention compared with simply studying it again. In one study of pharmacy students, long-term retention was around 46% after study alone, 50% after massed practice, and 67% with spaced retrieval practice. Persky et al., 2018 That changed how I thought about LearnSnap. I did not want the AI response to be the finish line. I wanted it to be the starting point. So the product gradually took shape around four simple steps: Ask: type a question or scan it from paper. Learn: get a clear explanation instead of only a final answer. Practice: test yourself on the same topic while it is still fresh. Revise: save the topic as flashcards and come back to it later. In simple words: ask, learn, practice, and revise. The goal is not to make AI answer faster. The goal is that when the same topic comes up again, the user already has enough context to understand what is being discussed instead of starting from zero. Students were my first audience, but I quickly realized the idea could go beyond homework. A working professional might hear an unfamiliar term in a meeting, ask AI what it means, practice the concept once, and revise it later. The problem is basically the same: Getting information is easy. Turning it into knowledge is harder. The First Product Decision Was What Not to Build Once the idea made sense to me, the next challenge was turning it into an actual product requirement document.I was building for Shipaton, so time was limited. But there were two very different ways I could use that time. I could optimize for the deadline and ship something polished but shallow. Or I could keep adding ideas until Shipaton ended and never launch anything at all. So the first real product decision was deciding what not to build. Before writing more code, I tried to define the smallest version of LearnSnap that could still prove the core idea. What must exist for LearnSnap to feel like a learning product rather than another AI answer tool? That question shaped the MVP. The first release needed to let a user: type or scan a question; get a clear explanation; practice the same topic with a quiz; turn it into flashcards; save the learning material; return to it later; and use already generated study content offline. In simple words, LearnSnap had to support ask, learn, practice, and revise. Everything else had to justify why it belonged in the first version. I had plenty of other ideas: deeper progress systems, referrals, automation, social learning, more advanced revision, and eventually iOS. Some of those made it into later Shipaton iterations. Others were deliberately pushed back. That changed how I looked at the PRD. It stopped being a wishlist and became a boundary. It told me not only what LearnSnap should do, but also what I was not allowed to spend time building yet. I also had to think about monetization earlier than I normally would because every AI request has a real cost. Unlimited free usage might sound attractive for acquisition, but it could become expensive very quickly. Credits, subscriptions, free access, and later rewarded ads had to be considered as part of the product architecture from the beginning. The same was true for the backend. It would have been easier for the Android app to call an AI provider directly, but that would put too much sensitive logic and responsibility inside the client. So I made another early decision: The mobile app would never talk directly to the AI provider. AI requests, authentication, credits, subscriptions, referrals, and study generation would go through my own backend. That decision made the project much bigger than the Android app I first imagined, but it also moved LearnSnap closer to a real product instead of a demo. By the time the PRD felt stable enough to start serious implementation, I had one simple test for every new idea: Does this make the core learning loop stronger, or am I adding it because it sounds impressive? That question probably saved me more development time than any tool I used during Shipaton. Before Writing More Code, I Had to Figure Out What LearnSnap Should Feel Like There was another problem I had to solve before going too deep into implementation. I am not a designer. Figma was not part of my normal workflow, and things like spacing, visual hierarchy, color choices, and interface flow had always felt like a separate discipline to me. But when you are building alone, separate disciplines do not stay separate for very long. I started by looking at education apps and asking a basic question: What should a learning product actually feel like? I did not want LearnSnap to feel overly playful or visually noisy. The app is supposed to help someone focus, understand something, and move to the next learning step without getting distracted. That pushed me toward a blue and purple visual direction. Then I created two different design directions. One came from Google Stitch. The other came from a Claude-assisted design workflow. Neither one was perfect. So I compared them, kept the stronger parts, adjusted the spacing and hierarchy, and then showed both directions to actual students. I kept the questions simple: Which layout feels easier to understand? Which screen feels too crowded? Does the quiz flow make sense? Are the flashcards easy to follow? Do the colors feel calm, or just boring? Their feedback helped shape the final UI. It also exposed things I had not considered as a developer. One student photographed a question from a page that contained other text and asked me something very simple: How do I know the app is only reading my question and not everything else on the page? From my side, the flow made sense because I knew how the image was being processed. From the user's side, it was unclear. That feedback pushed me to improve the image review and cropping flow, so the user could decide exactly which part of the page should be sent for interpretation. That was a useful lesson. Before this project, I often treated UI as an implementation problem. Now I see that a feature can be technically complete and still fail if the user does not understand what is happening. If the next action is not obvious, the feature is not really finished. Now, jumping the gun a little here, the same problem came back when LearnSnap was getting ready for launch. Suddenly I needed Play Store screenshots, an app icon, a feature graphic, a preview video, a website, Product Hunt images, and Shipaton media. And every time I made one of those assets, the same question came back: How do I explain the product clearly without making everything look crowded? That became another learning curve. I started creating assets in Figma myself, composing screenshots, making thumbnails, and eventually editing videos too. By the end of Shipaton, I was not only learning how to build LearnSnap. I was also learning how to present the product, explain it visually, and make someone understand it before they even installed it. Then I Realized I Wasn’t Just Building an Android App Android development was my comfort zone. Kotlin, Jetpack Compose, navigation, UI states, local storage, APIs from the client side. These were problems I understood. Backend development was not. At that time, words like NestJS, Prisma, MariaDB, migrations, webhooks, refresh tokens, idempotency, and rate limiting honestly felt a bit mind-boggling. I remember looking at all of that and thinking: I am building an Android app. Why am I suddenly dealing with database migrations and subscription webhooks? But LearnSnap was forcing me in that direction. If I wanted credits to be trusted, subscriptions to survive reinstalls, referrals to work properly, AI usage to stay controlled, and user state to remain consistent, I could not keep everything inside the mobile app. The backend was no longer optional. So I started learning it the same way I had been handling the rest of the project. I did not try to become a backend expert overnight. I just tried to understand enough to make the next correct decision. Over time, the backend became responsible for authentication, AI requests, credits, subscriptions, RevenueCat webhooks, referrals, study generation, account state, and production monitoring. That changed how I looked at even a simple button. A user tapping Get Answer was no longer just a UI event. Behind that one action there could be authentication, backend validation, a credit check, an AI request, database work, and then the final response coming back to the app. And if any one of those steps failed, the user did not care whether the problem came from Android, the backend, the database, or the AI provider. They only knew one thing: The app did not work. That was the point where I stopped thinking about LearnSnap as only an Android app. I was now building a complete system, and that pushed me far outside the part of development I already knew. AI Became My Learning Accelerator, Not My Replacement I would not pretend that I learned every backend concept in the traditional way during Shipaton. AI accelerated that process a lot. I used ChatGPT and Claude to understand unfamiliar architecture, challenge technical decisions, break large requirements into smaller tasks, investigate bugs, review code, and move between product thinking and implementation much faster than I could have on my own. But one thing became very obvious: AI could write code faster than I could trust it. That changed the way I worked. Instead of only asking, “Can AI build this?”, I started asking questions like: What happens if the app closes halfway through? What happens if the same request is sent twice? What happens when a subscription expires? What happens after a refund? What if the AI provider goes down? What happens after reinstalling the app? Those questions became more important than how quickly a feature could be generated. I started splitting work into smaller tasks, writing clearer requirements first, checking the implementation against those requirements, rerunning tests, and reading the actual code before accepting a change. AI helped me move outside my comfort zone, but verification is what made that useful. It did not remove the need to understand what I was building. It gave me a much faster way to learn while I was building it. Building the Product Was One Problem. Making It Reliable Was Another. The first working version of a feature was rarely the end of the work. Subscriptions are a good example. From the outside, the requirement sounds simple: User pays. Premium unlocks. In reality, I had to think about purchases, renewals, expiry, refunds, restores, stale entitlement state, reinstalls, account changes, and credit expiry. The same thing happened with AI credits. At one point, the app could show credits that the backend would no longer allow the user to spend. At another point, an expired subscription allowance could behave incorrectly when a refund arrived later. A process death could also cause the same operation to run again unless the request was protected against duplicates. These were not exciting features. Nobody installs an app because the refund accounting is correct. But these were exactly the things that made me more comfortable putting the product in front of real users. I found smaller issues everywhere too. A notification deep link could take too long because it was waiting for authentication. A premium state could briefly flicker when the app launched. A provider outage could leave the user staring at a Retry button that could never actually recover. A referral link could silently fail because of how the Play Store referrer string was parsed. None of these problems looked impressive in screenshots, but fixing them changed how reliable the product felt. That became one of the clearest lessons for me: The happy path is usually the easy part. The product starts becoming real when you begin thinking about everything that can happen around that happy path. Shipping the App Changed the Problem Eventually, LearnSnap reached the point where I could stop asking, “Can I build this?” and start asking a much harder question: Will anyone actually use it? Before I could find out, I first had to get through Google Play. LearnSnap had already been in closed testing, and Google required a continuous 14-day testing window before I could move forward. I managed to make that process longer for myself. On day 8, I removed the Play-installed build from one of the tester accounts and installed a development build directly from Android Studio. That tester stopped counting toward the continuous testing window, and I had to start the cycle again. It was a frustrating mistake, but it also made one thing very clear: Shipping through a real store is very different from having an APK that works on your own phone. Getting the app ready for Google Play meant dealing with testing tracks, policy checks, store screenshots, an app icon, a feature graphic, preview video, listing copy, subscriptions, and all the small things that do not exist while the app is still sitting on your own device. LearnSnap finally launched publicly on August 25, 2026. Readers can download it directly from Google Play. I also had to think seriously about monetization before launch. AI usage has a real cost, so I could not simply offer unlimited requests and hope the economics would work later. That led to a credit-based subscription model through RevenueCat. Free users get enough credits to experience the core product, while paid users receive larger credit allowances through weekly, monthly, or annual subscriptions. Later, I added optional rewarded ads as another path. If a user reaches zero credits and does not want to subscribe, they can watch a rewarded ad and continue studying. I liked this approach because it keeps advertising outside the actual learning experience. There are no banners between explanations and no forced interstitials during a quiz. The ad only becomes relevant when the user needs more access. I also added OneSignal for retention, but with one rule in mind: A notification should bring the student back to something meaningful, not just back to the app. If someone studies a topic and leaves before practicing or revising it, the reminder can bring them back to that same learning context. By the time LearnSnap went live, the product had become much more than the simple AI study helper I first imagined. But going live changed the problem again. The product finally existed. Now I had to figure out how to get it in front of people. The Hardest Part Started After I Shipped Once LearnSnap was live, development stopped being the biggest problem. Growth replaced it. With development, I usually know what success looks like. A bug is fixed or it is not. A screen works or it does not. Growth has been much less predictable. So instead of pretending I had a growth strategy figured out, I started testing whatever channels were available to me. What I Actually Tried I launched LearnSnap on Product Hunt. It gave the product some visibility, but it did not turn into a meaningful acquisition channel for me. Most of the messages I received afterwards were from services trying to sell promotion, listings, or other growth products rather than students discovering LearnSnap. I also posted in Shipaton and Reddit communities. The response there was close to zero. That was useful information by itself. Public posting was not automatically giving me the kind of feedback I needed. I created a new X account specifically to document the Shipaton build as well. It was suspended the next day under the generic label of “inauthentic behaviors,” and multiple appeals did not restore it. So I stopped treating public communities as my only feedback source. The most useful feedback actually came from students I could reach directly. I asked students in my own circle to install LearnSnap, gave them enough credits to use the complete flow, and asked them to tell me what felt confusing, useful, or unnecessary. That feedback led to real changes in the product. Other students asked for a way to report whether an AI answer was acceptable or problematic, which led me to add feedback and reporting around generated answers. Even a small detail like the greeting logic changed because a tester noticed that the app could still behave as if it was “evening” very late at night. Those conversations were more useful than getting likes on a post. Trying to Reach Beyond My Own Circle I also started approaching people who already have access to students. I spoke to teachers and explored whether they could let their students try LearnSnap. I have also approached a school about a possible collaboration. That conversation is still in progress, so it is too early to claim any result from it. The same is true for the ambassador model. The idea is to let students, tutors, or education partners refer users and earn only when those referrals become paying subscribers. It may become a useful acquisition channel. Right now, it is still a hypothesis I am testing. Then the Problem Moved One Step Earlier Paid acquisition through Google Ads, Meta, TikTok, creators, or platforms such as Noise can move faster, but they all eventually run into the same constraint for me: budget. So I started building LearnSnap’s presence on Instagram, TikTok, and YouTube through short-form content. That changed the question again. At first I was asking: How do I get more users? Now I am asking: How do I get more viewers first? Because if a Reel gets almost no reach, there is very little opportunity to convert anyone into a user. If the content reaches a much larger audience, even a small percentage becoming curious enough to install LearnSnap can start creating an acquisition loop. So right now I am learning another system from scratch: hooks, watch time, retention, creative formats, captions, and what makes someone stop scrolling. The social experiment is still too early to judge. I do not yet have a repeatable content format or enough data to claim that short-form video is driving meaningful installs. But that is the next problem I am actively working on. How Do You Get Views? Honestly, I do not have the answer yet. And that is probably the most accurate way to describe the current stage of LearnSnap. I know how to build the product. I know much more now about making it reliable. The part I am still learning is distribution. Shipping LearnSnap gave me something real to grow. Now I have to figure out how to put it in front of enough people to learn what happens next. What Shipaton Actually Changed for Me When I started Shipaton, I thought the challenge was simple: build something useful and ship it on time. By the end, I realized that building the app was only one part of the job. I had to think about product scope, design, backend systems, subscriptions, reliability, user feedback, monetization, store presentation, and eventually distribution. The biggest change was probably how I started seeing myself. I came into the project from an Android development background. I am leaving it thinking much more like an indie product builder. A few lessons will stay with me: a working feature is not always a reliable feature; AI can make learning faster, but it cannot replace verification; real users will notice things you never thought to question yourself; and shipping a product and getting people to discover it are completely different problems. LearnSnap is still early. I do not have huge user numbers or a proven growth engine yet. But I now have something real: a live product, a working backend, monetization, real users to learn from, and a much clearer idea of what I need to figure out next. That is probably the biggest thing I am taking away from Shipaton. I did not just learn how to build LearnSnap. I learned what starts after the product is built.