why i stopped working on nytr — problems and lessons.

a project i worked on was nytr, where i built a full-stack ios app for students studying at penn state harrisburg.

the idea was pretty simple. we already have apps like macrofactor, myfitnesspal, and cronometer, but i wanted to build something specifically for penn state students.

basically, you would get a notification telling you what to eat every day from the campus dining menu to meet your calorie and protein goals. i eventually wanted to expand it to other penn state campuses too.

i also had plans for sleep tracking, integrating hevy so the app could give feedback on your workouts, and some smaller features like searching for foods, scanning barcodes, and logging meals.

sounds like a pretty successful idea, right?

no.

the first problem was actual usage. the app was built around a deterministic system, basically using mathematical calculations to figure out what someone should eat based on their goals. it worked in theory, but practically, it wasn't that simple.

sure, you could use it to hit your calorie and protein targets in the short term. but in the long term, nutrition isn't just about calories and protein. things like omega-3, cholesterol, vitamins, and other nutrients matter too. my app didn't properly account for all of that.

and there's also the fact that people don't necessarily want to eat whatever an algorithm tells them to eat every single day.

the second problem was data.

the app relied heavily on the official penn state dining menu, and the nutritional data wasn't always complete or consistent. some items didn't even have all their macros listed.

that's a pretty big problem when your entire app depends on that data to make recommendations. no matter how good the code is, if the data going into it isn't reliable, the recommendations won't be either.

third, installation.

publishing an app on the apple app store costs $99 per year, and i intended to build this project on a $0 budget.

so the practical way for someone to use it was to clone the github repo and manually install it through xcode.

now imagine telling a random student that they need a mac, xcode, and some technical knowledge just to try your food tracking app.

yeah, not happening.

fourth, versatility.

i built nytr for ios, but i didn't make an android version. so that immediately excluded a large number of students who could've potentially used it.

i could've continued working on these issues. i even experimented with adding an llm layer to make the recommendations more flexible, but that introduced another problem: api costs.

since i wanted to keep everything free, i started looking into on-device apple intelligence instead.

but eventually, i stopped working on phase 2.

not because the project was completely useless or because i couldn't figure out how to implement the remaining features. i just started questioning whether adding more features was actually going to solve the main problems.

i learned a lot from building nytr. working on the backend, ios development, integrating different services, dealing with real-world data, and figuring out how all these components work together.

but probably the biggest lesson was that building something that works and building something people will actually use are two very different things.

i spent a lot of time thinking about how to make the app technically better, but not nearly enough time figuring out whether students would actually want to use it every day.

looking back, i probably should've validated the idea with students much earlier instead of building so much first.

i could've kept adding features and trying to perfect everything, but at some point, i felt like i'd learned what i wanted to learn from the project.

so i decided to move on and put my time into learning other things.

maybe i'll revisit nytr someday. but for now, i'm pretty happy with what i learned from it.