AI-Built App Store Apps After 10 Days: Did They Actually Make Money?

Three iOS apps. Ten days in the App Store. Roughly $275 in revenue, running at about $20 a day with no ongoing effort. That is the honest result, and the person who published it was not trying to oversell it.

I am Madhuranjan Kumar, and the reason I find this experiment worth a close read is not the dollar figure. It is the system underneath it. Three apps, built with Claude Code and submitted without a development team, earning daily revenue from a workflow that compounds with each iteration. When I look at a result like this, the question I want to answer is: what exactly did the builder learn, and how does someone replicate it with the next idea? Here are five lessons worth taking seriously.

Lesson 1: Static apps earn clean margins from day one; AI-powered apps require cost modeling before you set a price

The experiment produced two types of apps, and understanding the difference is the foundation of everything else in this pipeline. The first type is static: the app runs entirely on data and logic stored on the device. No external API calls, no per-use costs, no backend to maintain. You pay once to build it and the Apple Developer account fee covers your ongoing overhead. The Nido Collector app, which drove 94 of the roughly 120 total sales in this experiment, is a static app. The unit economics are nearly as simple as they get: every sale is close to pure margin after Apple takes its cut.

The second type is AI-powered: the app calls an external model every time a user runs a session. The Looks app, the most recent build in this pipeline, takes a photo and returns personalized style images including an old-money aesthetic, six haircut options, and a wardrobe palette. That output comes from the OpenAI GPT image API, and image APIs charge by the token, not by the image. Input tokens, cached input tokens, and output tokens each carry their own rate. Quality settings change the cost: a high-quality vertical output costs more than a standard square. Aspect ratio changes the cost. The number of images returned per session changes the cost.

This is not a reason to avoid AI features. It is a reason to model the cost before you set the price. The builder ran 10 to 20 real test calls before launch, using the exact quality settings and output configuration planned for production. That gave him the actual cost per session, not an estimate, and he priced above it with a comfortable margin. Apps that skip this step and set prices arbitrarily can lose money on every single session without the owner realizing it until weeks later when the API bill arrives.

For static apps, the margin calculation is almost trivial. For AI apps, it is the most important step in the whole build process and it takes less than an hour to do properly.

Lesson 2: Claude Code runs the entire build loop so you focus on decisions, not syntax

Claude Code is the tool that makes this pipeline accessible to a single person without a development team. You type what you want in plain language, and the agent writes the app code, opens Xcode, launches the iOS simulator, and tests the build on its own. The workflow that used to require a developer to manage every step now runs from natural language direction.

What this means in practice: the builder is not learning Swift or debugging compilation errors manually. He is making product decisions. What should the app show when it opens? What does the user see after uploading a photo? How many style variations should one session return? Those are judgment calls about the product experience, and they are the decisions that actually determine whether the app earns downloads or gets abandoned after the first use.

The build loop runs in the background while the builder reviews the last output. When Claude Code finishes one pass, you look at the simulator, decide what to change, and prompt the next instruction. The iteration speed is fast enough that a working, testable build is achievable in an afternoon for a well-scoped app idea. That speed is what makes the pipeline viable for a single person to run across multiple apps simultaneously.

The gap between someone who uses this pipeline effectively and someone who does not is not technical skill. It is the ability to describe the product clearly and make fast decisions about what the next change should be. Those skills improve with each build, which is why the fifth app in this pipeline will come together faster than the first.

Lesson 3: Per-session pricing is the only model that guarantees you never lose money on API calls

The Looks app uses a per-session pricing model rather than a subscription. The user buys a single session or a pack of sessions as an in-app purchase. Each purchase covers the API cost of the sessions it buys before any revenue reaches the developer. That alignment between cost and price is what makes the economics predictable at any volume.

Here is the math that shows why this matters. Suppose a single high-quality vertical style session through the GPT image API costs $0.04 in token fees when you run it at the output quality you plan to ship. You price one session at $0.99. Apple takes 30 percent on most transactions, leaving $0.69. After the $0.04 API cost, you net $0.65 per session. That is a 94 percent margin on the variable cost, and it holds at 10 sessions per day or 10,000 sessions per day.

