Photos of your people in one Home Screen widget. Slices or squares, with everyone adding their own photo.
App Store screenshots ↗02 / ROADMAP
From experience to the next step
Your starting point does not determine the outcome
I was not consistently successful in exams during primary and middle school. In high school, I changed how I worked: I attended supplementary classes from ninth grade and focused on university admission for four years. I entered Marmara University’s Computer Engineering programme ranked third among incoming students.
That experience shaped how I work. I care less about how far behind I start than about finding a way forward. I have seen what sustained focus can do. In product development, that means changing an approach that is not working, rather than simply working harder.
Learning to turn an idea into a product
My first goal was an app that answered legal questions. For eight weekends, I got up at six and travelled two hours by bus, Metrobus and another bus to learn Ionic 3. The legal app never launched, but I continued building mobile products.
Before Swift, I worked with HTML, Java, JavaScript and CSS. I then learned Swift, Storyboard and Android development. Becoming able to ship on both platforms alongside university took years. I wrote my earliest apps myself, without today’s generative AI tools.
I designed all of my apps’ interfaces myself in Figma. Over time, hands-on work with Firebase and Supabase gave me strong practical experience with both. Thinking about design and infrastructure together became part of how I build products.
Building software and signing up businesses
LattApp began as an app where café purchases earned points towards free coffee. I contacted entrepreneurs, investors and cafés directly, and signed up around twenty cafés. I prepared counter cards and printed promotional materials.
Signing up businesses did not automatically lead to customer adoption. I experimented with prize games to increase participation. This taught me that functioning software, partner participation and end-user habits are separate problems.
Testing engagement and revenue models
I moved from café reward games to word games, tower stacking and trivia. When cafés closed during the pandemic, I replaced business-funded rewards with an in-app prize pool.
At one stage, this model generated approximately TRY 6,000 in a month. Competitions, ads and reward selection worked within the same product. However, I did not consider the model sufficiently scalable and discontinued it.
LattApp became Vlatua during this period. I released these experiments as updates to the same store listing, so its single release date does not represent the full product history.


Vlatua: Para Ödüllü Yarışma
Word game and rewards · ArchiveRethinking product costs as technology changes
A humorous Instagram newspaper I made for friends became the basis for an app that retrieved and summarised RSS news. Building the iOS and Android versions took around three months. Falling AI API costs improved the product’s cost structure during that period.
Completing the technology was not enough to create demand. My marketing experience then largely consisted of a one-dollar-a-day Meta ad. In subsequent work, I began considering distribution and acquisition earlier, alongside product development.
Separating early revenue from lasting demand
I developed Vlatua further with personal newspapers and map layers, bringing interests such as flights, wildfires, earthquakes and space into one app.
It generated approximately $200 in one thirty-day period. I subsequently saw that much of the interest was tied to wildfire season, and most subscriptions did not continue. The experience taught me to distinguish seasonal interest from lasting usage and subscription demand.
Different needs and usage cycles
HoHoHo is a Secret Santa app for friends and families. It reached a few thousand downloads in its first year and several tens of thousands in its second. Invitations helped it spread, while seasonal usage limited continuity.
I built 15 vs 1 for a Women’s Day event: the player starts at zero and the opponent at fifteen. Ask & Shake was a mobile version of the Magic 8 Ball experience I wanted for myself. With StuMate, I built a product to help university students find roommates.
Across these products, I handled iOS and Android development, interface design, store releases and ongoing maintenance.

Building around a more focused need
PicPie brings a family or friend group’s photos together in one Home Screen widget. One person creates a group and invites others; everyone adds their own photo. The layout can use pizza slices or squares.
The idea came from wanting to see family more often and stay connected to everyday life. I am applying the invitation experience from previous products to a more focused, potentially daily need. PicPie’s lasting demand and growth model are still being validated.
Starting with Vlatua’s latest version, I moved to coding with AI agents and continued that approach with PicPie. It took me 26 days to launch PicPie on both the iOS and Android stores. I estimate that my previous solo workflow could have taken around six months; that is an estimate, not a measured comparison. I still created the designs myself in Figma. My AI agent handled the Cloudflare implementation; unlike Firebase and Supabase, I do not yet have the same hands-on depth to build that infrastructure manually.
Measure, learn and stay focused
My next priority for PicPie is understanding the journey from creating a group and inviting loved ones to adding a widget and sharing photos again. Alongside downloads, I want to evaluate group participation, repeat usage and subscription retention.
I want to test content and acquisition channels to learn which messages reach the right audience, and use those findings to inform product decisions. The aim is to understand why regular usage does or does not develop before expanding the feature set.
AI is now central to how I work. Returning to an entirely manual workflow would not be an efficient choice for me. I see my contribution as defining the need, designing the product, directing development, reviewing the work and making decisions based on the results.












































