Building BeautifAI Taught Me About The Next Bottleneck, and It Changed How I Work With AI

By Harini Senthil Arasu · September 26, 2026 · Originally published on Medium

Building BeautifAI — an AI styling app for teens — taught me that shrinking a $20K build to $99 doesn’t shrink the hard decisions.

Every morning before school, I stand in my closet half asleep, staring at my clothes and wondering what to wear. I usually grab a random shirt and the first pair of pants I see, only to regret the mismatched combination later in the day. After talking to other girls, I realized this was not just my problem. For many teenagers, choosing an outfit before school feels like a daily struggle.

That led three of my friends and me to ask a simple question: could technology make this part of our mornings easier?

Artificial intelligence was already becoming common in classrooms, workplaces, and everyday life. We wondered why it couldn’t also be used in our closets. That question became BeautifAI: an AI-powered styling app designed for teenage girls. Users upload pictures of the clothes they own, and the app recommends outfit combinations based on color theory, styling principles, and personal preferences.

BeautifAI began as a marketing project for our entrepreneurship class in high school. At first, it existed only as an idea presented through slides, market research, and a business plan. Over time, however, it grew into something much more serious. We pitched the concept to investors, gathered feedback, and began thinking about how it could become a real product.

A few months ago, I had a specification for an iOS app but not a finished product. Today, that specification has become a functioning app that is hosted and being tested by real users. A coding LLM wrote a significant portion of the code and shortened the development cycle dramatically, but the most important decisions were still human ones.

We Had a Specification, Not an App

Hand-drawn sketch of the BeautifAI home screen: greeting, weather, daily affirmation, and today's outfit match

The biggest obstacle was building the app itself.

As we developed our business plan, we researched the cost of hiring someone to create even a basic version of the app. Our estimate was close to $20,000. As high school students and first-time entrepreneurs, that number felt impossible. For a while, it seemed as though the idea might never move beyond a presentation.

I began wondering whether I could build it myself using the limited coding experience I had gained over the previous two years. I knew some programming, but I had never created a complete iOS app, connected it to a database, or prepared it for real users. The gap between having an idea and building a functioning product still seemed enormous.

Turning the Specification Into Working Code

Then I began experimenting with Claude.

Until that point, I had mainly used Claude to help me understand chemistry concepts and review my essays. I had never thought of it as a serious development tool. But with the help of Claude, Xcode, and Apple’s development tools, I discovered that a coding LLM could help translate our written specification into a working application.

Instead of paying thousands of dollars for an initial prototype, my direct cost was largely reduced to Apple’s $99 annual developer fee.

The process was not as simple as typing one prompt and receiving a finished app:

Some days involved more debugging than building. At times, it felt like I was arguing with a computer that confidently misunderstood what I meant.

Diagram of the development loop: user prompts Claude, Claude generates Swift code, Xcode builds, the simulator runs it, and errors flow back to Claude

Still, the speed was remarkable.

Claude helped generate screens, navigation, database connections, image-upload features, and much of the underlying Swift code. It explained unfamiliar errors and allowed me to continue working without first mastering every part of iOS development. A feature that might previously have required several days of research, experimentation, and implementation could often reach a working first version within a few hours.

The LLM shortened not only coding time but learning time: instead of studying an entire framework before beginning, I learned the relevant concepts while implementing the app. But building the app also taught me something important: generating code quickly is not the same as building the right product.

A Working App Was Not Yet a Viable App

Our first architecture was simple: send all the wardrobe garments to the cloud for AI matching, get the match, and present it to the user. We knew this would consume a lot of WiFi/cellular bandwidth. But later, we found another issue that would totally render this solution unusable — the AI cost!

Diagram of the first matching architecture: the iPhone sends a photo on every request through a Cloud Function to a vision LLM

In order to compute the cost, we need to look at the number of tokens that are required to be read, because Anthropic bills images as input tokens, and a 1024×1024 garment photo takes about 1,400 tokens. So the cost is driven by the number of photos that need to be compared. If we take an average wardrobe of 30 garments, each match will use about 42,000 tokens, and that would cost about $0.043 per match/request when using a Haiku model, or $0.129 with a Sonnet model — which for 100 requests per month adds up to $4.30 or $12.90 respectively.

We realized this would not scale for us, and our intention was to provide this app as a free and accesible app for teen users.

Where Human Judgment Changed the Architecture

The fix was not a smarter prompt. It was a different question: does the photo need to be re-analyzed every time, or only once?

Instead of sending a garment’s photo to a vision model on every match request, the app now extracts structured attributes — color, pattern, garment type, formality, season — from each photo one time, when it’s uploaded. Every outfit request after that runs on those text attributes alone. No image is re-sent.

Diagram titled Extract once, match many: phase 1 extracts attributes from each garment photo once; phase 2 matches outfits using text only

That single architectural decision changed the cost curve entirely: extraction runs once per garment at roughly $0.003 per photo, and matching runs on text only at roughly $0.005 per request. For a user with 30 closet items generating 100 outfit requests a month, that works out to about $0.59 a month — instead of paying the much larger cost of a vision model re-analyzing a photo on every one of those 100 requests.

Cost per user: $0.003 per photo for extraction plus $0.005 per matching request equals $0.59 a month for 30 items and 100 matches

Claude could implement whatever architecture I described, including an expensive one. It took my own judgment to recognize which architecture was worth building.

The New Bottleneck Is Judgment

The cost of producing code is falling. The cost of making the right decisions is not falling at the same rate. More people can now build software — which makes product judgment, architecture, validation, ethics, and user understanding even more important. Human contribution moves upward: from typing every line toward defining, evaluating, and improving the system. The decisions that made BeautifAI more useful and scalable still required human judgment.

BeautifAI is still being beta-tested. The next challenge is protecting the teens who trust it with their photos and privacy. The answer will not come from a prompt but from listening to the people using it.

Disclaimer : No part of the text was written using LLM. However, the images were hand drawn and converted to more presentable form using LLM.