Compare that to a flat subscription model where users can run unlimited sessions for $4.99 per month. One heavy user running 200 sessions in a month at $0.04 per session costs you $8 in API fees on a plan that collected $4.99. The subscription model subsidizes heavy users at the expense of the developer unless the API cost per session is near zero. For static apps, subscriptions work cleanly. For AI apps where each interaction carries a real cost, per-session pricing is the model that keeps the unit economics positive regardless of how much any individual user engages.

The App Store's discoverability for this type of app also connects to how well the app's name and description are written for the keywords people are already searching. The organic search and content strategy that matters for a web business has an analogue inside the App Store: apps whose titles and subtitles match what people type into the search bar on the day they feel the need for that specific tool get found without paid promotion. When the Looks app targets the "looksmaxing" search behavior that was already trending at the moment of launch, the marketing burden shrinks substantially because demand pre-exists.

Lesson 4: Trend-surfing produces downloads without a marketing budget

The apps in this experiment were not built to fill a market gap the builder discovered through months of research. They were built to meet demand that was already visibly active. Nido Collector targeted a community of collectors. Poke Machine targeted a specific format of content creator. The Looks app targeted the looksmaxing aesthetic trend, which had been growing virally on short-form video platforms in the weeks before the app launched.

The practical implication is that apps aimed at pre-existing demand require far less marketing to get their first downloads than apps that try to manufacture demand for a novel concept. When a potential user types a search term into the App Store and finds exactly what they were looking for, the conversion from view to download is high. When a user has to be educated about why they need the app at all, the download friction is much higher and the cost of acquiring each user goes up.

Scouting for trending topics before you start a build is a skill that improves with repetition. Viral formats on short-form video, Reddit threads where communities express frustration with the tools they have, search volume spikes in App Store categories, and social media sounds or aesthetics that have reached a large audience in the past 30 days are all signals that can point to an app idea with built-in demand. The builder in this experiment identified the looksmaxing format as one with high search intent and low competition in the App Store specifically, which is a more useful insight than simply noting that it was trending on social media.

Once an app is live and earning downloads, the next layer of growth involves the lifecycle of the customers who downloaded it: how you bring them back, what you offer them next, and whether the tool they bought becomes part of a broader relationship with your brand. That is the territory covered by CRM and customer lifecycle management, and even a simple tool like a follow-up email sequence to app buyers can meaningfully extend the revenue per customer beyond the initial purchase.

Lesson 5: The pipeline is the asset, not any single app

The most important mindset shift in this experiment is treating every build as a step toward a reusable template rather than as a standalone bet. The first app in the pipeline is valuable mostly because it teaches you where the build process breaks down, what the submission review process actually requires, and how to model the cost for an AI feature before you set a price. The second app is faster. The third is faster still. By the fourth or fifth build, the template is solid enough that a new idea can go from prompt to App Store submission in a fraction of the time the first one took.

The goal the builder stated explicitly was not to produce a hit with any single app. It was to produce a templatized workflow that could be repeated across any number of ideas. Each build that reaches the App Store improves the review submission checklist, tightens the cost modeling process for AI features, and adds another data point on which types of ideas gain traction quickly and which take longer to find their audience.

$275 in 10 days across three apps at roughly $20 per day is not a life-changing number in isolation. Compounded across 10 apps over several months, with each app improving the pipeline and each subsequent build taking less time to ship, the model starts to look more interesting. And the apps that take off with stronger demand produce revenue curves that grow for weeks or months after launch without additional spend. The pipeline does not generate lottery tickets. It generates a portfolio of small, consistent earners that build on each other over time.

---

The practical path from here is straightforward. Pick one trend-surfing idea with visible demand and low App Store competition. Use Claude Code to build and test it, keeping the first build scope narrow enough to finish in an afternoon. If the idea uses an AI API, run the cost calculation before you set a price, model it at the quality settings you plan to ship, and price with a margin that is comfortable rather than tight. Submit it to the App Store, note what you learned about the review process, and start the next one on the same template. Each app that earns, even modestly, validates the pipeline and funds the next iteration.